text:
Feature Request - match_json_schema matcher

Hi, thanks for all hard works to make this gem, it's really helpful. I have a feature request and want to discuss, created a PR to describe the feature to see if this make sense :)
Requested feature and reason
Sometimes I only want to test nested object like JSON(response.body)['nested_object'], I think it's more flexible to not using response.body but just JSON-string at JsonMatchers::Matcher#matches?.
Anyone thinks it's a good idea to support this? Or having a better idea how to approach this? Willing to have discussion, thanks 😸
Usage
# spec/requests/posts_spec.rb

describe "GET /posts" do
  it "returns Posts" do
    get posts_path, format: :json

    expect(response.status).to eq 200
    expect(response.body).to match_json_schema("posts")
  end
end

#42

Released as part of https://github.com/thoughtbot/json_matchers/releases/tag/v0.6.0.
Thanks!


text:
Minify Bundled Entry Point Script

This issue recommends minifying the bundled entry point script. To achieve this, one can utilize the --minify or -m parameter when using the ncc command to bundle the script.

After careful consideration, minifying the bundled script for a GitHub Action project appears impractical. This is because committing the minified script to this repository could potentially increase the repository's size with each change, even for minor modifications.

source: gharchive/issue

repo: threeal/action-starter

license: Unlicense

license_type: permissive

license_source: github-api


text:
ingress with tcp forwarding capabilities

Right now the ingress used is traefik 1.7 or 1.8, which doesn't have the features for tcp forwarding. the tcp forwarding feature is required for threefoldtech/vdc-solutions-charts#13, suggested solution is upgrading to traefik 2.2 in k3os image

The entrypoint in the sample is changed to 'websecure'.
To update traefik version to 2.3.3, I changed the content of /var/lib/rancher/k3s/server/manifests/traefik.yaml as described here to:
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: traefik
  namespace: kube-system
spec:
  chart: traefik
  repo: https://helm.traefik.io/traefik
  set:
    image.tag: "2.3.3"
    ports.websecure.tls.enabled: true

And the new version got automatically installed. I tested peertube, mattermost, and the sample in the comment and they all worked. The address in the ingress is empty but it seems that nothing is broken.
it currently generates a self signed certificate will see how to use a CA instead.

done in https://github.com/threefoldtech/js-sdk/pull/2002

authors: OmarElawady xmonader

repo: threefoldtech/js-sdk


text:
Logout from hosted 3Bot doesn't react

I am logged in with my 3Bot for a hosted 3Bot. I want to log out, but there's no reaction after pushing the button.
Issue both on mainnet and testnet

Version information

OS: MacOS
Project commit/version: Hosted 3Bot on testnet and mainnet
Browser: Chrome 88 and Brave (tried both)

Verified on devnet, testnet, mainnet

authors: gmachtel waleedhammam


text:
documentation is not clear enough

documentation is not clear enough to explain the purpose of the web3proxy and after following the documentation it does not build correctly.

back end side documented now and built with success but there are 7 examples on the web3proxy but there is no clear documentation for every example and how to use every call

Updated the manual with clear example documentation. @khaledyoussef24 can you please check and let me know if it's more clear now? See https://threefoldtech.github.io/web3_proxy/index.html


text:
Update README.md

Need to escape | (pipe) symbol in table cells or it will terminate the current cell.

No use merging in my forked master.

source: gharchive/pull-request

license: MIT


text:
Thrust 100904 breaks OpenMP

Here is, thrust-bug.cc, a MWE that compiles under the github version 100803 but not under the latest CUDA release 100904
/*
 This program compiles with Thrust 100803 but not with 100904.

g++-8 -fopenmp -I100803 -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_OMP -DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_CPP thrust-bug.cc  -lgomp

g++-8 -fopenmp -I100904 -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_OMP -DTHRUST_HOST_SYSTEM=THRUST_HOST_SYSTEM_CPP thrust-bug.cc  -lgomp

100803 is the thrust github dir, which is version 100803.

100904 is cuda/include for 10.1.105.

Error:

In file included from 100904/thrust/device_allocator.h:27,
                 from 100904/thrust/device_vector.h:26,
                 from thrust-bug.cc:2:
100904/thrust/memory/detail/device_system_resource.h:34:59: error: 'universal_host_pinned_memory_resource' in namespace 'thrust::system::omp' does not name a type
 typedef thrust::system::__THRUST_DEVICE_SYSTEM_NAMESPACE::universal_host_pinned_memory_resource
                                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
100904/thrust/memory/detail/device_system_resource.h:34:9: note: suggested alternative: 'host_pinned_memory_resource'
 typedef thrust::system::__THRUST_DEVICE_SYSTEM_NAMESPACE::universal_host_pinned_memory_resource
         ^~~~~~
         host_pinned_memory_resource

*/

#include <thrust/device_vector.h>

int main() {
  thrust::device_vector<int> d(10);
  d[1]=1;
}

Hi and thanks for the report!
As for the bug: yes, we know; due to insufficient internal CI coverage for non-CUDA backends (we're working on improving this!) we've caught it too late for it to make it into CUDA 10.1, and the 1.9.4 tag is based precisely on that. This should be fixed both on master and maintenance/cuda-10.1 branches, and for the version packaged with CUDA, it should be fixed with the next release.
For some further information about our current branching stragegy can be found here.

I have a very similar problem, where it fails to compile a most basic example for the CPP backend, and throws this: error: namespace "thrust::system::cpp" has no member "universal_host_pinned_memory_resource"
Can I assume this is the same bug you already fixed?

It was not fixed.  They said that there was no time to get it working
before the release date.   They marked it closed because they knew about it.
My recommendation is that release notes should mention deletions as well
as additions.
This is not the only case where a new version of an Nvidia tool breaks
an established function.  One of my students reports that cuda 10.1
breaks tensorflow-gpu .
On 4/5/19 6:29 PM, Emmett Lalish wrote:

I have a very similar problem, where it fails to compile a most basic
example for the CPP backend, and throws this: error: namespace
"thrust::system::cpp" has no member "universal_host_pinned_memory_resource"
Can I assume this is the same bug you already fixed?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/thrust/thrust/issues/962#issuecomment-480442040, or
mute the thread
https://github.com/notifications/unsubscribe-auth/ASmBtBquuR1gqOfpAI2RM6Tv3VjqOp4qks5vd85egaJpZM4bnmpv.

--
W. Randolph Franklin, Professor
ECSE Dept., 6026 JEC,
Rensselaer Polytechnic Inst,
110 8th St,
Troy NY, 12180 USA
mail@wrfranklin.org or frankwr@rpi.edu
+1 (518) 276-6077
https://wrf.ecse.rpi.edu/

Hi,
This has been closed, because the issue has been fixed in this repository; the master branch does not have this issue anymore, and the maintenance/cuda-10.1 branch, which is what landed in the CUDA Toolkit release 10.1 plus several bugfixes (like... for this issue!) also doesn't have this issue anymore. Of course this doesn't mean that the 10.1 Toolkit has the bugfix; we can't fix bugs retroactively. An upcoming minor release of 10.1 doesn't have this bugfix either; the next minor release of 10.1 after that should have this fixed, but I can't promise anything, as whenever we release as a part of the CUDA Toolkit, we have to follow the internal procedures.
Now, the process of deciding what goes into a release internally is complicated; there's also deadlines that are rather strict, and no "last minute before release" fixes are accepted. This is the unfortunate consequence of releasing as a part of a product that is extensively tested; we can't "just" fix things if we discover them after the day of a final submission.
What I can promise you is that the versions on Github have as many bug fixes (that don't otherwise affect the release) as we deem necessary (and as time allows). Here, we have much more freedom for adding fixes to branches and on top of releases, since we are concerned mainly with Thrust, and not with the entire CUDA Toolkit. I can also promise that this will be fixed in the next regular release of the CUDA Toolkit.
Due to the slow velocity of internal changes in the Thrust testing process, we don't have as much test coverage as we'd like as part of the CUDA Toolkit testing process. We are working on that, and we intend to reach a point where we can fully test all backends for every internal change that we make. However, due to the fact that Thrust has been mostly in maintenance mode for a while now, this is a slow and painful process.
Now, a final thing: I realize that the current world is suboptimal, and it is one of our priorities to change it. One big change that we've recently made (after 10.1 has been released) is a rewrite of our build system for tests to CMake, which makes it really easy for us to actually run everything with all backends. This should help us avoid getting mistakes like this shipped with the CUDA Toolkit; however, until more extensive changes have been made in our testing infra, it may occasionally happen. Sorry for that. I really wish we could catch all possible bugs before releasing.
My hope here is that this particular issue is not a gigantic problem, since it affects the non-CUDA backends, so getting a version from a maintenance branch here is easier, because there's no inherent dependency on CUDA; and when CUDA is needed, then the version from the Toolkit does work.
Cheers.
@wrf3: I don't quite understand what you mean by "deletions". Can you elaborate?

@wrf3: also, is the tensorflow issue you've mentioned https://github.com/tensorflow/tensorflow/issues/26155? If so, then our team has also been bit by that compiler bug ;)

@griwes: I understand that bugs slip by a release milestone now and then. I'm just glad to see that the latest Thrust is public again and getting some love! The release notes this time around were impressive. It's a fantastic library and I'm glad to see it's not just in maintenance mode anymore.

Thanks for the detailed insight to how this works.
Of course I wouldn't expect last-minute changes to be incorporated into
an official package; that violates any SW discipline and just causes chaos.
It had been awhile since I looked at the github version since it used to
be older, and I'd gotten confused about the various versions.  It's good
to see the latest version now on github.
Based on your info, I'll start to include files from the github version
instead of from the cuda package.
Info about the status and future plans (to the extent allowable) is
always welcome.  One of my biggest decisions to make when starting a
project is what tools to use.  A lot of tools I start to use turn out to
have been a mistake.  Another large group turn out to be really good.
Thrust seems to be the latter.  However, the Kokkos people want me to
switch.
It would also be nice sometimes to know the reasons for particular
design decisions.  Some functions appear redundant.  But perhaps they do
something unobvious very well.
One reason I picked Thrust is the choice of backends.  I can program an
algorithm and test it on various architectures.  It's not always as easy
as recompiling; I hit many dependencies.  But it seems to be feasible to
carefully code my programs to compile both ways.
BTW I'm developing some programming paradigms for Thrust that may
perhaps be of interest.  I document them when writing up my algorithms,
and also my code is public.  I also have much shorter and clearer
versions of some of the example programs, by virtue of using lambdas or
_1 etc.  Id anyone's interested, just ask.
By new versions deleting things, I was thinking of the openmp issue and
of tensorflow-gpu.  This happens with non-Nvidia tools also.  Over the
many years that I've been writing C, the language and libraries have
changed so that my old programs no longer compile w/o modifications
(though the old executables may still execute).  Linux is likes to
remove old kernel function interfaces, forcing all kernel modules using
that interface to be rewritten.  I remember Ubuntu 16.10 (IIRC) that did
not initially support Nvidia drivers, although 16.04 did.  No they
didn't announce that in the lengthy release notes.
/W. Randolph Franklin
On 4/5/19 7:26 PM, Michał Dominiak wrote:

Hi,
This has been closed, because the issue has been fixed /in this
repository/; the |master| branch does not have this issue anymore, and
the |maintenance/cuda-10.1| branch, which is what landed in the CUDA
Toolkit release 10.1 plus several bugfixes (like... for this issue!)
also doesn't have this issue anymore. Of course this doesn't mean that
the 10.1 Toolkit has the bugfix; we can't fix bugs retroactively. An
upcoming minor release of 10.1 doesn't have this bugfix either; the next
minor release of 10.1 after that /should/ have this fixed, but I can't
promise anything, as whenever we release as a part of the CUDA Toolkit,
we have to follow the internal procedures.
Now, the process of deciding what goes into a release internally is
complicated; there's also deadlines that are rather strict, and no "last
minute before release" fixes are accepted. This is the unfortunate
consequence of releasing as a part of a product that is extensively
tested; we can't "just" fix things if we discover them after the day of
a final submission.
What I can promise you is that the versions on Github have as many bug
fixes (that don't otherwise affect the release) as we deem necessary
(and as time allows). Here, we have much more freedom for adding fixes
to branches and on top of releases, since we are concerned mainly with
Thrust, and not with the entire CUDA Toolkit. I can also promise that
this will be fixed in the next regular release of the CUDA Toolkit.
Due to the slow velocity of internal changes in the Thrust testing
process, we don't have as much test coverage as we'd like as part of the
CUDA Toolkit testing process. We are working on that, and we intend to
reach a point where we can fully test all backends for every internal
change that we make. However, due to the fact that Thrust has been
mostly in maintenance mode for a while now, this is a slow and painful
process.
Now, a final thing: I realize that the current world is suboptimal, and
it is one of our priorities to change it. One big change that we've
recently made (/after/ 10.1 has been released) is a rewrite of our build
system for tests to CMake, which makes it really easy for us to actually
run everything with all backends. This should help us avoid getting
mistakes like this shipped with the CUDA Toolkit; however, until more
extensive changes have been made in our testing infra, it /may/
occasionally happen. Sorry for that. I really wish we could catch all
possible bugs before releasing.
My hope here is that this particular issue is not a /gigantic/ problem,
since it affects the non-CUDA backends, so getting a version from a
maintenance branch here is easier, because there's no inherent
dependency on CUDA; and when CUDA is needed, then the version from the
Toolkit does work.
Cheers.
@wrf3 https://github.com/wrf3: I don't quite understand what you mean
by "deletions". Can you elaborate?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/thrust/thrust/issues/962#issuecomment-480451274, or
mute the thread
https://github.com/notifications/unsubscribe-auth/ASmBtFYlhRRB_jVDjwsSck-iQKuGuyMuks5vd9ujgaJpZM4bnmpv.

Dunno if this is the same error, the error messages are different.  My
student said that 10.0 and 9.0 worked, but that 10.1 and 9.1 did not.
Since he was just starting a term project, and since I was unwilling to
lower the CUDA version on the machine for fear of breaking something, he
switched to a different project.
BTW, we're good at breaking SW here.  On 12/12/2017, I wrote a small
program that threw nvcc 9 into an infinite loop for a particular size of
array (bug ID 2034466).  9.1 fixed it.
Here's a sample of tensorflow-gpu errors:
====================
Traceback (most recent call last):
File "Lyric_CNN_1.0.py", line 13, in
import tensorflow as tf
File "/usr/local/lib/python3.6/dist-packages/tensorflow/init.py",
line 24, in
from tensorflow.python import pywrap_tensorflow  # pylint:
disable=unused-import
File
"/usr/local/lib/python3.6/dist-packages/tensorflow/python/init.py",
line 49, in
from tensorflow.python import pywrap_tensorflow
File
"/usr/local/lib/python3.6/dist-packages/tensorflow/python/pywrap_tensorflow.py",
line 74, in
raise ImportError(msg)
ImportError: Traceback (most recent call last):
File
"/usr/local/lib/python3.6/dist-packages/tensorflow/python/pywrap_tensorflow.py",
line 58, in
from tensorflow.python.pywrap_tensorflow_internal import *
File
"/usr/local/lib/python3.6/dist-packages/tensorflow/python/pywrap_tensorflow_internal.py",
line 28, in
_pywrap_tensorflow_internal = swig_import_helper()
File
"/usr/local/lib/python3.6/dist-packages/tensorflow/python/pywrap_tensorflow_internal.py",
line 24, in swig_import_helper
_mod = imp.load_module('_pywrap_tensorflow_internal', fp, pathname,
description)
File "/usr/lib/python3.6/imp.py", line 243, in load_module
return load_dynamic(name, filename, file)
File "/usr/lib/python3.6/imp.py", line 343, in load_dynamic
return _load(spec)
ImportError: libcublas.so.10.0: cannot open shared object file: No such
file or directory
=======================
On 4/5/19 7:59 PM, Michał Dominiak wrote:

@wrf3 https://github.com/wrf3: also, is the tensorflow issue you've
mentioned tensorflow/tensorflow#26155
https://github.com/tensorflow/tensorflow/issues/26155? If so, then our
team has also been bit by that compiler bug ;)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/thrust/thrust/issues/962#issuecomment-480455220, or
mute the thread
https://github.com/notifications/unsubscribe-auth/ASmBtOP5nvwICeyGmgRWpIE08KhMnQlJks5vd-NOgaJpZM4bnmpv.

I see that CUDA 10.1 Update 2 is out now, but the release notes are a bit sparse. Did it indeed pick up this fix? It would be super helpful if these bugs could be tagged with the release they are slated for / part of.

Is this bug still present on CUDA 10.2? I'm experiencing the same situation!

@carlidel I was told by @griwes that this fix somehow didn't make it into 10.2 either and we'll just have to wait till CUDA 11 before any of the non-CUDA Thrust backends work again. Of course you can also check out the library from here and load it directly to get the fix. Personally I'm still on 9.2 until 11 comes out because of this problem.

Thanks, in the end I was able to get back the funtionalities I needed by directly commenting out the broken parts of the code.It’s not something I would suggest of course, but I just needed a quick thrust environment for experimenting things…

authors: carlidel elalish griwes wrf3

repo: thrust/thrust

license_source: bigquery


text:
About the details of datasets

Hi,
I've downloaded the all_datasets.zip from cloud you mentioned in readme, while where can I get detailed information about the dataset? For example, the traffic.csv under traffic folder seems nor attached readme file neither ref link, but every line is composed from hundreds fields.
Hope to get reply soon. Thanks a lot.
David

Hi, we include the dataset description in our previous paper: Autoformer
https://arxiv.org/pdf/2106.13008

repo: thuml/Time-Series-Library


text:
Change IMAP and SMTP passwords in a single step

Checklist

[X] I have used the search function to see if someone else has already submitted the same feature request.
[X] I will describe the problem with as much detail as possible.
[X] This issue only contains a request for one single feature, not multiple (related) features.

App version
6.202
Problem you are trying to solve
As most users, my password for IMAP and SMTP is the same.  When I change it, I have to adjust K9 mail on two places.
Suggested solution
Once the user changes the Incoming password, K9 shall offer the user (in a yes/no dialog)  to change also internally the Outgoing password.  And vice versa.
Screenshots / Drawings / Technical details
No response

Duplicate of #4422

authors: cketti dilyanpalauzov


text:
magix的事件代理

先说普通事件代理，以jQuery为例
$(document.body).on('click','p',function(e){

});

这样其实是为document.body上绑定一个click事件，当鼠标在页面上点击时，看点击的元素是否是p元素,如果是则触发，不是则向从当前节点向上查找到符合的p元素，一直查到body。这里其实是有性能问题的(jQuery已经弃用的live)，稍后我们再讨论并给出解决方案。
事件代理其实就是把事件处理函数绑定在父级，通过事件冒泡的特点，识别触发事件的元素是否是自已期望的元素。对，重点是这个事件冒泡
Magix中的事件代理的过程是这样的：把相应的事件绑定在父节点后，当事件发生在父节点里，父节点的事件处理函数被调用后，从触发事件的节点(target)开始，判断节点是否有mx-eventType属性，如果有则停下来调用相应view的事件处理函数，如果没有则向上查找，直到父节点
再来看Magix1.0之前的事件代理方案
当前view使用的事件都统一绑定到vframe根节点上，而vframe又可以嵌套，比如嵌套后的结构如下：

我们的事件是绑定在vframe上的，当vframe2与vframe1绑定相同类型的事件时，比如click，而vframe2的view与vframe1的view具有相同的事件处理函数时，比如selectAll，那么问题就来了：鼠标点击在vframe2的SelectAll checkbox上时，vframe2先处理，而同时事件冒泡，冒泡到vframe1上时，vframe1的selectAll方法同样会被触发。
这里因为vframe1节点与vframe2节点都绑定了click事件，而由于事件冒泡的原因，同时事件类型及方法名又一致，当点击在vframe2内部时，vframe2处理完事件向上冒泡到vframe1，导致vframe1又处理了一遍，那或许你会说为什么不取消事件冒泡呢？
因为在我们的项目中，我们有可能引入其它组件，比如弹出日历等，需要鼠标点击在页面其它位置时日历需要隐藏消失。所以我们不能直接就把事件冒泡取消，否则日历也无法隐藏(像日历这种通常是绑定在document，需要相关事件冒泡到document)
问题出来了总得有个解决办法
第1个解决方案：
明确事件的处理vframe，类似上图，当鼠标点击在vframe2时，当vframe2处理完事件后，给打一个标记，标明当前事件是被处理过的，当vframe1收到后，先判断是否是处理过的，如果是处理过则不再理会
说到这里，大家可以想象一下，如果嵌套的vframe比较多时，鼠标点击在最内部的vframe时，由于事件冒泡，冒泡到每一层的vframe时，这一层的vframe都需要对事件做一次判断，而这些判断其实是不必要的，因为事件已经被内部vframe处理了，为什么还在再次判断？这地方多少会有些性能损耗
第2个解决方案：
把代理节点提高到body上，如果事件代理在body上而不是vframe上，把注册在vframe上相同的监听统一合并到body上，这样vframe节点不需要注册任何事件，对于嵌套的vframe，也是统一在body上处理事件，不需要每一层vframe的判断了。
该方案所有事件在绑定时，不管什么事件类型都绑定的是同一个事件处理函数，在这个事件处理函数内部再决定调用哪一个view的处理函数。内部针对magix的特点，对事件这块再特殊优化，从而提升性能，原理接下来讨论
回到开头我们的那个问题(jQuery live)：事件是绑定在body上的，每当事件发生时，我们都要从发生事件的节点向上查找带有mx-eventType标识的节点，直到body。那我们来看一种情况：

假设html结构是这样的：

    div1

        div2
        <button mx-click="save()">Save</button>

document.body注册了一个click事件，当鼠标点击在button上时，target即符合我们的要求(带有mx-click属性)，所以不再向上查找，把button转交给相应的vframe去处理，而如果点击在button外部时，由于div不带mx-click属性，则会一直向上查找，直到body，而如果这种嵌套比较深的话，每次点击在button外部时，都需要从里至外的查找到body，性能上肯定不乐观，如何提升这块的性能 ？
我们发现不管是点击在div2内部还是div1内部，从事件触发的节点到body这条路径上是没有带mx-eventType属性的节点的，所以在向上查找的过程中，会把整条路径上的节点都记录下来，如果到body还未找到带mx-eventType的节点，则会把这些节点都标记上不需要处理click事件。
表明从这个节点向上是没有带mx-eventType属性的节点的，当下次再点击时，首先看当前这个节点是否已经被标识，如果被标识没有eventType类型的事件，则不再向上查找
由于Maigx事件本身是代理进行的，直接在期望的节点上写mx-event即可，最好不要出现类似这样的代码：

A

B

C

直接在li上面写mx-click即可，如果是在ul节点上，Magix本身需要从事件触发的节点向上找到带mx-eventType，开发者还需要从target再来判断一次事件触发节点是否是期望的li，从而拉低了性能。
经过上述方案后，对于高频事件比如mousemove也能很好的应对，不至于鼠标在页面内快速移动而造成CPU瞬间上升

在真实绑定事件的时候，Magix对接的是类库的事件绑定，如使用jQuery类库则调用jQuery的事件绑定机制进行绑定。
Magix在绑定的时候有如下优化：

无论多少个view，也无论每个view绑定多少个不同类型的事件，Magix只会调用一次类库事件的绑定方法。即不同的事件类型绑定的也是同一个Magix内部的事件处理方法
当某个事件发生时，Magix内部事件处理方法根据Magix的view嵌套关系特点，快速的找到对应的处理view，进而调用对应的方法

用图表示如下：

简单聊下jQuery的事件绑定，如图，当我们绑定click1,click2,click3,三个事件处理函数时，调用jquery的事件绑定方法，它内部会用把click1,click2,click3放到这个eventList数组里，而真实绑定的则是eventHandle的内部方法，当事件发生时，再循环调用eventList里面的回调函数

Magix的事件绑定，没有eventList来存储回调函数，而是当事件发生时，根据view之间的关系，快速寻找到对应的view。同时可避免不必要的检测，如点击在vf4区域内时，vf3则不会被检测

我们发现不管是点击在div2内部还是div1内部，从事件触发的节点到body这条路径上是没有带mx-eventType属性的节点的，所以在向上查找的过程中，会把整条路径上的节点都记录下来，如果到body还未找到带mx-eventType的节点，则会把这些节点都标记上不需要处理click事件。

这段话没能理解╮(╯_╰)╭

authors: sprying xinglie

repo: thx/magix


text:
[approve]: the suggestion comments make author easily misunderstood

the suggestion comment should be "all" logic not "any" logic.
expect: "please assign both X and Y for approvals".

The sentence "please assign ywqzzy, tangenta, eason7 for approval" could potentially lead to ambiguity, as it might imply that approval from any one of the three individuals would be sufficient. To eliminate any confusion and clarify that approval is required from all three individuals, you could rephrase the instruction as follows:
"please assign ywqzzy, tangenta, eason7  for approval, ensuring that each of them provides their approval before proceeding"

authors: purelind wuhuizuo

repo: ti-community-infra/test-infra


text:
[Docs] Incorrect link in SQL Databases Tutorial (Alembic Note )

Discussed in https://github.com/tiangolo/fastapi/discussions/10944

Originally posted by micallefdaniel January 12, 2024
First Check

[X] I added a very descriptive title here.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I searched the FastAPI documentation, with the integrated search.
[X] I already searched in Google "How to X in FastAPI" and didn't find any information.
[X] I already read and followed all the tutorial in the docs and didn't find an answer.
[X] I already checked if it is not related to FastAPI but to Pydantic.
[X] I already checked if it is not related to FastAPI but to Swagger UI.
[X] I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

[X] I commit to help with one of those options 👆

Example Code
You can find an example of Alembic in a FastAPI project in the templates from [Project Generation - Template](../project-generation.md){.internal-link target=_blank}. Specifically in the `alembic` directory in the source code.

Description
Link to Alembic example in SQL Databases Tutorial is broken after merging Discard Cookiecutter PR.
the `alembic` directory in the source code.

Should be changed to:
the `alembic` directory in the source code.

Operating System
Linux, Windows, macOS
Operating System Details
N/A
FastAPI Version
0.109.0
Pydantic Version
2
Python Version
3.10
Additional Context
N/A

This was solved in https://github.com/tiangolo/fastapi/pull/10716 🪄

authors: Kludex alejsdev

repo: tiangolo/fastapi


text:
✨ Enable Pydantic's serialization mode for responses, add support for Pydantic's computed_field, better OpenAPI for response models, proper required attributes, better generated clients

✨ Enable Pydantic's serialization mode for responses, add support for Pydantic's computed_field.
Ref: https://docs.pydantic.dev/latest/usage/computed_fields/

@tiangolo This change seems to break parts of OpenAPI / JSONSchema generation.
Specifically, fields that should not be "required" in the schema now are.
Simple repro:
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel):
    name: str
    price: float
    is_offer: None | bool = None

@app.get("/item", response_model=Item)
async def get_item():
    return {
        "name": "Foo",
        "price": 42.0,
        "is_offer": True,
    }

In the above, the generated schema for the Item model has is_offer listed in the required field of the JSON schema, even though the docs for Pydantic 2 indicate that this should not be required, and it was working as expected in FastAPI 0.100.x
Can make a separate issue for this, but thought I'd post here first.

same problem。

authors: acnebs goda-kazuki tiangolo


text:
🌐 Add German translation for docs/de/docs/index.md, docs/de/docs/fastapi-people.md, and docs/de/docs/python-types.md

Hello,
I have started to translate the documentation into german (to be honest, I was a bit surprised that nothing existed here yet).
Currently I have translated the following chapters.

index
features
fastapi-people
python-types

I thought to translate them piece by piece just following the order of the mkdocs nav.
Since I have never worked with MkDocs, I hope the "setup" for the german section is correct.
P.S.: Please don't be surprised about the short time intervals of the commits. No, I am not so fast in translating - It took me a while. I only had a bad setup near the end and had to reset everything. .

This is awesome @0x4Dark! :rocket: You have done a lot of work! :bow: :clap:
I have to wait for a couple of reviews before merging it. And as it has translations for several files, it will probably be difficult for someone to translate them all at the same time.

Let me suggest, could you split it into several PRs?
One would be just the basic setup, without any translation, just the result of:
$ python ./scripts/docs.py new-lang de

And then a new PR for each file translated. That way, even if there are some changes for some of them, maybe one of them is already perfect and can be approved and merged faster.

Hi all,
Unfortunately, had the last few months no time to continue working on it and then forgot. Too many projects (of course with FastAPI).
Thanks for the feedback @AaronDewes.
@tiangolo I can do that, no problem. I'll work the changes from AaronDewes and create the pull requests asap.

I updated it with recent changes, there's no longer need to use and synchronize complex mkdocs.yml files. I also removed the files that were already translated in other PRs and resolved the conflicts.
Nevertheless, it would probably be easier and better to have these 3 files in 3 different PRs so that it's easier to review them, and once one of the files is fine and approved (even if the other two are not), I could merge that if it was in an isolated PR.
As I know you're busy, maybe others might want to copy some of the work done here in one of these files and make a new PR only for that one, and continue from there. 🤓

📝 Docs preview for commit dd3d8a5f2ac9bd1e1f1dfadf282a64643d96d689 at: https://649a06e4d1bbbc073560fbdb--fastapi.netlify.app

As this is now being handled in 3 independent PRs at https://github.com/tiangolo/fastapi/pull/9502, https://github.com/tiangolo/fastapi/pull/10287, https://github.com/tiangolo/fastapi/pull/10285, I'm gonna close this one. Thanks everyone! 🚀


text:
TicDat.init from pandas.DataFrame doesn't fill in data fields

Since PanDat.__init__ does this, there is a reasonable workaround.

will fill in all missing fields for whom there is a default value

repo: ticdat/ticdat


text:
format google style

format unformatted files.
use mvn format and git diff --quiet to check.
git ignore parser-generated files.

/build

/run-all-tests

repo: tidb-incubator/TiBigData


text:
Find CSS properties that aren't in the tables

I'm not really sure if this is a good idea (versus just having people look through dfns to get the complete list of all properties), but I wrote this so it exists now 🤷🏻 Opinions welcome, etc.

The CSS extracts should contain all CSS properties and, ideally, there should be no diff between the list of CSS properties in the CSS extract and the list of CSS properties in the dfn extract. In other words, this pull request is needed :)
This code would add the following properties:

stop-color and stop-opacity in SVG. It would actually be good to add custom extraction code for these definitions. That can be done separately though.
All -webkit-* property aliases in Compat.
Legacy Gap Properties in CSS Box Alignment.
The legacy -webkit-user-select and -webkit-appearance properties in CSS Basic User Interface.
The legacy -webkit-line-clamp property in CSS Overflow.

That all looks good.
One problem is that this would also add the property-name example in CSS 2, and the --* family of properties in CSS Variables. These properties don't really exist, so it does not make sense to include them in the CSS extracts. They are hardcoded in the CSS extraction code. They probably have to be hardcoded here as well. Could you update the pull request accordingly? (The specs themselves should perhaps be updated since the definitions should actually not really be flagged as "property" dfns).
Out of curiosity, I also checked whether all CSS properties in the CSS extracts have corresponding entries in the dfns extract. That seems to be the case!

stop-color and stop-opacity in SVG. It would actually be good to add custom extraction code for these definitions. That can be done separately though.

Or someone should update the spec! 🙃

(The specs themselves should perhaps be updated since the definitions should actually not really be flagged as "property" dfns).

Alas, given they're generated the same way as the other propdef my brief look at avoiding this in Bikeshed was… difficult. But probably worth filing an issue.

One problem is that this would also add the property-name example in CSS 2, and the --* family of properties in CSS Variables. These properties don't really exist, so it does not make sense to include them in the CSS extracts. They are hardcoded in the CSS extraction code. They probably have to be hardcoded here as well. Could you update the pull request accordingly?

I updated the pull request to exclude property-name and --* from the CSS extracts.

authors: gsnedders tidoust

repo: tidoust/reffy

license: mit


text:
refactor(hesai_hw_interface): remove mention of Velodyne sensors in Hesai code

NebulaModelToHesaiModelNo was explicitly handling Velodyne models, while it should really just handle everything that is not Hesai the same. Because of this, PR #77 and future sensor additions cause warnings in this piece of code (enum value XYZ not handled).
PR Type

Improvement

Description
The function on question now has a generic default case for any non-Hesai sensors. Functionally it is exactly the same as before.
Review Procedure
Confirm there are no build warnings like "Enum value XYZW not handled in switch statement", confirm in the diff that the code is equivalent.
Pre-Review Checklist for the PR Author
PR Author should check the checkboxes below when creating the PR.

[x] Assign PR to reviewer

Checklist for the PR Reviewer
Reviewers should check the checkboxes below before approval.

[ ] Commits are properly organized and messages are according to the guideline
[ ] (Optional) Unit tests have been written for new behavior
[ ] PR title describes the changes

Post-Review Checklist for the PR Author
PR Author should check the checkboxes below before merging.

[ ] All open points are addressed and tracked via issues or tickets

CI Checks

Build and test for PR: Required to pass before the merge.

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

Comparison is base (71e7d0e) 8.29% compared to head (0f22ed8) 3.96%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff            @@
##            main    #100      +/-   ##
========================================
- Coverage   8.29%   3.96%   -4.33%
========================================
  Files         87      27      -60
  Lines       8455    5952    -2503
  Branches     852     463     -389
========================================
- Hits         701     236     -465
+ Misses      7179    5304    -1875
+ Partials     575     412     -163

Flag
Coverage Δ

differential
3.96% <ø> (?)

total
?

Flags with carried forward coverage won't be shown. Click here to find out more.

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

authors: codecov-commenter mojomex


text:
Spike blocks should not be TileEntity's.

And the reason why is that people might want to place a lot of spikes and they will be pissed when the game starts slowing down, because right now Spike blocks are TileEntities. That is not okay.
Generally: Do not make blocks TileEntities if there is a chance that there will be a lot of them placed in the world.

Make block models for the different states of a Spike (e.g: ON_UP, ON_DOWN, OFF_UP, ...).
Turn the Spike blocks (TCBlockContainer) back into normal blocks (TCBlock) and add two blockstates ACTIVE and DIRECTION.
Make the trigger method simply toggle the ACTIVE blockstate and run a block update without updating the neighbouring blocks.
Make the rendering of Spike blocks use the previously made block models.
Either give the Spike block a simple GUI to change the blockstates or use a existing tool.
Done.

Done

repo: tiffit/TaleCraft


text:
DOCS-1942-product-comparison-table

PR to update table to show OSS capabilities in comparison with CE and CC.
Product Version(s):
CC 18, 19
CE 3.19, 3.18, 3.17
OSS 3.27, 3.26
Issue:
https://tigera.atlassian.net/browse/DOCS-1942
Link to docs preview:
https://deploy-preview-1244--tigera.netlify.app/calico/latest/about/product-comparison
SME review:

[ ] An SME has approved this change.

DOCS review:

[ ] A member of the docs team has approved this change.

Additional information:

Merge checklist:

[ ] Deploy preview inspected wherever changes were made
[ ] Build completed successfully
[ ] Test have passed

@tmjd Vaibov said you would be the best reviewer for section called, Cluster mesh for CC. The initial request was from Reza to show that OSS does support native cluster mesh (as described in his blog here: https://www.tigera.io/blog/deep-dive/what-is-a-kubernetes-cluster-mesh-and-what-are-the-benefits/). Open to rephrasing the items.

Bringing the product names down through the table is a clear win. Very nice!

Looks fine to me now. Though I'm assuming you'll be copying those updates to the unversioned/main calico version of that doc.
I'll leave this for someone else to approve since I'm not sure if I'm the last one to review or not.

@tmjd Top of the PR shows all of the places I need to copy this doc to. Just waiting for Phil to do a quick review. Thanks much the review.

authors: bmckercher123 ctauchen tmjd

repo: tigera/docs


text:
waf integration fixes / improvements

Description
This PR changes how coreruleset rules are delivered as part of the WAF integration

add unit testing for WAF render
remove embedded coreruleset. this greatly reduces the size of the config map rendered by operator.
leaving only one file available by default, tigera.conf
change dikastes command line flags to use coraza's direct file loading api
only reference coreruleset already installed in dikastes through a 'header' file (tigera.conf)

remove -waf-directive flags, swap with -waf-ruleset-file flag
remove -waf-ruleset-base-dir because DirFS didn't work as expected

For PR author

[ ] Tests for change.
[ ] If changing pkg/apis/, run make gen-files
[ ] If changing versions, run make gen-versions

For PR reviewers
A note for code reviewers - all pull requests must have the following:

[ ] Milestone set according to targeted release.
[ ] Appropriate labels:

kind/bug if this is a bugfix.
kind/enhancement if this is a a new feature.
enterprise if this PR applies to Calico Enterprise only.

Could you explain a bit further about this?

change dikastes command line flags to use coraza's direct file loading api

Primarily I'm wondering if this has impact on clusters that don't have internet access.
Another way to ask what I'm curious about is, how does dikastes fetch the ruleset data that is being removed in this PR?
Another thing I'm curious about, does this change what happens during upgrades? I think before this PR the ruleset gets installed/cached and then with future updates the existing ruleset would be used (I'm not sure about this behavior but it would match the behavior I usually expect with the operator). My thinking is that now if dikastes is fetching this data (or it is builtin) then I would think the data could change/update when upgrading.

@tmjd sorry for the confusion, I typically call it API because it's an 'application programming interface' within the code.. not necessarily an API endpoint.
in this case I meant to say that it that just means that in dikastes we're just loading the file directly instead of using a Include <path-to-file> directive. e.g.:
from
-waf-directive "Include /etc/modsecurity-ruleset/tigera.conf"

to
-waf-ruleset-file /etc/modsecurity-ruleset/tigera.conf

tigera.conf is still a file mounted via config map, then used in that CLI flag
the rest of the core ruleset files are embedded within the dikastes binary, see here:
nothing is loaded via internet access

I discussed this a bit with @electricjesus and the intention is that when a user upgrades the ruleset will be updated along with the upgrade.

authors: electricjesus tmjd

repo: tigera/operator


text:
Remove old operator bundles [v1.36]

These operator bundles are not necessary for us to keep around, so in the interests of cleaning up the repository we can just remove them. Cherry-pick of #3582.

I'm sorry but I failed delete the branch after merging the pull request.

authors: danudey marvin-tigera


text:
Add import statement for Stream in index.d.ts

FIX ERROR
yarn run v1.22.19
$ tsc && tsc-alias
node_modules/node-color-log/index.d.ts:28:26 - error TS2304: Cannot find name 'Stream'.
28     setLogStream(stream: Stream): Logger;
~~~~~~
Found 1 error in node_modules/node-color-log/index.d.ts:28
error Command failed with exit code 2.

@febrimaulana  thanks

authors: febrimaulana tigercosmos

repo: tigercosmos/node-color-log


text:
Select mavlink logging only if there is no SD card available

Configure logger to use mavlink logging only in case SDCARD not available/accessible

Verified with Saluki-v2:
px4 amp:
1814  1814 230 RR       Task    --- Waiting  Semaphore 0000000000000000 007248 002688  37.0%  logger start -b 8 -t -m mavlink
px4 default:
 1391  1391 230 RR       Task    --- Waiting  Semaphore 0000000000000000 007264 003728  51.3%  logger start -b 8 -t


text:
Detach the delivery of Ready from the call to tick() to reduce commit latency.

Is your feature request related to a problem? Please describe.
With the current implementation, the commit delay is tied to the heartbeat interval, because the only way for the node to send accumulated messages to peers is after calling tick().
Describe the solution you'd like
In etcd's implementation, Readys are received on a separate channel, disjoint from the ticker, which makes it possible to receive a ready that contains MsgAppendResp without waiting for the tick interval to elapse.
Describe alternatives you've considered
N/A
Additional context
Add any other context or screenshots about the feature request here.
[1]: https://github.com/etcd-io/etcd/blob/7a1cecd5fafcea03adfb11b6bed49e901cd1dcf2/contrib/raftexample/raft.go#L451
[2]: https://github.com/etcd-io/etcd/blob/ae36a577d7becbdeebf1f0fb665573b721e435f8/raft/node.go#L316

Nvm, what I missed was that one could call has_ready() separately from tick().
Please disregard.

repo: tikv/raft-rs


text:
[Dynamic Regions] TiKV OOM in tpcc 25K import data

Bug Report

What version of TiKV are you using?

nightly
What operating system and CPU are you using?

Steps to reproduce

In 8C32Core M5.2xlarge, run tpcc 25K warehouse data prepare with 128 threads.
What did you expect?
Run successfully without crash
What did happened?
TiKV OOM.
134_heap_5.pdf
134_heap_4.pdf

Grafana: http://54.189.73.225:33762/d/RDVQiEzZz/tpcc-tikv-details?orgId=1&from=1675200847691&to=1675204064867&var-k8s_cluster=&var-tidb_cluster=&var-db=All&var-command=All&var-instance=172.31.15.134:20180&var-titan_db=All

Even when tablet gc is not blocked, tikv still OOMs. So it's likely not related to tablet gc.

134_61_heap.pdf

With tablet flow control enabled, the issue is mitigated.
The root cause is that the memory flush cannot catch up the write speed and data are queued in memtable. So the memtable grows above the quota.  With flow control enabled, the pending L0 files will slow down the region's speed automatically and thus reduce the memtable's write volume.

repo: tikv/tikv


text:
Rename counter metrics?

Question

Based on the Label Naming, all counter value should have suffix _total, but I saw a lot of metrics in Tikv don't follow this. So is it necessary to rename them? I guess it may cause some compatibility issues so I am not sure if it is worthwhile.
# TYPE tikv_coprocessor_dag_request_count counter
# TYPE tikv_coprocessor_executor_count counter
# TYPE tikv_coprocessor_response_bytes counter
# TYPE tikv_coprocessor_rocksdb_perf counter
# TYPE tikv_coprocessor_scan_details counter
# TYPE tikv_engine_blob_file_synced counter
# TYPE tikv_engine_blob_flow_bytes counter
# TYPE tikv_engine_blob_gc_file_count counter
# TYPE tikv_engine_blob_gc_flow_bytes counter
# TYPE tikv_engine_blob_locate counter
# TYPE tikv_engine_bloom_efficiency counter
# TYPE tikv_engine_cache_efficiency counter
# TYPE tikv_engine_compaction_flow_bytes counter
# TYPE tikv_engine_compaction_key_drop counter
# TYPE tikv_engine_compaction_num_corrupt_keys counter
# TYPE tikv_engine_compaction_reason counter
# TYPE tikv_engine_file_status counter
# TYPE tikv_engine_flow_bytes counter
# TYPE tikv_engine_get_served counter
# TYPE tikv_engine_locate counter
# TYPE tikv_engine_memtable_efficiency counter
# TYPE tikv_engine_read_amp_flow_bytes counter
# TYPE tikv_engine_stall_micro_seconds counter
# TYPE tikv_engine_wal_file_synced counter
# TYPE tikv_engine_write_served counter
# TYPE tikv_raftstore_entry_fetches counter
# TYPE tikv_raftstore_local_read_executed_requests counter
# TYPE tikv_scheduler_kv_scan_details counter
# TYPE tikv_thread_nonvoluntary_context_switches counter
# TYPE tikv_thread_voluntary_context_switches counter

Another point I want to mention is that OpenMetrics requests all counter type metrics end with _total. I think Prometheus will also adopt it in the future.

PTAL @breeswish

@yeya24
Thank you very much, I think it is worth to follow the suggestion even the label naming is not mandatory. But the most thing I worry that is we need to change too many places, like TiKV Grafana, Alter rule, etc.
So maybe we can regulate following this for the new metrics at first.

Maybe not only counter but also some other types are not following the rule too. :-)

Agree. Changing too much place is definitely painful.

authors: Hoverbear siddontang yeya24


text:
Stop sending store report as the result of plan execution

Signed-off-by: v01dstar yang.zhang@pingcap.com

What is changed and how it works?
TiKV issue #10483
What's Changed:
This PR makes TiKV stop sending report at the end of unsafe recovery plan execution as the result, since PD can use region info reported from region heartbeats to determine whether a plan has been executed or not.
Related changes

PR to update tikv/pd: https://github.com/tikv/pd/pull/4447

Check List
Tests

Unit test

Side effects
N/A
Release note
None

/cc @Connor1996

Reimpl in https://github.com/tikv/tikv/pull/11716


text:
raftstore: trigger compaction when no valid split key can be found

What is changed and how it works?

Issue Number: Close #15282
What's Changed:

trigger compaction when no valid split key can be found

This PR handles the case where split keys cannot be found due to so many duplicated mvcc keys.
It triggers range compaction for this case but at most once for each safe point duration to avoid scheduling to many compaction tasks.
The test steps are:

prepare few rows, say 20 rows
update these 20 rows and regions will be split to 20 regions and no extra region will be splitted.
before safe point is updated, stop the workload, so no minor compaction will be performed
use pd to trigger split a region
region size decreases significantly

Related changes

PR to update pingcap/docs/pingcap/docs-cn:
Need to cherry-pick to the release branch

Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)

Release note
None

/test

/merge

/test


text:
cherry pick #5270

cherry pick #5270

/run-all-tests

/run-all-tests

/run-all-tests

/test

authors: 5kbpers hicqu zhouqiang-cl


text:
metrics: grafana dashboards support multiple cluster

What problem does this PR solve?
Many users(come from DBaaS、operator、tiup) monitor multiple TiDB clusters in one Grafana, this PR make Grafana dashboards support multiple clusters and not affect single cluster usage. Cluster variable is hidden by default.
What is changed and how it works?

add a tidb_cluster label in all expr
add cluster variable in Grafana templating

How it Works:
load it to your Grafana :))
Single Cluster:
No change
Multiple Cluster:
Construct a label that can uniquely identify the cluster. in tidb_operator, you can use {namespace}-{cluster_name} as your {tidb_cluster} variable.
add this configuration to your prometheus config
relabel_configs:
  - source_labels:
      - namespace
      - name
    separator: "-"
    target_label: tidb_cluster

Related changes

https://github.com/pingcap/tidb/pull/22503/files

Check List
Tests

No code

Side effects

No effects

Release note

metrics: grafana dashboards support multiple clusters

/cc @tennix @breeswish @AstroProfundis @DanielZhangQD

/cc @tennix @breeswish @AstroProfundis @DanielZhangQD

/label needs-cherry-pick-4.0

/label needs-cherry-pick-4.0

https://github.com/pingcap/tidb/pull/22534

https://github.com/pingcap/tidb/pull/22534

/run-all-tests

/run-all-tests

/run-all-tests

/run-all-tests

/run-all-tests

/run-all-tests

/lgtm

/lgtm

/merge

/merge


text:
RSVP doesn't work right with 'await'

I've been struggling with an issue we have for the past few days. It seems to go away when I don't use await with RSVP.all/hash. I still cannot create a reproduction (will post it here if I manage) but we do something like:
class Foo
  constructor: ->
    @loading = {}
    @loading.c = @find()
    @wait()

  findHelper: (properties) ->
    result = for property in properties
      promise = new Ember.RSVP.Promise (resolve) ->
        setTimeout ->
          resolve()
        , 2000
      @loading[property] = promise.then ->
        console.log 'resolved'
    Ember.RSVP.all(result)

  find: ->
    a = @findHelper([])
    b = @findHelper(['a', 'b'])
    await Ember.RSVP.hash({ a, b })
    Ember.RSVP.resolve()

  wait: ->
    await Ember.RSVP.hash(@loading)
    console.log 'done awaiting'

The issue in our case is that done awaiting is printed before resolved. In this test case it doesn't but in our code it does. :) That is, when the wait method is called, @loading contains the two promises that were set in findHelper but awaiting them doesn't actually do that.
If we change the 2 awaits to .thens then it works fine. Can you see anything wrong that we should not be doing?
Another question - awaiting a promise returns a native promise rather than an RSVP one. This is in the context of an Ember app. Can this be changed somehow?

No, in an ember app it requires an RSVP promise because RSVP is monkey patched to handle an ember run loop. Native promise do not have this. There is history concerning this at https://github.com/emberjs/rfcs/issues/175 but unfortunately it is unlikely to have a solution.
Good news is that there is a very usable and helpful workaround with the ember-co addon which works great for this very use case.

Another question - awaiting a promise returns a native promise rather than an RSVP one. This is in the context of an Ember app. Can this be changed somehow?

I don't believe this can be changed currently.

@boris-petrov can you provide a runnable example? I will gladly debug if one is provide

@stefanpenner - about the first thing - isn't doing a:
import { Promise } from 'rsvp'

export default
  name: 'promise'
  initialize: ->
    window.Promise = Promise

Doing that?
About the second thing - I really tried hard reproducing the problem but could not find a short version (or one that I can publish). :( I currently don't have the time to try again. If you prefer, you could close the issue and I will create a new one if/when I manage with a reproduction. Or hopefully the problem just goes away by itself.

import { Promise } from 'rsvp'
export default
name: 'promise'
initialize: ->
window.Promise = Promise
Doing exactly that?

I don't believe so, not with Native AsyncAwait at-least (potentially though with polyfills)

If you prefer, you could close the issue and I will create a new one if/when I manage with a reproduction. Or hopefully the problem just goes away by itself.

Unfortunately I think I will need to. I tried some experiments and was also unable to find an issue...
I will gladly reopen if I can get further info/reproduction, but currently I am not sure what I can do. :(

authors: boris-petrov stefanpenner sukima


text:
Great Lakes bathymetry

https://www.ngdc.noaa.gov/mgg/greatlakes/
http://www.glerl.noaa.gov/data/bathy/bathy.html
(ported from https://github.com/valhalla/skadi/issues/26)

List files
There's only 5 of them, so here they are:
cat > mgg_greatlakes_listing.txt << EOF
https://www.ngdc.noaa.gov/mgg/greatlakes/erie/data/geotiff/erie_lld.geotiff.tar.gz
https://www.ngdc.noaa.gov/mgg/greatlakes/huron/data/geotiff/huron_lld.geotiff.tar.gz
https://www.ngdc.noaa.gov/mgg/greatlakes/michigan/data/geotiff/michigan_lld.geotiff.tar.gz
https://www.ngdc.noaa.gov/mgg/greatlakes/ontario/data/geotiff/ontario_lld.geotiff.tar.gz
https://www.ngdc.noaa.gov/mgg/greatlakes/superior/data/geotiff/superior_lld.geotiff.tar.gz
EOF

Mirror files
cat mgg_greatlakes_listing.txt \
    | xargs \
      -I {} \
      -P 24 \
      -n 1 \
      sh -c 'export f="{}"; export s3="s3://elevation-sources-prod/mgg_greatlakes/`basename $f`"; curl -s $f | AWS_DEFAULT_PROFILE=openterrain aws s3 cp - $s3; echo $s3' \
    | tee mgg_greatlakes_s3_objects.txt

Transcode files
cat mgg_greatlakes_s3_objects.txt | \
while read filename; do
    bn=$(basename $filename)
   make submit-job job=aws/transcode-job.json.hbs input=${filename} output=s3://elevation-sources-transcoded/mgg_greatlakes/$(sed 's/\.geotiff\.tar\.gz//' <<< $bn) name=$(sed 's/\.geotiff\.tar\.gz//' <<< $bn)
done

These jobs failed because the transcoder didn't properly handle the .tar.gz extension.

We finally got these in, but when the tiler tries to composite with them, it fails for some reason and 500s. I'll take a closer look later.

I just re-transcoded these and they don't break the tiler anymore, but they also aren't showing up over the top of ned13, which doesn't seem to have holes cut out for the Great Lakes.

change their priority to -1?
On Thu, Jul 13, 2017 at 2:00 PM, Ian Dees notifications@github.com wrote:

I just re-transcoded these and they don't break the tiler anymore, but
they also aren't showing up over the top of ned13, which doesn't seem to
have holes cut out for the Great Lakes.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/tilezen/joerd/issues/23#issuecomment-315200895, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA0EOyNqS3Cnj_VEnMQLP0bAvmaxuDX4ks5sNoVjgaJpZM4HWqm8
.

That helps. It looks like vertical measurements are unexpected though, because there's a hillshade border around the data:

(southern end of Lake Michigan)

Does it need a different clip? Where could we do that?

I'm going to disable this for now. I haven't figured out a way to get rid of the stripe and the resolution isn't all that great anyway.

footprints=> update footprints set enabled=false where source='mgg_greatlakes';
UPDATE 8

Re-opening for a rainy day.

Info for rainy day. These DEMs each have individual vertical offsets, I think maybe their zero height datum is the mean surface level of each lake? The offset data is available from NOAA or pre-digested in Joerd v1.

Thanks!

authors: iandees nvkelso zerebubuth

repo: tilezen/joerd


text:
Sync config file across devices (Chrome & Firefox)

Hi,
It would be very nice if we could sync the config file using Chrome Sync or Firefox Sync across multiple devices: laptop @ home and laptop @ work.
Thanks!

@z0ph Your setting is synchronized if you sign in to the both browsers with the same chrome / firefox user.

I'm sign-in with the same account and no, I've to copy past my settings across browsers. (Chrome to Chrome and Firefox to Firefox). Did I miss something?

@z0ph Is the item for the extension turned on in your chrome://settings/syncSetup/advanced ?

Yes,

On both computers.

It turned out that the settings displayed in the textarea were not synchronized. However, the actual profile settings were synchronized on background.

repo: tilfin/aws-extend-switch-roles


text:
Which branch is the available tilia Phoenix Connect

Hi David,
at vividads, I keep getting this error message:
Dynamic property 'SelectedSheets' has invalid value 'Corflute/5 mm/2450 × 1230mm Long'
However, when I check the code inside the function isPropertyValid there is no catch for this property and a value of true gets returned.
Is the code of the App different from this repo?
best
Peter

@pkleinheider - I'm investigating this issue via the Tilia Labs Help Desk. The User should follow up with you afterwards directly.
The main branch should be the exact same code as the latest version on the Enfocus App Store

authors: pkleinheider tiliadavid

repo: tilialabs/tilia-phoenix-connect


text:
Set up with Appveyor

#6  Needs completed first.

I didn't know you could use mingw with Appveyor. I will have to look into this to actually implement it. If you know an example, please leave a link <3

repo: tilkinsc/LuaConsole


text:
Crash on startup

[localhost:sync] Starting gut-sync between /home/hari/work and hari@100.1x.xx.xx[39m:~/work/.
[localhost:daemon] fatal: Uh oh. Your system reports no Gut commands at all.
[:init] warning: templates not found /home/ubuntu/.guts/gut-build/share/gut-core/templates
[:init] Initialized empty Gut repository in /home/hari/work/.gut/
[:fetch] Fetching changes to 100.xx.x.x....
[1] Error on reverse-tunnel dial: dial tcp 127.0.0.1:34754: getsockopt: connection refused
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x20 pc=0x4ee651]
goroutine 405 [running]:
io.copyBuffer(0x7f05f59b2c90, 0xc8204f0000, 0x0, 0x0, 0xc8204fc000, 0x8000, 0x8000, 0x0, 0x0, 0x0)
/home/ubuntu/go/src/io/io.go:381 +0x241
io.Copy(0x7f05f59b2c90, 0xc8204f0000, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/ubuntu/go/src/io/io.go:351 +0x64
github.com/tillberg/bismuth.ExecContext.ReverseTunnel.func1.1.1(0x7f05f40ee4f8, 0xc8204f0000, 0x0, 0x0, 0xc8201bc4d0, 0xc8204a6fc0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:492 +0xc9
created by github.com/tillberg/bismuth.ExecContext.ReverseTunnel.func1.1
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:497 +0x23f
goroutine 1 [chan receive]:
main.Sync.func2()
/home/ubuntu/work/go/src/github.com/tillberg/gut/shell.go:175 +0x51
main.Sync(0xc82000f650, 0xc8200340d0, 0x1, 0x1, 0x0, 0x0)
/home/ubuntu/work/go/src/github.com/tillberg/gut/shell.go:318 +0x1188
main.main()
/home/ubuntu/work/go/src/github.com/tillberg/gut/shell.go:709 +0x13f0
goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/home/ubuntu/go/src/runtime/asm_amd64.s:1696 +0x1
goroutine 5 [syscall]:
os/signal.loop()
/home/ubuntu/go/src/os/signal/signal_unix.go:22 +0x18
created by os/signal.init.1
/home/ubuntu/go/src/os/signal/signal_unix.go:28 +0x37
goroutine 6 [select, locked to thread]:
runtime.gopark(0x7f24e0, 0xc820032728, 0x7655b8, 0x6, 0x44e618, 0x2)
/home/ubuntu/go/src/runtime/proc.go:185 +0x163
runtime.selectgoImpl(0xc820032728, 0x0, 0x18)
/home/ubuntu/go/src/runtime/select.go:392 +0xa64
runtime.selectgo(0xc820032728)
/home/ubuntu/go/src/runtime/select.go:212 +0x12
runtime.ensureSigM.func1()
/home/ubuntu/go/src/runtime/signal1_unix.go:227 +0x353
runtime.goexit()
/home/ubuntu/go/src/runtime/asm_amd64.s:1696 +0x1
goroutine 7 [chan receive]:
main.main.func1(0xc8200146c0)
/home/ubuntu/work/go/src/github.com/tillberg/gut/shell.go:635 +0x36
created by main.main
/home/ubuntu/work/go/src/github.com/tillberg/gut/shell.go:637 +0xd9b
goroutine 402 [select]:
github.com/tillberg/bismuth.callClosers(0xc8203fb200)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 400 [chan receive]:
github.com/tillberg/bismuth.SessionBuffer.func1(0x7f05f40ee2b0, 0xc8203fd440, 0xc8203fb620, 0xc8203fb680)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:651 +0x153
created by github.com/tillberg/bismuth.(*ExecContext).StartSession
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:562 +0x223
goroutine 35 [select]:
github.com/tillberg/bismuth.callClosers(0xc8200de900)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 95 [select]:
github.com/tillberg/bismuth.callClosers(0xc820015260)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 69 [chan receive]:
golang.org/x/crypto/ssh.(*Client).handleGlobalRequests(0xc8201c7340, 0xc820144f60)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/client.go:137 +0x4a
created by golang.org/x/crypto/ssh.NewClient
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/client.go:54 +0xe4
goroutine 118 [select]:
github.com/tillberg/bismuth.callClosers(0xc8201452c0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 26 [select]:
github.com/tillberg/bismuth.callClosers(0xc8200de120)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 70 [chan receive]:
golang.org/x/crypto/ssh.(*Client).handleChannelOpens(0xc8201c7340, 0xc820144ea0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/client.go:146 +0x6e
created by golang.org/x/crypto/ssh.NewClient
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/client.go:55 +0x110
goroutine 319 [select]:
github.com/tillberg/bismuth.callClosers(0xc820446780)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 34 [select]:
github.com/tillberg/bismuth.callClosers(0xc8200de4e0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 55 [select]:
github.com/tillberg/bismuth.callClosers(0xc820144120)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 312 [select]:
github.com/tillberg/bismuth.callClosers(0xc820446420)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 63 [select]:
github.com/tillberg/bismuth.callClosers(0xc8200ded20)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 13 [select]:
github.com/tillberg/bismuth.callClosers(0xc820190060)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 56 [select]:
github.com/tillberg/bismuth.callClosers(0xc820144480)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 108 [select]:
github.com/tillberg/bismuth.callClosers(0xc820191e60)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 382 [select]:
github.com/tillberg/bismuth.callClosers(0xc820447ce0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 11 [select]:
github.com/tillberg/bismuth.callClosers(0xc8200df0e0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 68 [runnable]:
golang.org/x/crypto/ssh.(*handshakeTransport).readPacket(0xc82001a1e0, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/handshake.go:124 +0x6d
golang.org/x/crypto/ssh.(*mux).onePacket(0xc82016f110, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/mux.go:224 +0x5e
golang.org/x/crypto/ssh.(*mux).loop(0xc82016f110)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/mux.go:199 +0x42
created by golang.org/x/crypto/ssh.newMux
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/mux.go:128 +0x20d
goroutine 12 [runnable]:
syscall.Syscall(0x0, 0x5, 0xc8201a2000, 0x1000, 0xffffffffffffffff, 0x0, 0xb)
/home/ubuntu/go/src/syscall/asm_linux_amd64.s:18 +0x5
syscall.read(0x5, 0xc8201a2000, 0x1000, 0x1000, 0x72, 0x0, 0x0)
/home/ubuntu/go/src/syscall/zsyscall_linux_amd64.go:783 +0x5f
syscall.Read(0x5, 0xc8201a2000, 0x1000, 0x1000, 0xed0345181, 0x0, 0x0)
/home/ubuntu/go/src/syscall/syscall_unix.go:160 +0x4d
net.(*netFD).Read(0xc8200c6460, 0xc8201a2000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
/home/ubuntu/go/src/net/fd_unix.go:228 +0x18b
net.(*conn).Read(0xc820160000, 0xc8201a2000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
/home/ubuntu/go/src/net/net.go:172 +0xe4
github.com/tillberg/bismuth.(*Conn).Read(0xc82015c040, 0xc8201a2000, 0x1000, 0x1000, 0xd3e4b27d465a22fc, 0x0, 0x0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:95 +0x1ac
bufio.(*Reader).fill(0xc820015020)
/home/ubuntu/go/src/bufio/bufio.go:97 +0x1e9
bufio.(*Reader).Read(0xc820015020, 0xc82017c920, 0x5, 0x5, 0x20, 0x0, 0x0)
/home/ubuntu/go/src/bufio/bufio.go:207 +0x260
io.ReadAtLeast(0x7f05f59b2978, 0xc820015020, 0xc82017c920, 0x5, 0x5, 0x5, 0x0, 0x0, 0x0)
/home/ubuntu/go/src/io/io.go:298 +0xe6
io.ReadFull(0x7f05f59b2978, 0xc820015020, 0xc82017c920, 0x5, 0x5, 0xc820319900, 0x0, 0x0)
/home/ubuntu/go/src/io/io.go:316 +0x62
golang.org/x/crypto/ssh.(*streamPacketCipher).readPacket(0xc82017c900, 0xc8000000c2, 0x7f05f59b2978, 0xc820015020, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/cipher.go:142 +0xc1
golang.org/x/crypto/ssh.(*connectionState).readPacket(0xc820094c60, 0xc820015020, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/transport.go:111 +0xce
golang.org/x/crypto/ssh.(*transport).readPacket(0xc820094c60, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/transport.go:107 +0x55
golang.org/x/crypto/ssh.(*handshakeTransport).readOnePacket(0xc82001a1e0, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/handshake.go:153 +0xe7
golang.org/x/crypto/ssh.(*handshakeTransport).readLoop(0xc82001a1e0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/handshake.go:133 +0x25
created by golang.org/x/crypto/ssh.newClientTransport
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/handshake.go:101 +0x31b
goroutine 419 [chan receive]:
golang.org/x/crypto/ssh.(*Session).Wait(0xc8204d4120, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/session.go:380 +0x14a
github.com/tillberg/bismuth.(*SshSession).Wait(0xc8203fd440, 0x7f1dd0, 0x0, 0x0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:139 +0x36
github.com/tillberg/bismuth.(*ExecContext).StartCmd.func1(0xc8200a7600, 0xc8200c80b0, 0x7f05f40ee2b0, 0xc8203fd440, 0xc820034278)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:530 +0xc1
created by github.com/tillberg/bismuth.(*ExecContext).StartCmd
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:543 +0x394
goroutine 313 [select]:
github.com/tillberg/bismuth.callClosers(0xc82020f140)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 94 [select]:
github.com/tillberg/bismuth.callClosers(0xc8201903c0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 146 [select]:
github.com/tillberg/bismuth.callClosers(0xc820145bc0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 401 [chan receive]:
github.com/tillberg/bismuth.(*ExecContext).SessionQuoteOut.func1(0x7f05f40ee2b0, 0xc8203fd440, 0xc8203fb620, 0xc8203fb680)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:594 +0x115
created by github.com/tillberg/bismuth.(*ExecContext).StartSession
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:562 +0x223
goroutine 117 [select]:
github.com/tillberg/bismuth.callClosers(0xc820190840)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 71 [semacquire]:
sync.runtime_Syncsemacquire(0xc8201c7310)
/home/ubuntu/go/src/runtime/sema.go:237 +0x201
sync.(*Cond).Wait(0xc8201c7300)
/home/ubuntu/go/src/sync/cond.go:62 +0x9b
golang.org/x/crypto/ssh.(*mux).Wait(0xc82016f110, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/mux.go:110 +0xb8
golang.org/x/crypto/ssh.NewClient.func1(0xc8201c7340)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/client.go:57 +0x39
created by golang.org/x/crypto/ssh.NewClient
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/client.go:59 +0x132
goroutine 72 [chan receive]:
golang.org/x/crypto/ssh.(*forwardList).handleChannels(0xc8201c7350, 0xc820144fc0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/tcpip.go:178 +0x6e
created by golang.org/x/crypto/ssh.NewClient
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/client.go:60 +0x18f
goroutine 73 [chan receive]:
github.com/tillberg/bismuth.(*ExecContext).reconnect.func1(0xc8201c7340, 0xc8200c80b0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:154 +0x88
created by github.com/tillberg/bismuth.(*ExecContext).reconnect
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:165 +0x7fd
goroutine 134 [select]:
github.com/tillberg/bismuth.callClosers(0xc820145620)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 151 [chan receive]:
main.Sync.func4.1(0xc82020ecc0, 0xc82020eba0, 0xc82000f6b0)
/home/ubuntu/work/go/src/github.com/tillberg/gut/shell.go:194 +0x36
created by main.Sync.func4
/home/ubuntu/work/go/src/github.com/tillberg/gut/shell.go:197 +0xd8
goroutine 397 [chan receive]:
golang.org/x/crypto/ssh.(*Session).wait(0xc8204d4120, 0xc8204a6de0, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/session.go:400 +0xb4
golang.org/x/crypto/ssh.newSession.func1(0xc8204d4120, 0xc8204a6de0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/session.go:558 +0x2b
created by golang.org/x/crypto/ssh.newSession
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/session.go:559 +0xde
goroutine 181 [select]:
github.com/tillberg/bismuth.callClosers(0xc820191260)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 283 [select]:
github.com/tillberg/bismuth.callClosers(0xc820446f60)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 164 [select]:
github.com/tillberg/bismuth.callClosers(0xc820190ea0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 406 [semacquire]:
sync.runtime_Syncsemacquire(0xc820467590)
/home/ubuntu/go/src/runtime/sema.go:237 +0x201
sync.(*Cond).Wait(0xc820467580)
/home/ubuntu/go/src/sync/cond.go:62 +0x9b
golang.org/x/crypto/ssh.(*buffer).Read(0xc8204651a0, 0xc8204f4000, 0x8000, 0x8000, 0x0, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/buffer.go:95 +0x339
golang.org/x/crypto/ssh.(*channel).ReadExtended(0xc8201d2600, 0xc8204f4000, 0x8000, 0x8000, 0xc800000000, 0x73e0d8, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/channel.go:349 +0x7a
golang.org/x/crypto/ssh.(*channel).Read(0xc8201d2600, 0xc8204f4000, 0x8000, 0x8000, 0x73e060, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/channel.go:526 +0x86
golang.org/x/crypto/ssh.(*tcpChanConn).Read(0xc8204f0000, 0xc8204f4000, 0x8000, 0x8000, 0x8000, 0x0, 0x0)
:257 +0x80
io.copyBuffer(0x0, 0x0, 0x7f05f40ee5d0, 0xc8204f0000, 0xc8204f4000, 0x8000, 0x8000, 0x0, 0x0, 0x0)
/home/ubuntu/go/src/io/io.go:381 +0x247
io.Copy(0x0, 0x0, 0x7f05f40ee5d0, 0xc8204f0000, 0xc8204f0000, 0x0, 0x0)
/home/ubuntu/go/src/io/io.go:351 +0x64
github.com/tillberg/bismuth.ExecContext.ReverseTunnel.func1.1.2(0x0, 0x0, 0x7f05f40ee4f8, 0xc8204f0000, 0xc8201bc4d0, 0xc8204a6fc0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:500 +0xc9
created by github.com/tillberg/bismuth.ExecContext.ReverseTunnel.func1.1
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:505 +0x29c
goroutine 324 [select]:
github.com/tillberg/bismuth.callClosers(0xc82020f500)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 150 [chan receive]:
golang.org/x/crypto/ssh.(*tcpListener).Accept(0xc820159bc0, 0x0, 0x0, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/tcpip.go:255 +0x8b
github.com/tillberg/bismuth.ExecContext.ReverseTunnel.func1(0xc82013bb00, 0xc82016a0f0, 0xc82013bad0, 0xf, 0xc8201bc4d0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:477 +0x3a
created by github.com/tillberg/bismuth.ExecContext.ReverseTunnel
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:510 +0x3cd
goroutine 279 [select]:
github.com/tillberg/bismuth.callClosers(0xc82020fc20)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 145 [select]:
github.com/tillberg/bismuth.callClosers(0xc820145f80)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 176 [chan receive]:
main.(*SyncContext).StartReverseTunnel.func1(0xc82000f6b0, 0xc82013bad0, 0xf, 0xc82013bad0, 0xf, 0xc82013baf0, 0xc82020ec60, 0xc82016a0e8)
/home/ubuntu/work/go/src/github.com/tillberg/gut/shell.go:71 +0x1f0
created by main.(*SyncContext).StartReverseTunnel
/home/ubuntu/work/go/src/github.com/tillberg/gut/shell.go:122 +0x103
goroutine 403 [chan receive]:
golang.org/x/crypto/ssh.DiscardRequests(0xc8204a6ea0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/connection.go:81 +0x4a
created by golang.org/x/crypto/ssh.(*tcpListener).Accept
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/tcpip.go:263 +0x18a
goroutine 107 [select]:
github.com/tillberg/bismuth.callClosers(0xc820191a40)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 173 [select]:
github.com/tillberg/bismuth.callClosers(0xc82020e7e0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 205 [chan send]:
github.com/tillberg/bismuth.(*ExecContext).StartSession.func2(0xc8201952d0, 0xc82024ab70, 0xc8201601a0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:574 +0x85
created by github.com/tillberg/bismuth.(*ExecContext).StartSession
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:575 +0x398
goroutine 197 [select]:
github.com/tillberg/bismuth.callClosers(0xc820015ce0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 418 [chan receive]:
github.com/tillberg/bismuth.(*ExecContext).SessionQuoteErr.func1(0x7f05f40ee2b0, 0xc8203fd440, 0xc8203fb620, 0xc8203fb680)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:605 +0x115
created by github.com/tillberg/bismuth.(*ExecContext).StartSession
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:562 +0x223
goroutine 211 [select]:
github.com/tillberg/bismuth.callClosers(0xc820015920)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 301 [select]:
github.com/tillberg/bismuth.callClosers(0xc820446060)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 177 [select]:
github.com/tillberg/bismuth.callClosers(0xc8203fa060)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 293 [chan receive]:
github.com/tillberg/bismuth.(*ExecContext).ExecSession(0xc8200c80b0, 0xc820457e30, 0x5, 0x5, 0xf, 0x0, 0x0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:584 +0xac
github.com/tillberg/bismuth.(*ExecContext).QuoteCwdBuf(0xc8200c80b0, 0x764070, 0x5, 0xc820459140, 0xf, 0xc820467380, 0x4, 0x4, 0x0, 0x0, ...)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:724 +0x26a
main.(*SyncContext).GutQuoteBuf(0xc82000f6b0, 0x764070, 0x5, 0xc820051e90, 0x3, 0x3, 0x0, 0x0, 0x0, 0x0, ...)
/home/ubuntu/work/go/src/github.com/tillberg/gut/sync_context.go:159 +0x14c
main.(*SyncContext).GutFetch(0xc82000f6b0, 0x0, 0x0)
/home/ubuntu/work/go/src/github.com/tillberg/gut/gut_cmd.go:141 +0x22e
main.(*SyncContext).GutPull(0xc82000f6b0, 0x0, 0x0)
/home/ubuntu/work/go/src/github.com/tillberg/gut/gut_cmd.go:149 +0x2f
main.Sync.func8(0xc82000f6b0)
/home/ubuntu/work/go/src/github.com/tillberg/gut/shell.go:312 +0xea
main.Sync.func1.1(0xc820420d50, 0xc82000f6b0, 0xc82020ec00)
/home/ubuntu/work/go/src/github.com/tillberg/gut/shell.go:169 +0x26
created by main.Sync.func1
/home/ubuntu/work/go/src/github.com/tillberg/gut/shell.go:171 +0x55
goroutine 224 [select]:
github.com/tillberg/bismuth.callClosers(0xc8203e61e0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 225 [select]:
github.com/tillberg/bismuth.callClosers(0xc8203e6f00)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 246 [select]:
github.com/tillberg/bismuth.callClosers(0xc8203e7080)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 228 [select]:
github.com/tillberg/bismuth.callClosers(0xc8203e6600)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 420 [chan receive]:
github.com/tillberg/bismuth.(*ExecContext).StartSession.func2(0xc8200c7a40, 0xc82049c360, 0xc82016a220)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:572 +0x40
created by github.com/tillberg/bismuth.(*ExecContext).StartSession
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:575 +0x398
goroutine 234 [select]:
github.com/tillberg/bismuth.callClosers(0xc8203e6a20)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 274 [select]:
github.com/tillberg/bismuth.callClosers(0xc82020ee40)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 291 [select]:
github.com/tillberg/bismuth.callClosers(0xc8200dfaa0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 268 [select]:
github.com/tillberg/bismuth.callClosers(0xc8203e7500)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 399 [chan receive]:
github.com/tillberg/bismuth.SessionArgs.func1(0x7f05f40ee2b0, 0xc8203fd440, 0xc8203fb620, 0xc8203fb680)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:623 +0x9d
created by github.com/tillberg/bismuth.(*ExecContext).StartSession
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:562 +0x223
goroutine 352 [select]:
github.com/tillberg/bismuth.callClosers(0xc8204473e0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 278 [select]:
github.com/tillberg/bismuth.callClosers(0xc82020f8c0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*LocalSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:218 +0x45
goroutine 404 [chan receive]:
github.com/tillberg/bismuth.ExecContext.ReverseTunnel.func1.1(0x7f05f40ee4f8, 0xc8204f0000, 0xc82013bad0, 0xf, 0xc8201bc4d0)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:506 +0x2bf
created by github.com/tillberg/bismuth.ExecContext.ReverseTunnel.func1
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:508 +0xea
goroutine 398 [chan receive]:
github.com/tillberg/bismuth.SessionCwd.func1(0x7f05f40ee2b0, 0xc8203fd440, 0xc8203fb620, 0xc8203fb680)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:632 +0x9d
created by github.com/tillberg/bismuth.(*ExecContext).StartSession
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/bismuth.go:562 +0x223
goroutine 372 [select]:
github.com/tillberg/bismuth.callClosers(0xc82020ff80)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 436 [semacquire]:
sync.runtime_Syncsemacquire(0xc820467450)
/home/ubuntu/go/src/runtime/sema.go:237 +0x201
sync.(*Cond).Wait(0xc820467440)
/home/ubuntu/go/src/sync/cond.go:62 +0x9b
golang.org/x/crypto/ssh.(*buffer).Read(0xc820465140, 0xc8204e0000, 0x8000, 0x8000, 0x0, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/buffer.go:95 +0x339
golang.org/x/crypto/ssh.(*channel).ReadExtended(0xc8201d2540, 0xc8204e0000, 0x8000, 0x8000, 0x1, 0xc8204e0000, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/channel.go:347 +0x161
golang.org/x/crypto/ssh.(*extChannel).Read(0xc820472eb0, 0xc8204e0000, 0x8000, 0x8000, 0x6, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/channel.go:486 +0x57
io.copyBuffer(0x7f05f40ee340, 0xc8203fb8c0, 0x7f05f59b2af0, 0xc820472eb0, 0xc8204e0000, 0x8000, 0x8000, 0x6, 0x0, 0x0)
/home/ubuntu/go/src/io/io.go:381 +0x247
io.Copy(0x7f05f40ee340, 0xc8203fb8c0, 0x7f05f59b2af0, 0xc820472eb0, 0xc820472eb0, 0x0, 0x0)
/home/ubuntu/go/src/io/io.go:351 +0x64
golang.org/x/crypto/ssh.(*Session).stderr.func1(0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/session.go:489 +0xbc
golang.org/x/crypto/ssh.(*Session).start.func1(0xc8204d4120, 0xc820472ea0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/session.go:361 +0x1d
created by golang.org/x/crypto/ssh.(*Session).start
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/session.go:362 +0x1e1
goroutine 365 [select]:
github.com/tillberg/bismuth.callClosers(0xc8204a6360)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:151 +0x45
goroutine 435 [semacquire]:
sync.runtime_Syncsemacquire(0xc820467410)
/home/ubuntu/go/src/runtime/sema.go:237 +0x201
sync.(*Cond).Wait(0xc820467400)
/home/ubuntu/go/src/sync/cond.go:62 +0x9b
golang.org/x/crypto/ssh.(*buffer).Read(0xc820465100, 0xc8204e8000, 0x8000, 0x8000, 0x0, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/buffer.go:95 +0x339
golang.org/x/crypto/ssh.(*channel).ReadExtended(0xc8201d2540, 0xc8204e8000, 0x8000, 0x8000, 0x0, 0x8000, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/channel.go:349 +0x7a
golang.org/x/crypto/ssh.(*channel).Read(0xc8201d2540, 0xc8204e8000, 0x8000, 0x8000, 0x8000, 0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/channel.go:526 +0x86
io.copyBuffer(0x7f05f412a238, 0xc8200a7400, 0x7f05f40ee368, 0xc8201d2540, 0xc8204e8000, 0x8000, 0x8000, 0x0, 0x0, 0x0)
/home/ubuntu/go/src/io/io.go:381 +0x247
io.Copy(0x7f05f412a238, 0xc8200a7400, 0x7f05f40ee368, 0xc8201d2540, 0xc8201d2540, 0x0, 0x0)
/home/ubuntu/go/src/io/io.go:351 +0x64
golang.org/x/crypto/ssh.(*Session).stdout.func1(0x0, 0x0)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/session.go:476 +0x95
golang.org/x/crypto/ssh.(*Session).start.func1(0xc8204d4120, 0xc820472e80)
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/session.go:361 +0x1d
created by golang.org/x/crypto/ssh.(*Session).start
/home/ubuntu/work/go/src/golang.org/x/crypto/ssh/session.go:362 +0x1e1
goroutine 366 [select]:
github.com/tillberg/bismuth.callClosers(0xc8203fae40)
/home/ubuntu/work/go/src/github.com/tillberg/bismuth/session.go:89 +0x112
created by github.com/tillberg/bismuth.(*SshSession).Close
/

I tried running local sync. There seems to be an issue with connecting to the local host. Error message is not descriptive though.
[localhost:sync] Starting gut-sync between /home/hari/mywork and /home/hari/backup/mywork.
[localhost:daemon] fatal: Uh oh. Your system reports no Gut commands at all.
[localhost:init] warning: templates not found /home/ubuntu/.guts/gut-build/share/gut-core/templates
[localhost:init] Initialized empty Gut repository in /home/hari/backup/mywork/.gut/
[localhost:fetch] Fetching changes to localhost...
[localhost:fetch] fatal: unable to connect to localhost:
[localhost:fetch] localhost[0: 127.0.0.1]: errno=Connection refused
[localhost:fetch]
[localhost:merge] Merging changes to localhost...
[localhost:merge] merge: origin/master - not something we can merge
[localhost] inotifywait started, watching localhost:/home/hari/mywork.
[localhost] inotifywait started, watching localhost:/home/hari/backup/mywork.
[localhost:commit] Checking localhost for changes (scope=.)...
[localhost:commit] Checking localhost for changes (scope=.)...
[localhost:commit] On branch master
[localhost:commit]
[localhost:commit] Initial commit
[localhost:commit]
[localhost:commit] nothing to commit
[localhost:commit] On branch master
[localhost:commit] nothing to commit, working directory clean
[localhost:commit] No changes.
[localhost:commit] No changes.
[localhost:fetch] Fetching changes to localhost...
[localhost:fetch] fatal: unable to connect to localhost:
[localhost:fetch] localhost[0: 127.0.0.1]: errno=Connection refused
[localhost:fetch]
[localhost:merge] Merging changes to localhost...
[localhost:merge] merge: origin/master - not something we can merge
^CReceived SIGINT. Stopping all subprocesses...

repo: tillberg/gut

license: isc


text:
Select assets before showing picker

TLPhotosPickerViewController has selectedAssets but I don't think it was made to accept assets from outside. Is there a way to display picker with selectedAssets?

See this issue

Got it, I was trying to set selectedAssets = someNewAccests instead of append: operator

authors: intoxicated tilltue

repo: tilltue/TLPhotoPicker


text:
How can crop the detected hand part

Hi, I want crop the detected hand part from image.  how to do that?
Thanks!

What do you mean crop ?. Don't you already have keypoints ?
Use min row, min col, max row, max col and add some threshold if you want and apply crop using opencv.
is it what you are looking for ?

authors: chaiban chenzi


text:
Ferrocene compiler needs more information about the type of Box<_> at compile time.

When attempting to compile this crate using the Ferrocene compiler, I see the following error in /src/format_description/parse/mod.rs.

This isn't specific to Ferrocene, nor is it an issue at all. See #681 — it's already been fixed.

authors: benracine jhpratt

repo: time-rs/time


text:
Non-leaders should not fill the logs

Currently the non-leaders in the leader-election method do not stop logging and hence fill the logs which are enough to be logged just once until a change. This needs to be fixed. Log only if the situation compared to previous is changed.

[ ] Lesser logging by non-leaders

Clarrification: This is only the debug log level. The default log level already doesn't pollute log

authors: Harkishen-Singh cevian

repo: timescale/promscale


text:
Refactor generate_queries devops case to use errs

Previously the devops use case generation code used a call to
log.Fatalf when something went wrong. This makes it awkward to test
error conditions when generating queries from other packages, since
we need a way to (a) replace the unexported call to log.Fatalf and
(b) prevent the runtime from actually quitting.
It is better for the library to actually return errors on calls
that can fail, rather than either fataling or panicking. Now other
packages can handle the errors themselves and also test error
conditions in their packages as well.
This refactor was pruned a bit to bubble the 'panic' up one level
for now. When the actual generation code encounters the error
during normal execution, it will panic. But these are easier to
test for and don't require adding hooks to replace the 'fatal'
path in the original package.

Codecov Report

Merging #77 into master will decrease coverage by 0.31%.
The diff coverage is 49.49%.

@@            Coverage Diff             @@
##           master      #77      +/-   ##
==========================================
- Coverage   57.13%   56.82%   -0.32%
==========================================
  Files          76       76
  Lines        3719     3757      +38
==========================================
+ Hits         2125     2135      +10
- Misses       1570     1592      +22
- Partials       24       30       +6

Impacted Files
Coverage Δ

...bs_generate_queries/databases/clickhouse/devops.go
10.1% <20%> (+0.16%)
:arrow_up:

...sbs_generate_queries/databases/cassandra/devops.go
25.55% <28.57%> (+0.86%)
:arrow_up:

...d/tsbs_generate_queries/databases/influx/devops.go
32.14% <28.57%> (+0.14%)
:arrow_up:

...d/tsbs_generate_queries/databases/siridb/devops.go
27.58% <28.57%> (+0.66%)
:arrow_up:

...s_generate_queries/databases/timescaledb/devops.go
97.41% <87.5%> (-1.2%)
:arrow_down:

cmd/tsbs_generate_queries/uses/devops/common.go
92.85% <90.47%> (-3.97%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3cfaae0...70ddcb7. Read the comment docs.

authors: RobAtticus codecov-io

repo: timescale/tsbs


text:
RuntimeError: cannot reuse already awaited coroutine

It is said it "happens pretty much any time you use a bare coroutine in Python.".

Tentative fix using package asyncache in commit 36e8fd9fb6754d4cfae4d1ca80fa163025e85986.

repo: timkofu/ghs


text:
Implementing equals() and hashCode() for UserTrade.

I'm a user of XChange but this is my first contribution.
I would benefit from these modifications, and I thought others would too.
If I am not following accepted conventions, proper PR protocol, etc please let me know and I'll try to make necessary changes.

just out of curiosity, why do you need those methods?

@andre77
I have an object in my application that has a UserTrade as a property and has other properties that add data about the UserTrade that is specific to my application.
I want to implement equals() and hashCode() on my custom object so that two objects with the same values are considered equal, and this would be made easier/cleaner for me if UserTrade implemented equals() and hashCode() so that two UserTrades with equal values are considered equal.
I assumed other users would desire the same behavior from UserTrades.
Perhaps this was an incorrect assumption.
If this isn't going to be a net positive for the community, I'll close the PR.

@stevenuray
i do not mind to add those methods, totally fine to me
in your case, you probably just could extend the existing UserTrade and create a new class containing all the properties required by your application. In that new class you can than add what ever you like, the hash and equals method, which would use the properties from the super classes etc.
just my 2c
Marry Christmas! :-)

I'm not yet against it, but haven't had time yet to take a close look. Please don't close this PR yet. Thanks!

@andre77
I agree extending the class would work too, in this case.
Thanks for the reviews/merge, and also all the work on the XChange project!
Happy Holidays!

authors: andre77 stevenuray timmolter

repo: timmolter/XChange


text:
Баг: Не работает bot.labeler.vbml_ignore_case = True.

Опишите баг: ...
Описан
Ожидаемое поведение: ...
Бот будет игнорить регистр
Фактическое поведение: ...
Бот не игнорит регистр
Ваш код (опционально): ...
bot.run_forever()``` и ```@bot.on.chat_message(text=['кошка', 'кот', "котик", 'котенок', 'котёнок', 'котики'])
async def cat(message: Message):
	await dev_mode(message, 'Sending Cat')
	await message.answer('Котик!', attachment=random.choice(cats))
bot.labeler.vbml_ignore_case = True``` (оба варианта не работают)

**Заполните поля технической информации:**

<!-- Узнать версии установленных библиотек можно командой pip freeze -->

---
vkbottle: 3.0 uploaders
vkbottle-types:  0.1.22
OS: Windows 7 64-bit

---

<!-- Проверьте что вы кратко описали баг в названии issue -->

код оформлен ужасно, но могу предположить что флаг установлен после хендлеров когда должен до

код оформлен ужасно, но могу предположить что флаг установлен после хендлеров когда должен до

тоже не работает

ну вот как всегда нужно догадываться в чем проблема
блупринты имеют свой labeler и флаги таким образом не наследуются
установите флаг в каждом из блупринтов где он нужен

authors: Timtaran timoniq

repo: timoniq/vkbottle


text:
Improve the CLI

This PR introduces a number of improvements to the command line tools included with the package.
Specifically, it:

adds a new getNameForDevice which returns a device's name (e.g. "Logitech Litra Glow")
updates all of the CLIs so you can specify a --serial-number/-s to target a specific device when you have multiple devices connected
adds a new litra-identify CLI for getting the serial numbers of your Litra devices when multiple are connected
switches to using the commander package for a better CLI experience and more robust argument parsing

@leggetter Would you be able to give the new --serial-number option and litra-identify commands a go, since you have multiple devices?

@leggetter Would you be able to give the new --serial-number option and litra-identify commands a go, since you have multiple devices?

tl;dr - the -s works to control individual devices.
I didn't globally install as I have a clash with my own commands called litra-on and litra-off. So, I'm running the commands directly using node dist/path/to/command.js.
timrogers/cli-improvements $ node dist/commonjs/cli/litra-identify.js
Found 2 connected Litra devices
Flashing light on Logitech Litra Beam device with serial number SERIAL_ONE...
Press Enter to continueFlashing light on Logitech Litra Beam device with serial number SERIAL_TWO...

Press Enter to continue%
timrogers/cli-improvements $ node dist/commonjs/cli/litra-on.js -s SERIAL_ONE
timrogers/cli-improvements $ node dist/commonjs/cli/litra-on.js -s SERIAL_TWO

The flashing of the light is a great idea to identify them, and the console output seems to suggest this should repeat until enter is pressed; however, the script seems to continue and exist without user intervention.
My next comment is the ... after the serial number makes it slightly harder to copy the value by double-clicking onit with the mouse because that means the ... is also highlighted rather than just the serial number.
Maybe that's just because of how I'm running the commands?

authors: leggetter timrogers

repo: timrogers/litra