text:
建议IConverter的convert方法把ResponseBody参数换成Response

这样的话方便自定义的Converter拿到Response，就可以通过OkHttpCompat.request(response).header()拿到请求头信息，方便定制每个人不同的业务逻辑

收到，我斟酌下

仔细想了下，Converter中应该只做数据转换工作，而不应该参杂其它业务逻辑；如果想拿到Response 对象处理业务逻辑，可通过自定义解析器解决

我的需求是在convert方法里通过
String timestamp = OkHttpCompat.request(response).header("timestamp");

拿到timestamp去解密后台返回的数据，数据格式如下
{
    "code": 200,
    "data": "加密过的数据，解密的key是存在请求头里的timestamp",
    "msg": ""
}

如果拿不到Response的话，我就解密不了数据

这种场景自定义解析器最合适不过了，如下：
@Override
public T onParse(@NotNull okhttp3.Response response) throws IOException {
    String result = getResult(response);
    try {
        JSONObject jsonObject = new JSONObject(result);
        int code = jsonObject.optInt("code");
        String data = jsonObject.optString("data");
        String msg = jsonObject.optString("msg");
        T t = null;
        if (code == 200) {
            //1、自行实现解密逻辑

            //2、将解密后的数据转换为Bean对象
            t = GsonUtil.fromJson(data, mType);
        }
        if (t == null) {
            throw new ParseException(String.valueOf(code), msg, response)
        }

        return t;
    } catch (JSONException e) {
        throw new IOException(e);
    }
}

多谢，是我犯糊涂了

repo: liujingxing/okhttp-RxHttp


text:
Update changelog

🐈⬛

WDYT about mentioning that Docker and Desktop release is using Elixir 1.17 and OTP 27?

source: gharchive/pull-request

authors: jonatanklosko wojtekmach

repo: livebook-dev/livebook

license_type: permissive

license_source: github-api


text:
Use a bigger chunk size when transferring files across nodes

We transparently copy files from Livebook to remote runtime (Fly), for example, when using Kino.Input.image. We noticed that it takes unusually long time to transfer the file. This increases file chunk size that we write across the nodes.
Just as an example, I tried ~1MB .jpeg image and this change dropped the transfer time roughly from 70s to 4s.

We can probably bump it even more? I'd expect the Erlang distribution to chunk large binaries naturally, so we don't have to worry about those concerns. I mean, in Nx we just send the whole binary tensor, and I haven't ran into issues.

@josevalim we still want to minimize the memory usage while sending the file, no? I kept it at 64kb, because bumping to 128kb didn't seem to bring further improvement :)

authors: jonatanklosko josevalim


text:
Use rust::String::lossy for stringification to avoid crashing due to non-utf8 content

This was causing crashes here in Zed's live kit test app when run on Linux.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks!

authors: CLAassistant mgsloan theomonnom

repo: livekit/rust-sdks


text:
🛑 Movie is down

In 5fa37ec, Movie (http://h.liyaodong.com:8096) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Movie is back up in 1addb74.

source: gharchive/issue

repo: liyaodong/uptime

license: MIT


text:
Add GitHub Actions

I have made things!

Checklist

[x] I have read contributing guidelines
[x] I'm sure that I did not unrelated changes in this pull request
[x] I have created at least one test case for the changes I have made
[x] I have added myself to the CONTRIBUTORS.rst

Related issues

Closes #963

I made an initial attempt at migrating the current Travis CI to GitHub Actions. @lk-geimfari you will have to create some repository secrets:

[x] CODECOV_TOKEN
[ ] PYPI_PASSWORD

For now I have left the codecov step commented out so it doesn't fail the pipeline, once secrets are in place we can try properly.
I also cached the virtual environment so we get quicker subsequent runs if the dependencies don't change 😄
This is what it looks like:

@michael0liver First of all — thank you very much for this PR. I've added a comment.

@michael0liver Thank you again. You have done a great job!.

@michael0liver Sure! I'll do it after solving #976 and #975. Thanks again!

repo: lk-geimfari/mimesis


text:
keep up-to-date

I hope this nice crate to be kept up-to-date somehow. (+ rust-ptrace too. cf. https://github.com/lkpdn/rust-ptrace/commit/7614a304faa1a1d62d9b8eb8b152da89e6a3dc27 )

oh my

repo: lkpdn/rust-posix-ipc


text:
Uncaught Error: watch ~/projects ENOSPC

[Enter steps to reproduce:]

...
...

Atom: 1.21.1 x64
Electron: 1.6.15
OS: Ubuntu 16.04.3
Thrown From: go-debug package 1.5.2
Stack Trace
Uncaught Error: watch /home/matthieu/projects ENOSPC
At events.js:160

Error: watch /home/matthieu/projects ENOSPC
    at exports._errnoException (util.js:1022:11)
    at FSWatcher.start (fs.js:1316:19)
    at Object.fs.watch (fs.js:1341:11)
    at createFsWatchInstance (/packages/go-debug/node_modules/chokidar/lib/nodefs-handler.js:37:15)
    at setFsWatchListener (/packages/go-debug/node_modules/chokidar/lib/nodefs-handler.js:80:15)
    at FSWatcher.NodeFsHandler._watchWithNodeFs (/packages/go-debug/node_modules/chokidar/lib/nodefs-handler.js:228:14)
    at FSWatcher.NodeFsHandler._handleDir (/packages/go-debug/node_modules/chokidar/lib/nodefs-handler.js:407:19)
    at /packages/go-debug/node_modules/chokidar/lib/nodefs-handler.js:455:19)
    at /packages/go-debug/node_modules/chokidar/lib/nodefs-handler.js:460:16)
    at FSReqWrap.oncomplete (fs.js:112:15)

Commands
     -0:13.7.0 tree-view:show (atom-workspace.workspace.scrollbars-visible-always)

Non-Core Packages
busy-signal 1.4.3
file-icons 2.1.13
go-debug 1.5.2
go-plus 5.5.6
go-signature-statusbar 1.2.3
hyperclick 0.1.5
intentions 1.1.5
language-docker 1.1.8
linter 2.2.0
linter-ui-default 1.6.10

Duplicate of https://github.com/lloiser/go-debug/issues/73. If not reopen and provide more info.

authors: lloiser mjoossen

repo: lloiser/go-debug

license: mit

license_source: bigquery


text:
Release pynndescent 0.3.0

It would be good to do a new release. The last release was 0.2.1 in July last year (https://pypi.org/project/pynndescent/).

I ran pyroma (via Prospector), a linting tool specifically for setup.py, and it suggested a few minor changes that might be worth including. I will supply a PR later today.

Thanks @jlmelville!

Thanks @tomwhite and @jlmelville for all the work you have both put into this recently -- it has been greatly appreciated. I really hope to get some time soon to go through and properly catch up with everything and start adding a few bits and pieces (multi-threaded trees, dask support, etc.) In the meantime, yes, this is definitely worthy of a 0.3 release -- I'll wait for James to make his changes, and try and get it done in the next day or so.

Thanks @lmcinnes.
Re dask support, I have got a branch that I wrote a while ago. I'll post it soon.

Before we release this I was thinking it would be good to be sure that the API for running in threaded mode is what we want. I've started looking at joblib to see if we can use that.

I'm happy with the current state, but understand if you want to address a few of the remaining joblib related bits and pieces first (alternatively we can add those in a 0.3.1 as needed). Let me know.

I think it's worth removing chunk_size from the API for NNDescent or at least making it optional. I will submit a PR. (Other bits and pieces can wait for a point release.)

Thanks for releasing 0.3.0 @lmcinnes!

Glad to see all your and James' work make it out into a release.

authors: jlmelville lmcinnes tomwhite

repo: lmcinnes/pynndescent


text:
Indicate launch module updates in app layer versioning

The automated application layer versioning in 0.2.0 is misleading, as the given version number only reflects the lock version, it doesn't reflect the launch module version. This makes it hard for the deploying application to work out if the latest version of an application layer is already installed, or if it needs to download and install a new one.
To fix this, the meaning of versioned=True on application layers should change to include a app_launch_module_version field (based on the app_launch_module_hash changing) in addition to the existing lock_version field.
For app layers, the deployed layer name format would change from {layer_name}@{lock_version} to {layer_name}@{app_launch_module_version}.{lock_version}

I initially thought this could use the same approach as the existing archive_build field, and just put the launch module version number in the layer output metadata. However, that approach won't work for this use case, as the "previous launch module hash" and "previous launch module version" information needs to be consistent across both archive builds and local exports, and it needs to be reliably available.
Instead, we need a dedicated (automatically generated) versioning file checked into git for each application layer, just as we already have for the environment lock versioning.
Proposed location for that file:

emit a app-{layer_name}.json file in the requirements/app-{layer_name} folder for each application layer (this folder is already required to be under version control, as it contains the per-platform lock files for the layer)
Potential variation: launch-module-app-{layer_name}.json (to be more consistent with the way the per-platform lock files are named)

Proposed fields for that file:

launch_name: the name to pass to python -m to launch the module (version is bumped if this changes)
source_hash: the file-or-directory hash for the launch module source (version is bumped if this changes)
app_version: counterpart to the lock_version field in the layer lock version files

Output metadata (option 1 - flat):

app_launch_module: rename to app_launch_name
app_launch_module_hash: rename to app_source_hash
app_version: new field

Output metadata (option 2 - nested):

app: new field with the same structure as the committed app layer versioning file

The old output metadata field names would be temporarily retained for 0.3.0, but removed in 0.4.0.
As part of this, we should explicitly document the expectation that venvstacks projects should consistently use LF line-endings, even on Windows, to avoid cross-platform hash inconsistencies (referencing https://github.com/lmstudio-ai/venvstacks/blob/main/.gitattributes as an example)

After chatting to @neilmehta24 about it, I'm going to try an approach that treats the launch module hash as an additional input to the environment lock file for application layers.
However, I still have to decide how the visible layer versioning numbering should work:

{layer_name}@{lock_version}.{app_version}
{layer_name}@{app_version}.{lock_version}
{layer_name}@{layer_version} (incremented when lock or app version is updated)
{layer_name}@{lock_version+app_version} (incremented twice if lock version and app version both change)

I'm currently leaning towards Neil's suggested app layer versioning format, where the part immediately after the @ symbol is the lock version for all layers, and app layers add the launch module version after that.
The general idea being that complex launch modules should ideally be separated out as regular versioned Python packages, with the launch modules being a relatively thin layer that adapts the application interface to the CLI interface expected by the embedding application.

Further discussion between Neil and myself narrowed the four options above down to two candidates:

{layer_name}@{lock_version}.{app_version}
{layer_name}@{lock_version+app_version}

These are the two that feel the most "similar in spirit" to the way the runtime and framework layer versioning works (with just a lock version defined, since venvstacks only allows injecting unpackaged code into the application layers).
The (arguable) problem with the first option (exposing the two numbers separately), is that it promotes an implementation detail (whether an application is written as a complex launch module only distributed with venvstacks, or as a published Python module that the application layer definition depends on) into a visible part of the layer name. It also uses the dotted version notation for something that is quite different from the way semantic versioning or calendar versioning uses it.
Distinguished versioning with a complex launch module and the occasional dependency update:

app-layer@1.1 (initial layer publication)
app-layer@1.2 (launch module update)
app-layer@1.3 (launch module update)
app-layer@2.3 (dependency update)
app-layer@3.4 (dependency and launch module update)

Distinguished versioning with a simple launch module and all functional changes happening via dependency updates:

app-layer@1.1 (initial layer publication)
app-layer@2.1 (app module update)
app-layer@3.1 (app module update)
app-layer@4.1 (other dependency update)
app-layer@5.1 (app module and other dependency update)

If we make the launch module versioning zero-based instead of one based, then summing the two version numbers would give the following progression:
Combined versioning with a complex launch module and the occasional dependency update:

app-layer@1 (initial layer publication: 1+0)
app-layer@2 (launch module update: 1+1)
app-layer@3 (launch module update: 1+2)
app-layer@4 (dependency update: 2+2)
app-layer@6 (dependency and launch module update: 3+3)

Combined versioning with a simple launch module and all functional changes happening via dependency updates:

app-layer@1 (initial layer publication: 1+0)
app-layer@2 (launch module update: 2+0)
app-layer@3 (launch module update: 3+0)
app-layer@4 (dependency update: 4+0)
app-layer@5 (dependency and launch module update: 5+0)

I'm still not loving either of the app layer versioning approaches explored in my previous comment. The fact I felt compelled to explain the sums involved when writing out the "combined version number" examples isn't a good sign, and neither is the fact that the combined approach needs zero-based launch modules versions to avoid making the initial layer version number weird.
It did inspire a fifth idea, though, which is to use + as the separator instead of ., so it's clearer that these are two different version numbers more than they are two parts of one version number:
Distinguished versioning with a complex launch module and the occasional dependency update:

app-layer@1+1 (initial layer publication)
app-layer@1+2 (launch module update)
app-layer@1+3 (launch module update)
app-layer@2+3 (dependency update)
app-layer@3+4 (dependency and launch module update)

Distinguished versioning with a simple launch module and all functional changes happening via dependency updates:

app-layer@1+1 (initial layer publication)
app-layer@2+1 (app module update)
app-layer@3+1 (app module update)
app-layer@4+1 (other dependency update)
app-layer@5+1 (app module and other dependency update)

{layer_name}@{lock_version}+{app_version} looks good to @neilmehta24 as well, so that's the approach we're going to go with.

repo: lmstudio-ai/venvstacks


text:
🛑 BiQ Insight is down

In 93b493c, BiQ Insight (https://data.biq.dk) was down:

HTTP code: 500
Response time: 18994 ms

Resolved: BiQ Insight is back up in 70f7e1c after 8 minutes.

repo: lobner/status


text:
localtunnel.me 504 Time-Out

I love tocaltunnel for the functionality : lt --port 8000 --subdomain mydomain --local-host mydomain.localhost
Today I wanted to use the functionality again, but I get an 504 Gateway Time-out (nginx/1.7.8).
I can not tell exactly when I was using it last, maybe a month ago, and there it worked perfectly fine.
I recently updated to OSX 10.11 I am not sure if that does make any difference, but I don't think so.
I also don't get an error in my terminal, so I think it is an error on you side.
Cheers

+1

If the website goes down or some other thing breaks users might see this for a few moments until things are back up. If things are offline for a while the best approach is to ping me on twitter @defunctzombie

authors: defunctzombie jimmyn n3ssi3

repo: localtunnel/localtunnel


text:
404 and client crashes after a few seconds after connect to my own localtunnel server

hi, I am aware of a similar issues, however, those are outdated and no longer works for me. I have followed the instructions from this article []https://medium.com/quark-works/running-your-own-reverse-proxy-with-localtunnel-b1658e239c35 to set up a localtunnel server, but when I try to connect from a client machine, it shows a 404 error and automatically disconnects after a few seconds.

thanks everyone, I figured it out.

@Im-SRJ I'm facing the same issue! How did you resolve it?

authors: Amit-A Im-SRJ

repo: localtunnel/server


text:
Show no results if the search term is not found

Is there a way to show no results if the search term is not found instead of showing all items?

Hi @switch13.
I've just tested and no results are being returned when a search term isn't found. Have you implemented your own search function?

I'm sorry, please close this.

repo: localz/react-native-searchbar


text:
cancel button in logout window doesn't do anything

On macOS

https://github.com/lockbook/lockbook/assets/4467106/89789784-5db9-4531-9406-78648926d915

I'm running master as well, but it is giving me a different behavior from yours. Mine just doesn't let me click cancel, I don't do anything notable for it to happen.

I don't think its disabled:

The window close in the top left does work.

does a breakpoint here hit?

I think I see the issue. In master, that line is just a call into core:
https://github.com/lockbook/lockbook/blob/78a1780e04206a1c7aaf0b70e80b0738e23435af/clients/apple/Shared/Views/LogoutConfirmation.swift#L119

That line you linked is for logout, not dismiss. Dismiss is here

You are correct, sorry. The breakpoint hits but doesn't do anything.

Since the breakpoint hits, we know my custom button wrapper/handler works. It is weird because I cannot reproduce it on my end. After the meeting today we can screen share and take a look together on your machine

authors: CoreyCole smailbarkouch

repo: lockbook/lockbook

license: Unlicense


text:
Numerical differentiation (or analitycal one) seems to be wrong for the Floating in Contact DAM

In GitLab by @cmastalli on Feb 23, 2019, 18:35
I was analyzing a bit the effect of disturbance values for the numerical computation of derivatives. And I found a huge error in the computation of Fx, Lx and Lxx. Unfortunately we don't have unit-test for NumDiff withi this problem. I have attached the code which I used for it
test_floating_contact_numdiff.py
The weird thing is that the NumDiff for ABA is working quite well. As I reported here !109. I also attached this code test_aba_numdiff.py.

In GitLab by @cmastalli on Feb 23, 2019, 18:35
mentioned in merge request !109

In GitLab by @cmastalli on Feb 23, 2019, 18:52
changed the description

In GitLab by @nmansard on Feb 27, 2019, 09:01
What is this bug and how is it related to !109? Does it mean that !109 cannot be merged? Are you 100% confident that there is no other bugs related to !109 that are hidden somewhere?
Again, I am very reluctant to commit this changes, as the ratio benefit over time-cost and risk is very high. I want a strong commitment that it is working, and I am afraid that, here, "strong" has the direct consequence of implying a lot of validation time.

In GitLab by @cmastalli on Feb 27, 2019, 09:23
@nmansard this probably bug is orthogonal (i.e. unrelated) to !109, you can merge it. That PR fixed some few problems with the unit-test and modify the default disturbance value.
Instead I tried different disturbance values (not using default one) for both DAMFullyActuated and DAMFloatingInContact. I did it in order to understand the numerical error with different disturbance values.
For the DAMFullyActuated case, I encountered the results that I expected (i.e. $\sqrt{2*eps}\approx 2.1073\cdot 10^{-8}$). And in fact, I didn't see any rounding error with Numpy or EigenPy.
In order to benchmark better this, I decided to try the same with DAMFloatingInContact. However, I found very big numerical errors in all the disturbance values (including $``0^{-5}`$).
I shared both scripts used to test it. I don't discard the possibility of having a bug there. Please try the shared scripts and merger !109.

In GitLab by @proyan on Feb 27, 2019, 09:49
I checked and this is not a bug. The problem is in your code.
You are using a random state to check the numdiff of floatingincontact. This won't work. You need to account for the shape of the manifold.

In GitLab by @proyan on Feb 27, 2019, 09:49
I'll close this. Feel free to open it if the issue persists.

In GitLab by @proyan on Feb 27, 2019, 09:49
closed

In GitLab by @cmastalli on Feb 27, 2019, 09:51
@proyan thanks a lot. Could you share the modified code here? I would like to try it and it's nice to share here for future references.

In GitLab by @proyan on Feb 27, 2019, 09:53
Just use state.rand instead of np.rand to generate the random states.


text:
FastHttpLocust + SNI

Getting weird issue with FastHttpLocust again.
It works fine from client.
But server (OpenResty) has SNI based bindings and show tons of errors like
... failed to get SNI ...
and falls back to default certificate. :(
Same exact code works fine with HttpLocust.
Don’t know how to help somebody to reproduce…
Am I missing something (simple?) with FastHttpLocust?
AFAIR, it’s up to the https client to send SNI or not, right?
url = f'{https}://{host}{url}'
headers = {
	'Host': host,
}
self.client.get(url, name=url, headers=headers)

(locust382) ubuntu@...:~$ conda list
# packages in environment at /home/ubuntu/anaconda3/envs/locust382:
#
# Name                    Version                   Build  Channel
_libgcc_mutex             0.1                        main
ca-certificates           2020.1.1                      0
certifi                   2020.4.5.1               py38_0
chardet                   3.0.4                    pypi_0    pypi
click                     7.1.1                    pypi_0    pypi
configargparse            1.2.1                    pypi_0    pypi
flask                     1.1.2                    pypi_0    pypi
flask-basicauth           0.2.0                    pypi_0    pypi
gevent                    1.5.0                    pypi_0    pypi
geventhttpclient-wheels   1.3.1.dev3               pypi_0    pypi
greenlet                  0.4.15                   pypi_0    pypi
idna                      2.9                      pypi_0    pypi
itsdangerous              1.1.0                    pypi_0    pypi
jinja2                    2.11.2                   pypi_0    pypi
ld_impl_linux-64          2.33.1               h53a641e_7
libedit                   3.1.20181209         hc058e9b_0
libffi                    3.2.1                hd88cf55_4
libgcc-ng                 9.1.0                hdf63c60_0
libstdcxx-ng              9.1.0                hdf63c60_0
locustio                  1.0.0                     dev_0    <develop>
markupsafe                1.1.1                    pypi_0    pypi
msgpack                   1.0.0                    pypi_0    pypi
ncurses                   6.2                  he6710b0_0
openssl                   1.1.1g               h7b6447c_0
pip                       20.0.2                   py38_1
psutil                    5.7.0                    pypi_0    pypi
python                    3.8.2                hcf32534_0
pyzmq                     19.0.0                   pypi_0    pypi
readline                  8.0                  h7b6447c_0
requests                  2.23.0                   pypi_0    pypi
setuptools                46.1.3                   py38_0
six                       1.14.0                   pypi_0    pypi
sqlite                    3.31.1               h62c20be_1
tk                        8.6.8                hbc83047_0
urllib3                   1.25.9                   pypi_0    pypi
werkzeug                  1.0.1                    pypi_0    pypi
wheel                     0.34.2                   py38_0
xz                        5.2.5                h7b6447c_0
zlib                      1.2.11               h7b6447c_3

What version of Locust are you using? Have you tried with master? I did a fix for #1360 a week ago, but it hasn't gone out in any release yet.

I was on
locustio                  1.0.0                     dev_0    <develop>
installed 4/22/2020
conda list is in my prev. message…
I’ve updated to
locustio                  1.0b2                     dev_0    <develop>
And I cannot even start locust now…
I’ve wiped and reinstalled conda env – it made no difference…
I did install with
pip install -e git://github.com/locustio/locust.git@master#egg=locustio
in both cases.
Logs are below:
Traceback (most recent call last):
  File "/home/ubuntu/anaconda3/envs/locust382/bin/locust", line 11, in <module>
    load_entry_point('locustio', 'console_scripts', 'locust')()
  File "/home/ubuntu/locust/src/locustio/locust/main.py", line 113, in main
    docstring, user_classes = load_locustfile(locustfile)
  File "/home/ubuntu/locust/src/locustio/locust/main.py", line 77, in load_locustfile
    imported = __import_locustfile__(locustfile, path)
  File "/home/ubuntu/locust/src/locustio/locust/main.py", line 53, in __import_locustfile__
    return  source.load_module()
  File "<frozen importlib._bootstrap_external>", line 462, in _check_name_wrapper
  File "<frozen importlib._bootstrap_external>", line 962, in load_module
  File "<frozen importlib._bootstrap_external>", line 787, in load_module
  File "<frozen importlib._bootstrap>", line 265, in _load_module_shim
  File "<frozen importlib._bootstrap>", line 702, in _load
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 783, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/home/ubuntu/locust/case2.py", line 1, in <module>
    from locust import HttpLocust, TaskSet, task, between
ImportError: cannot import name 'HttpLocust' from 'locust' (/home/ubuntu/locust/src/locustio/locust/__init__.py)

# packages in environment at /home/ubuntu/anaconda3/envs/locust382:
#
# Name                    Version                   Build  Channel
_libgcc_mutex             0.1                        main
ca-certificates           2020.1.1                      0
certifi                   2020.4.5.1               py38_0
chardet                   3.0.4                    pypi_0    pypi
click                     7.1.2                    pypi_0    pypi
configargparse            1.2.3                    pypi_0    pypi
flask                     1.1.2                    pypi_0    pypi
flask-basicauth           0.2.0                    pypi_0    pypi
gevent                    20.5.0                   pypi_0    pypi
geventhttpclient-wheels   1.3.1.dev3               pypi_0    pypi
greenlet                  0.4.15                   pypi_0    pypi
idna                      2.9                      pypi_0    pypi
itsdangerous              1.1.0                    pypi_0    pypi
jinja2                    2.11.2                   pypi_0    pypi
ld_impl_linux-64          2.33.1               h53a641e_7
libedit                   3.1.20181209         hc058e9b_0
libffi                    3.3                  he6710b0_1
libgcc-ng                 9.1.0                hdf63c60_0
libstdcxx-ng              9.1.0                hdf63c60_0
locustio                  1.0b2                     dev_0    <develop>
markupsafe                1.1.1                    pypi_0    pypi
msgpack                   1.0.0                    pypi_0    pypi
ncurses                   6.2                  he6710b0_1
openssl                   1.1.1g               h7b6447c_0
pip                       20.0.2                   py38_3
psutil                    5.7.0                    pypi_0    pypi
python                    3.8.2               hcff3b4d_14
pyzmq                     19.0.1                   pypi_0    pypi
readline                  8.0                  h7b6447c_0
requests                  2.23.0                   pypi_0    pypi
setuptools                46.2.0                   py38_0
six                       1.14.0                   pypi_0    pypi
sqlite                    3.31.1               h62c20be_1
tk                        8.6.8                hbc83047_0
urllib3                   1.25.9                   pypi_0    pypi
werkzeug                  1.0.1                    pypi_0    pypi
wheel                     0.34.2                   py38_0
xz                        5.2.5                h7b6447c_0
zlib                      1.2.11               h7b6447c_3

I've switched to introduce-type-hints for now.
At least I can keep running my tests...
Let me know if you want to me clarify or test something on master, please.

HttpLocust has been renamed to HttpUser (and the Locust class has been renamed to User) in 1.0.
For all backwards incompatible changes see: https://docs.locust.io/en/latest/changelog.html
I'm fairly hopeful that your SNI problem should go away if you switch to 1.0.

Will try and let you know,
Thanks!

Tested Locust 1.0.1
No more SNI with FastHttpUser!
Thanks a lot!

repo: locustio/locust


text:
Add scenario concept

Bt default, in locust each User Class is loaded. When we have different applications or use cases we need to have many locustfiles and we have to redeploy the application each time we want to change of locustfile.
For that I add the concept of scenario in Locust. Instead of load every User instance, we have the ability to add a scenario and specify which User instance to run for each scenario.
The UI is modified only when they have scenario instance :

This change is full compatible for each client without scenario.

This is really cool.
I think it would be even more useful if you could specify user weights in the scenario as well, like this:
users = {User1: 3, User2: 5}
Can you also add a unit test that runs a scenario using the Web UI?

This is really cool.
I think it would be even more useful if you could specify user weights in the scenario as well, like this:
users = {User1: 3, User2: 5}
Can you also add a unit test that runs a scenario using the Web UI?

@cyberw I add UTs on WebUI.
Yes, I'm agree with you and it be also useful to add shape on scenario object. I think that is a good first iteration.
The weight could by fake like that:
        class MyUser(User):
            @task(1)
            def my_task(self):
                pass

        class MyUserForScenario1(MyUser):
            weight = 3

        class MyUserForScenario2(MyUser):
            weight = 1

        class Scenario1(Scenario):
            name = "My Scenario 1"
            users = [MyUserForScenario1]

        class Scenario2(Scenario):
            name = "My Scenario 2"
            users = [MyUserForScenario2]

@cyberw I add UTs on WebUI.
Yes, I'm agree with you and it be also useful to add shape on scenario object. I think that is a good first iteration.
The weight could by fake like that:
        class MyUser(User):
            @task(1)
            def my_task(self):
                pass

        class MyUserForScenario1(MyUser):
            weight = 3

        class MyUserForScenario2(MyUser):
            weight = 1

        class Scenario1(Scenario):
            name = "My Scenario 1"
            users = [MyUserForScenario1]

        class Scenario2(Scenario):
            name = "My Scenario 2"
            users = [MyUserForScenario2]

Lgtm. I will merge soon, unless someone has any objections.

Lgtm. I will merge soon, unless someone has any objections.

I guess the one objection one might have is that this does the same thing as the @tags functionality.
oh, and one more thing: we need to add command line support as well.

I guess the one objection one might have is that this does the same thing as the @tags functionality.
oh, and one more thing: we need to add command line support as well.

I think the command line support isn't full useful, because there are already possible to have multiple locustfile with different scenari. But if you want, I could add them to the PR.

I think the command line support isn't full useful, because there are already possible to have multiple locustfile with different scenari. But if you want, I could add them to the PR.

hmm... yea, I guess this is mainly useful for UI runs.
@heyman , do you have an opinion on whether to merge this? I think we talked about a while back but decided on adding the tags feature instead of this. I see the need for it, but I'm kind of +/- 0.

hmm... yea, I guess this is mainly useful for UI runs.
@heyman , do you have an opinion on whether to merge this? I think we talked about a while back but decided on adding the tags feature instead of this. I see the need for it, but I'm kind of +/- 0.

@mathcantin , can you merge the latest master into your branch (the automated build stuff has been updated, and it would be nice to see that it works on your branch)

@mathcantin , can you merge the latest master into your branch (the automated build stuff has been updated, and it would be nice to see that it works on your branch)

I wonder if we really need to introduce a whole new concept (Scenario) for this. Wouldn't we achieve the same thing if we instead implemented the ability to specify which User classes to run, from the Web UI? We could even add the ability to override the User classes' weight from the UI.

I wonder if we really need to introduce a whole new concept (Scenario) for this. Wouldn't we achieve the same thing if we instead implemented the ability to specify which User classes to run, from the Web UI? We could even add the ability to override the User classes' weight from the UI.

I merge the master into my branch. I still think the scenario object is more flexible in the future than a mix between User, Weigth, Shape on UI. But it's your call.

I'm +/- 0 (so I wont merge right now, but I wont object if somebody else does).
I see the point and the code seems well written. I think @heyman 's suggestion would be more flexible, but if nobody builds that (within reasonable time) then that point is moot :)

I indeed see the point for the scenarios usages but I don’t like either to continue modifying the current codebase with new python class based structures
I will vote/go for a redesign of the current codebase to make it more based on data rather than custom python classes construction to define more complex designs of load tests concurrent scenarios
Maybe it sounds crazy and don’t get me wrong... I find locust very interesting and awesome project but I think it needs a redesign to make it more lean and robust than today. Also with this redesign I will go also for a reactive ui using maybe reactjs or vuejs that reflect the status of the data tests options definitions

I kind of agree with @aek
Now that we have switched to ConfigArgparse, so we already support config files, perhaps the best solution would be to expand on that?
Scenarios, Load Shapes and possibly even User weights could fit in there (havent tried it or anything, but imo it would be worth exploring)

I see the use of this PR, but I'd rather not introduce a whole new concept just for specifying a group of User classes to use in a test.
What I suggested in my comment above should be possible to implement with less or equal amount of code, and should also have the added benefit of making the Web UI more powerful in general, allowing end-users to run different set of User classes "on the fly" (without having to create a new Scenario).
Regarding @aek's comment, that sounds a bit more like separate issue(s) to me. There's definitely parts of Locust's code base that could benefit from a rewrite (rewriting the Web UI in Vue.js is one such thing that I've thought about). However, I also think one should be wary of second system syndrome :).

authors: aek cyberw heyman mathcantin


text:
Error while extending Date

I try to extend the Date object and get following error:
ReferenceError: Reflect is not defined

and it highlights following line:
var instance = Reflect.construct(cls, Array.from(arguments));
		               ^

The file:
export default class Instant extends Date {
	constructor () {
		super()
	}
}

#2

Yeah, duplicate of https://github.com/loganfsmyth/babel-plugin-transform-builtin-extend/issues/2

You should mention that in the Readme to prevent further issues ;-)

authors: adius loganfsmyth zloirock


text:
Update keywords for iNS split forms

There are some inconsistencies in the code regarding the split forms for the incompressible Navier-Stokes equations. With this PR, the split forms called skew-symmetric-1split and skew-symmetric-2split are now skew-symmetric 1 and skew-symmetric 2 everywhere.

This is more complex than we expected. The tests are also failing for other reasons not related to the names of the averaging functions. Some of the control files seem to be wrong, and their names do not always match the ones in the workflow.

I am aware of the naming problem of the control file in the workflow, I'll fix that. What about the other things? All fixed then?

Everything seems to be fine with the last fix that you pushed. The control files were fine, just a silly mistake from my side... Now there is an issue with the VTKHDF module of horses2plt, but I will work on that on a different PR.

@Andres-MG, the error we are getting is weird and doesn't seem to have anything to do with what you changed right?

I think so. It seems that this test has not been run for some time, so I assume this issue is not new. The difference between the expected and the actual values is small, maybe it is not an error...

I would bet it works with ifort and not with gfortran

BTW, it runs in flexo with ifort + mkl

I think that this works with both, maybe the problem is that intel+MKL and gfortran use different libraries and the numerical errors are different.

authors: Andres-MG loganoz


text:
init script & RPM spec file

Just so we don't forget about this: Scale has an init (service) script and an RPM spec file that we should merge into this upstream repo. /cc @nhardt

started on this. https://github.com/nhardt/logcabin/tree/issue-74

more on https://github.com/logcabin/logcabin/compare/issue-74

authors: nhardt ongardie

repo: logcabin/logcabin

license: isc


text:
Possibility of using redux dev tools?

Haven't tried integrating them yet but as I dive deeper into a test app I'm quickly realizing how critical they are to my workflow. Would definitely be down to contribute, just wanted to get your opinion first

I personally haven't found any need for them when using the providers paradigm, since everything becomes so simple/predictable.  How are they critical to your workflow?  I'm curious.

They're a great visual tool for debugging action dispatching and state reduction. Not critical but a great (and immediate) sanity checker. The issue I mentioned here would have been immediately apparent, instead I had to dig to discover the source. The time travel feature has also occasionally been incredibly useful

I see.  I'm glad to integrate anything that would be helpful!

Related thread: https://github.com/loggur/react-redux-provide/issues/24

authors: slightlytyler timbur

repo: loggur/lumbur


text:
How to get tools from llamaHub

I want to use a function from a package called llama_hub, but if I write it according to the contents of my source, I cannot find the package. How can we solve this ethnic problem?
from llama_hub.trello import TrelloReader
from langflow import CustomComponent
from langchain.schema import Document
from tomlkit import document

class Component(CustomComponent):
    display_name: str = "TrelloReaderInLH"
    documentation: str = "TrelloReader"

    def build_config(self):
        return {"param": {"display_name": "Parameter"}}

    def build(self,

              api_key: str,
              api_token: str

              ) -> Document:

        loader = TrelloReader() # type: ignore

        documents = loader.load_langchain_documents(api_key = api_key, api_token = api_token) # type: ignore

        return documents

Hey, @yamonkjd Sorry for the delayed response. Have you managed to get this to work?

Thank you for answer. It was simply a problem with my twisted package.

repo: logspace-ai/langflow


text:
Discuss: Syntax of calculation expression

I am collecting opinions on the syntax of the expression.
Current: filter {  math { calculate => [ [ "-", "[var1]", "[var2]", "[result]" ] ] } }
Proposals:

filter {  math { calculate => [ [ "[result]", "[var1]", "-", "[var2]" ] ] } }
This switches the order to look more like written arithmetic.
filter {  math { calculate => [ "[result] = [var1] - [var2]" ] } }
This defines the expression as one string which is parsed into arrays as above.
filter {  math { calculate => [ "[result1] = %{[var1]} - %{[var2]}", "[result1] = %{[result1]} / 100" ] } }
This defines the expression as one string but uses interpolation and is parsed into arrays like the one above.

Currently the operands [var1] and [var2] must be fields but there is no reason why these can't be numeric values.

minor correction, the current syntax uses words for the operation:
math {  calculate => [  [ "add", "a_field1", "a_field2", "a_target" ] ] }
because of this, I think I prefer the current syntax to the proposal 1), because the first element being the operation it gives a better sense of what is happening: "ok this is adding var1 to var2 and placing the result in var3"
my concern with the string expressions (2 and 3) is providing good feedback when the user tries something insane :)

The string should parse a regex during register (or better still a custom validator so it parses at config validation)
I am ambivalent about the order of the multi element array version.

This sort of regex
/^(?<result>[^ =]+)\s*?=\s*?(?<arg1>\S+)\s*?(?<op>\+|-|\*{1,2}|\/|\%|fdiv)\s*?(?<arg2>\S+)\s*?$/

with results
Match 1
Full match  0-22  `[result1] = [var1] - 6`
Group `result`  0-9 `[result1]`
Group `arg1`  12-18 `[var1]`
Group `op`  19-20 `-`
Group `arg2`  21-22 `6`
Match 2
Full match  23-47 `[result1] = var1 ** var2`
Group `result`  23-32 `[result1]`
Group `arg1`  35-39 `var1`
Group `op`  40-42 `**`
Group `arg2`  43-47 `var2`
Match 3
Full match  48-71 `[result1] = var1 / var2`
Group `result`  48-57 `[result1]`
Group `arg1`  60-64 `var1`
Group `op`  65-66 `/`
Group `arg2`  67-71 `var2`
Match 4
Full match  72-100  `[result1] = [var1] fdiv var2`
Group `result`  72-81 `[result1]`
Group `arg1`  84-90 `[var1]`
Group `op`  91-95 `fdiv`
Group `arg2`  96-100  `var2`
Match 5
Full match  101-128 `[result1] = [var1] % [var2]`
Group `result`  101-110 `[result1]`
Group `arg1`  113-119 `[var1]`
Group `op`  120-121 `%`
Group `arg2`  122-128 `[var2]`
Match 6
Full match  129-151 `result1] = var1 * var2`
Group `result`  129-137 `result1]`
Group `arg1`  140-144 `var1`
Group `op`  145-146 `*`
Group `arg2`  147-151 `var2`
Match 7
Full match  152-171 `foo = [var1] + var2`
Group `result`  152-155 `foo`
Group `arg1`  158-164 `[var1]`
Group `op`  165-166 `+`
Group `arg2`  167-171 `var2`
Match 8
Full match  172-189 `foo = fdiv fdiv 5`
Group `result`  172-175 `foo`
Group `arg1`  178-182 `fdiv`
Group `op`  183-187 `fdiv`
Group `arg2`  188-189 `5`
Match 9
Full match  190-205 `bar  = 1 / foo `
Group `result`  190-193 `bar`
Group `arg1`  197-198 `1`
Group `op`  199-200 `/`
Group `arg2`  201-204 `foo`

The string should parse a regex during register (or better still a custom validator so it parses at config validation)

Right, so any mistake made by the user would result in an error saying "invalid format for math operation", the regex failure will be very opaque.
IMO I don't see a clear gain in UX in the proposals, but let's collect feedback from more folks 👍

We are discussing implementation details and not the merits of the syntaxes.
Better validation is possible.
We can use successive regexes from left to right to better mine the errors to present to the user. This would happen once.
For a string of bar = 1 / foo we

apply /^(?<result>[^ =]+)/

if match
extract match[:result]
move to the end of the match, string is 1 / foo
if no match
fail validation target field not found, expected format C = a + b; got #{string}

apply ^^\s*+=\s*+
extract and move or fail validation no equals sign found, expected format c = a + b; got #{string}
apply ^(?<arg1>\S+)\s*+(\+|-|\*{1,2}|\/|\%|fdiv)\s*+
extract and move or fail validation first operand not found, expected format c = A + b; got #{string}
apply ^\s*+(?<op>\+|-|\*{1,2}|\/|\%|fdiv)\s*+
extract and move or fail validation operator not found, expected format c = a OPERATOR b; got #{string} or invalid operator found, got #{operator}; expected one of #{OPERATORS.keys.join(', ')}
apply ^(?<arg2>\S+)\s*+$
extract or fail validation second operand not found, expected format c = a + B; got #{string}

my concern about the implementation maps to a concern of UX; if we support "[result] = [var1] - [var2]" as a string, I think it creates an expectation that the expression is extremely flexible.
I'd be tempted to try:
filter { math { calculate => [ "[result] = [var1] + [var2] + [var3]" ] } }
filter { math { calculate => [ "[result] = [var1] - [var2] * 23" ] } }
filter { math { calculate => [ "[result] = ([var1] - [var2]) / [var3]" ] } }
filter { math { calculate => [ "[result] = [var1]^2" ] } }
and so on. If the plan is to support more complex arithmetic then we can go forward with this approach, but for the current functionality I still think the current syntax provides a reasonable UX, i.e I prefer:
math { calculate => [ [ "sub", "[var1]", "[var2]", "[result]" ] ] }
# to:
math { calculate => [ [ "[result]", "[var1]", "-", "[var2]" ] ] }

different idea: why not use an RPN compatible notation so complex math would be possible and the interpretation would be simpler to implement?

@colinsurprenant
😄 Interesting idea (I considered it, no really, I did) but I fear very few users understand RPN.
I for one, very much do - having a) fixed HP scientific calculators way back in the Dark Ages and b) learned some form of programming with Forth which is exclusively a RPN + stack based language.
[btw, the smiley is a ref to stuff we were talking about earlier]
@jsvd & @colinsurprenant
For me the crucial judgement call now is that, if we go with a collection based expression now, how hard will it be to migrate code and users to a string based expression (if and) when its asked for?
Co-question, can (should) we support both syntaxes?

@guyboertje there is a slight learning curve but maybe the usage flexibility and implementation simplicity is worth it?  maybe more like this?
filter { math { target => "[result]", calculate => "[var1] [var2] - [var3] /" } }

so whatever is at the top of the stack is put in target.

Variation the not RPN string expression:
filter { math { target => "[result]", calculate => "[var1] - [var2]" } }
Complex RPN example (what is the calculation):
filter { math { target => "[result]", calculate => "[var1] [var2] add [var3] [var4] subtract multiply" } }
Would we support stack operations like swap?
Getting the reciprocal of a calculated value.
"1 [var1] [var2] add [var3] [var4] subtract multiply divide"
vs
"[var1] [var2] add [var3] [var4] subtract multiply 1 swap divide"

To sum up my opinion:

I think RPN is hard for a human to parse, it was made for computers to evaluate expressions with a stack.

The infix notation w/ parenthesis support is the best if the plugin is going to support nested expressions and more complex math, e.g. "([field1]+[field2])*2-[field3]^2". Humans are used to reading this.

If we only support a single operation then I suggest the current prefix (polish) notation with an array and named operations.

I think RPN is hard for a human to parse, it was made for computers to evaluate expressions with a stack.

I digress but wanted to note that some of the best calculators, operated by humans, where HPs using RPN 😁

How about this syntax ?
filter {
	math {
		add =>  {
		  "result1" => ["%{var1}", "%{var2}"]
                  "result2" => ["%{result1}", "%{var3}"]
		}
		subtract => {
		  "result3 => ["%{result2}", 99]
		}

We could allow only 2 elements in the array, or just define the order of operations left to right. It's basically the original syntax moved around some.

@jakelandis
I have been bitten before with using values, e.g. add and result1 as keys because they can't be defined twice. The simplicity of the current array of arrays is that it allows for left to right sequenced calculation where the later calcs use results from the earlier ones. In your example, doing a sequenced add divide add is not possible, however I do understand the calculation might be transformable to suit.
@webmat
For the sequencing reasons given above, a single target setting might be problematic. It would mean that we need to introduce the idea of registers that hold temporary results. In my mind, the register is an array that is the same size as the calculation array where index 0 stores the result of calculation 0 and so on with the target field being filled with the value of the last element. Users refer to temporary results in other calculations using (I suggest) a $1 -> index 0 etc. Registers allow for a better error message, e.g. user refers to a register with a nil value as a opposed to (in using the event as a temporary store) a field with a nil value, any field could have a nil value, we would need to track field names used for temporary results in order to give the same kind of error message, "Register $3 is empty, did you mean $0, $1 or $2? These registers have values: 0, -9 and 42".
But this only applies when calculations are not independent. If you want to do several separate calculations on different fields then a target is needed for each separate calculation.
But these sequences and separates with registers can be catered for:
filter {
  math {
    calculate => [
      {
        calculation => [
          ["+", "[var1]", "[var2]"], ["-", "[var3]", "[var4]"], ["*", "$1", "$2"]
        ],
        target => "[result1]" # <- register[-1]
      },
      {
        calculation => [
          ["-", "[ts_job_end]", "[ts_job_start]"]
        ],
        target => "[job_duration]" # <- register[-1]
      }
    ]
  }
}

OK I have definitely gone off the string expression style.
We could support a layout of prefix | infix | postfix for users preferred style of expression - it tells us where the operator is to be found.

Also, what is the consensus on enforcing bracket field references?
Doing so means we differentiate between "[$1]" being a field reference and "$1" being a register reference without ambiguity.

Once again, I'm all for conventions. I have been confused in the past with fields being referenced sometimes in brackets and sometimes not. I would go for the brackets here.

I also can't see any merit in supporting interpolation in operand strings e.g.
["+", "%{[var1]}", "%{[var2]}"]

I also can't see any merit in supporting interpolation in operand strings e.g.
["+", "%{[var1]}", "%{[var2]}"]

well, since values can only be numeric I don't see how using string  interpolation would be useful? are string operands possible??
OTOH just want to point out that in general there is no enforcement for using bracketed field reference (for root fields obviously) so I believe it would be the only place where this is strictly required? I don't really see a problem with that but could be confusing to some users that won't catch the note about being it necessary.

To clarify, requiring brackets for field names is really only needed if we introduce registers.
However, if a naming convention for register addresses can be devised that is intuitive and has a low collision potential with a users event field names (which are usually descriptive and not cryptic) then we don't need to enforce bracketed field names.
Something like one of these R[1], R(9), R{0}, ]1[, $[1], $(1), ${1}, %[0], &[1], &(0) springs to mind.
Basically, some prefix with an integer surrounded by brackets of some description.
Perhaps a separator based approach works too , R|0, R\0, R^0, although these are not so easy on the eye.
Another question, is zero based register index numbers intuitive to users that are not developers?

Conclusion:
I an going to stick with the current array based syntax but add registers.

authors: colinsurprenant guyboertje jakelandis jsvd webmat

repo: logstash-plugins/logstash-filter-math


text:
feat(dr-volume): forcibly activate a DR volume

Allow to forcibly activate a DR volume as long as there is a ready replica.
Modified activate API to receive the force parameter.
Add a volume.Status parameter ForciblyActivating
Ref: longhorn/longhorn#1512

I am thinking if adding a new field in volume spec is necessary.

or a global setting? but IMO it should handle each DR volume separately.

How about just blindly activating the DR volume if users set v.Spec.Standby to false via UI or kubectl?

Would it be dangerous if there is only one ready replica?
I think we could blindly activating the DR volume if users who knew the DR volume is not healthy set v.Spec.Standby to false
@innobead WDYT? and Does this ticket https://github.com/longhorn/longhorn/issues/1512 resemble more of a bug fixing or an improvement?

Would it be dangerous if there is only one ready replica?

No, since the backup is still there.
And for the UI action, we can still retain the flag force. For the kubectl operation, users should understand the risk.

authors: mantissahz shuo-wu

repo: longhorn/longhorn-manager


text:
Update the description of v2-data-engine setting

Which issue(s) this PR fixes:

Issue Longhorn/longhorn#7655
What this PR does / why we need it:
v1 and v2 date engines are separate, so the warning When applying the setting, Longhorn will restart all instance-manager pods. is not required.
Special notes for your reviewer:
Additional documentation or context

@mergify backport v1.6.x

authors: derekbit innobead


text:
fix(daemon): validate webhook by its domain

ref: https://github.com/longhorn/longhorn/issues/8005
The root cause is that we now have conversion-webhook(:9501), admission-webhook(:9502) in longhorn-manager
We set the readiness port to 9501
The order of starting is as follow

conversion-webhook
admission-webhook
upgrade
....

So there is a chance that the pod is not ready yet (readiness on 9501 hasn't succeeded) when the longhorn-manager starts to do the upgrade
It then fails to call the webhook by endpoint because there is no longhorn-manager pod ready.
Post \"https://longhorn-admission-webhook.longhorn-system.svc:9502/v1/webhook/validaton?timeout=10s\"

This PR fix it by validating the endpoint works by testing the domain instead of local address before doing the upgrade.

So there is a chance that the pod is not ready yet (readiness on 9501 hasn't succeeded) when the longhorn-manager starts to do the upgrade
It then fails to call the webhook by endpoint because there is no longhorn-manager pod ready.

I didn't get the point of why this PR would resolve this case... And before a longhorn-manager pod starts to do the upgrade, it should already start the webhook services by itself.

Hi @shuo-wu

And before a longhorn-manager pod starts to do the upgrade, it should already start the webhook services by itself.
Yes, correct, on the localhost.
However, because the k8s readiness check hasn't succeeded yet, K8s hasn't marked longhorn-manager pod as ready and added it to the endpoint of the k8s svc. So when doing the upgrade, it accessed the webhook by the endpoint longhorn-admission-webhook.longhorn-system.svc:9502, it then failed.

Hi @ejweber
Yes you are right, we should still check the status of local webhook services in the current pod. Thanks!

Hi @ejweber
I have added another check for the service availability, please take a look, thanks!

@mergify backport v1.6.x v1.5.x

authors: ChanYiLin innobead shuo-wu


text:
test: fix flaky test case test_extra_replica_cleanup

Which issue(s) this PR fixes:

Issue https://github.com/longhorn/longhorn/issues/7936
What this PR does / why we need it:
Replace assertion with wait mechanism.
Special notes for your reviewer:
Additional documentation or context

@mergify backport v1.6.x v1.5.x v1.4.x

repo: longhorn/longhorn-tests


text:
fix wait_for_snapshot_purge

Signed-off-by: Mohamed Eldafrawi mohamed.eldafrawi@rancher.com

LGTM.

Changes already merged in #256

authors: meldafrawi yasker


text:
Fix test_backup_status_for_unavailable_replicas

Proposal Change
The behavior changes after longhorn 3035.
Previous, the volume's backupStatus reflects the engine's backup status directly.
So, even the backup is completed, if we delete the corresponding replica, the
volume's backupStatus shows the engine's backup status with an error message.
Now, after longhorn 3035 was introduced, the volume's backupStatus reflects
the Backup CR status, not the engine's backup status anymore.
So, after the backup is completed, even we delete the corresponding replica,
the volume's backupStatus shows the Backup state is Completed.
We change the test case to during the backup creation in progress,
deletes the responsible replica to make the backup falls into Error
state and with an error message.
Issue
https://github.com/longhorn/longhorn/issues/3035

@jenting after merging, need to backport to 1.2.x.

authors: innobead jenting


text:
[BUG] Nightly Upgrade Test: test_volume_reattach_after_engine_sigkill  sometimes failed

Describe the bug
sometimes test_volume_reattach_after_engine_sigkill  test failed after upgrade
To Reproduce
Steps to reproduce the behavior:

Install Longhorn v1.0.0
Upgrade Longhorn to master
Run test_volume_reattach_after_engine_sigkill test

Expected behavior
test should pass
Log
Error Message
AssertionError
Stacktrace
client = <longhorn.Client object at 0x7f78e311a110>
core_api = <kubernetes.client.apis.core_v1_api.CoreV1Api object at 0x7f78e3f9df50>
volume_name = 'longhorn-testvol-5qiiqy'
pod_make = <function pod_make.<locals>.make_pod at 0x7f78e3d6bdd0>

    def test_volume_reattach_after_engine_sigkill(client, core_api, volume_name, pod_make):  # NOQA
        """
        [HA] Test if the volume can be reattached after using SIGKILL
        to crash the engine process

        1. Create PV/PVC/Pod. Make sure Pod has the liveness check.
        2. Wait for the pod start and the volume healthy.
        3. Write random data to the pod and get the md5sum.
        4. Crash the engine process by SIGKILL in the engine manager.
        5. Wait for volume reattached.
        6. Wait for pod to be restarted.
        7. Check md5sum of the data in the Pod.
        8. Check if data can be still written to the volume.
        """
        data_path1 = "/data/test1"
        data_path2 = "/data/test2"

        pod_name, _, _, md5sum = \
            prepare_pod_with_data_in_mb(client, core_api,
                                        pod_make,
                                        volume_name,
                                        data_size_in_mb=DATA_SIZE_IN_MB_1,
                                        data_path=data_path1)

        crash_engine_process_with_sigkill(client, core_api, volume_name)

        wait_for_volume_detached(client, volume_name)
        wait_for_volume_healthy(client, volume_name)

>       wait_for_pod_restart(core_api, pod_name)

test_ha.py:1318:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

core_api = <kubernetes.client.apis.core_v1_api.CoreV1Api object at 0x7f78e3f9df50>
pod_name = 'longhorn-testvol-5qiiqy-pod', namespace = 'default'

    def wait_for_pod_restart(core_api, pod_name, namespace="default"):
        pod = core_api.read_namespaced_pod(name=pod_name,
                                           namespace=namespace)
        restart_count = pod.status.container_statuses[0].restart_count

        pod_restarted = False
        for i in range(RETRY_COUNTS):
            pod = core_api.read_namespaced_pod(name=pod_name,
                                               namespace=namespace)
            count = pod.status.container_statuses[0].restart_count
            if count > restart_count:
                pod_restarted = True
                break

            time.sleep(RETRY_INTERVAL)
>       assert pod_restarted
E       AssertionError

common.py:3586: AssertionError

Environment:

Longhorn version: master
Kubernetes version: v1.17.2
Node OS type and version: Ubuntu 18.04

Additional context:
longhorn-upgrade-tests/122

Tried multiple times, couldn't reproduce the issue on a cluster with 1 etcd/control plane and 3 workers node. os type - ubuntu 18.04

Passed for the last 10 run. Upgrade test 103-112.
https://ci.longhorn.io/job/public/job/longhorn-upgrade-tests/test_results_analyzer/

authors: khushboo-rancher meldafrawi yasker

repo: longhorn/longhorn


text:
volume failed to attach to node

Question

when i deployed longhorn, the pod cannot use the pvc.

Environment

Longhorn version: 1.3.1
Kubernetes version: v1.24.2
Node config

OS type ：centos7
CPU per node: 4
Memory per node: 8G
Disk type：hdd
Network bandwidth and latency between the nodes: inner network

Underlying Infrastructure: Baremetal

logs

csi-attach log

Error processing "csi-eb0467592e57ad3f10ba2cc1aae84c15b350632a0425e4e5735767af8b4a76c6": failed to attach: rpc error: code = DeadlineExceeded desc = volume pv-test failed to attach to node

longhorn-pvc example  pod logs

Warning  FailedScheduling    21m                  default-scheduler        0/3 nodes are available: 3 persistentvolumeclaim "pvc-test" not found. preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling.
Warning  FailedScheduling    20m                  default-scheduler        0/3 nodes are available: 3 persistentvolumeclaim "pvc-test" not found. preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling.
Normal   Scheduled           20m                  default-scheduler        Successfully assigned default/volume-pv-test to wf-dev-mid-k8s-m
Warning  FailedMount         13m                  kubelet                  Unable to attach or mount volumes: unmounted volumes=[vol], unattached volumes=[kube-api-access-vrwh8 vol]: timed out waiting for the condition
Warning  FailedMount         2m11s (x7 over 18m)  kubelet                  Unable to attach or mount volumes: unmounted volumes=[vol], unattached volumes=[vol kube-api-access-vrwh8]: timed out waiting for the condition
Warning  FailedAttachVolume  3s (x17 over 18m)    attachdetach-controller  AttachVolume.Attach failed for volume "pv-test" : rpc error: code = DeadlineExceeded desc = volume pv-test failed to attach to node wf-dev-mid-k8s-m

how to slove this question?
please help me，tks a lot.

 "pvc-test" not found
Can you check if the PVC is already created or missing?

"pvc-test" not found

the pvc and pv existed.
[root@wf-dev-mid-k8s-m ~]# kubectl get pvc
NAME       STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS      AGE
pvc-test   Bound    pv-test   10Gi       RWO            longhorn-static   93m

[root@wf-dev-mid-k8s-m ~]# kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM              STORAGECLASS      REASON   AGE
pv-test   10Gi       RWO            Retain           Bound    default/pvc-test   longhorn-static            94m

yes .
is it wrong ?

Can you provide the support bundle?

please tell me how to get this。。。

Please refer to https://www.suse.com/support/kb/doc/?id=000020145
You can also check longhorn-manager and see if there are related error messages.

@zhuw0312 I cannot download the support bundle from the link. BTW, it's not related to the storage-network.

https://trumantaurus.oss-cn-hangzhou.aliyuncs.com/longhorn-support-bundle_ca737ab5-56b8-44ba-8fbc-d7d47bd45434_2022-08-22T12-22-44Z.zip
please try again.
ok,got it.

After investigating the support bundle, I found you change the hostpath of the daemonset during installation.
Can you check this ticket https://github.com/longhorn/longhorn/issues/4441?

@derekbit it workerd after  changing daemonset hostpath config from /data/longhorn to /var/lib/longhorn.
thank u very much.


text:
[BUG] Fix misleading error messages when creating a mount point for a backup store

Describe the bug (🐛 if you encounter this issue)
If the mount point doesn't exist, the check for syscall.ENOENT.Error() (code) will fail because the error message returned by mount.IsNotMountPoint is different. Although this won't introduce bugs and the mount point can be created in the end,
the error message might be misleading for users.
To Reproduce
Steps to reproduce the behavior:

Create a Longhorn cluster using master branch
Set NFS backup store
Create a volume
Execute backup. If the mount point is not existing inside the longhorn-manager-r pod, the error will show "...was identified as corrupted by ReadDir...". The backup should succeed.

Expected behavior
A clear and concise description of what you expected to happen.
Log or Support bundle
If applicable, add the Longhorn managers' log or support bundle when the issue happens.
You can generate a Support Bundle using the link at the footer of the Longhorn UI.
Environment

Longhorn version:
Installation method (e.g. Rancher Catalog App/Helm/Kubectl):
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version:

Number of management node in the cluster:
Number of worker node in the cluster:

Node config

OS type and version:
CPU per node:
Memory per node:
Disk type(e.g. SSD/NVMe):
Network bandwidth between the nodes:

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal):
Number of Longhorn volumes in the cluster:

Additional context
Add any other context about the problem here.

@innobead
No need to backport to v1.3.3 and v1.4.2. This is caused by my refactoring.

Closing w/o QA testing, since longhorn-manager, instance-manager, and engine are all updated and this is about log update. Let's follow up with the daily regression.
cc @longhorn/qa


text:
Upgrade to 2.0 breaks YAMLS with Longer Strings by Splitting them onto a Following Line

I have been using this extension for a while, without issue, but the recent upgrade to 2.0 causes problems where their weren't problems before.
I have CodeUris in an AWS template.yml that when upgraded to 2.0, it splits the string onto a separate line.
For example:
CodeUri: "s3://#{bucketName}/#{Octopus.Action[Upload Lambda to S3].Output.Package.FileName}"

On save, this autoformat changes to:
CodeUri: "s3://#{bucketName}/#{Octopus.Action[Upload Lambda
  to S3].Output.Package.FileName}"

Which breaks the YAML.
The previous 1.1 version does not do this and works as expected, so my current workaround is to tell my entire dev team to install the previous version and turn off auto update.

Same issue detected on my side :(

Same here. Is there a way to disable it?

Hi, all, the latest version 2.2.0 has just released with a new option lineWidth which defaults to 0 and you can get rid of this issue.

authors: Tchoupinax eugene-marchanka longkai maplion

repo: longkai/kubernetes-yaml-formatter


text:
Names of created routes are not clear

I was struggling with iron router on how to add the preview and send routes to my onBeforeAction filter.
I think it woud be great add in the docs or in the logs at startup the name, in addtion to the path, of the routes created.
for a template named templateTest, the route name was:
"previewtemplateTestEmail"
that was not obvious, or maybe i missed something !
Thanks,
Best.

Thanks, @mcoenca. I'll add some docs on that.

authors: johanbrook mcoenca

repo: lookback/meteor-emails


text:
don't return non existent combination

in this model
sql: actual_source is ||
        SELECT "red" as color,"Gernamy" as state,
        1 as Qty_sold,cast("2021-01-01" as date) as date_Transaction
        UNION ALL SELECT "red", "USA",1,"2021-01-04"
        UNION ALL SELECT "black", "Japan",1,"2021-01-02"
        UNION ALL SELECT "black", "China",1,"2021-01-02"
        UNION ALL SELECT "yellow", "China",1,"2021-01-02"
      ;;

source: Actual is from_sql(actual_source)
{

  measure : Quantity is Qty_sold.sum()
            Color_Sum is all(Quantity,color)
            Total is all(Quantity)

Query: Actual_by_state is {
  group_by : state,color
  aggregate:Quantity,Color_Sum,Total
}
}

All  is amazing !!!!
but some combination don't exist and maybe should be filtered out by default

Thanks @djouallah!  Yep, that's an oversite.  Now, how to fix it? :)

authors: djouallah lloydtabb

repo: looker-open-source/malloy


text:
바이너리 배포 프로세스

https://github.com/loom/loom-core/issues/2 에 이어서 논의를 이어갑니다.

semver를 사용한 CD(continuous delivery) 제안드립니다.
병합된 PR이 semver 기준으로 버전 증가에 해당하면 CD를 트리거. 이때 버전정보과 릴리즈노트가 필요함.
CD 트리거는 아래와 같이 git annotation 태그 이용을 제안합니다.
git tag -a 1.0.1 -m 릴리즈노트추가
git push origin 1.0.1

travis에서 위 방법을 지원할 꺼라고 생각합니다. 구성 방법은 해보질 않아서 잘 모릅니다. -_-;;

authors: jwChung mhyeon-lee

repo: loom/loom-core


text:
Images loading for a long time

hi. when loading images - they are loaded for a long time.

@googlle
How exactly are we to debug your problem without seeing source code? Your problem seems to be unique to the design of the app, or else we'd be bombarded with tens of issues like yours.
Bottom line: Show some source codes, including the correct URLs of the images you're trying to download.

authors: fineswap googlle

repo: loopj/android-async-http


text:
JSON and multipart mixed Request

Hi, i'm trying to make a request with some JSON data and a file, it looks like this:
METHOD: post
HEADERS:
Authorization   Basic d2Vic2VydmljZTpyM05hdTE3Rw==
Content-Type    multipart/form-data;boundary=xxxxxxxx
BODY:
--xxxxxxxx
Content-Disposition: form-data; name="jsonFile"
Content-Type: application/json
{"model":"Premium","deviceLongitude":4.79337638,"pseudo":"nickname","deviceLatitude":45.7671507,"year":"2005","email":"email@mail.com","deviceLocale":"fr_FR","title":"my picture"}
--xxxxxxxx
Content-Disposition: form-data; name="imgName"
Content-Type: image/jpeg
//Image data array
/9j/4AAQSkZJRgABAQAAAQABAAD/4QBYRXhpZgAATU0AKgAAAAgAAgESAAMAAAAB
AAEAAIdpAAQAAAABAAAAJgAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAB4KAD
AAQAAAABAAACgAAAAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQH/wAARCAKAAeADAREAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAA
AAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF
--xxxxxxxx
How can I accomplish this request with loopj?

method to use is here: https://github.com/loopj/android-async-http/blob/master/library/src/main/java/com/loopj/android/http/RequestParams.java#L283
Well, as simple as it can get is to use RequestParams, like this:
RequestParams rp = new RequestParams();
// using method put(String key, File file, String contentType, String customFileName)
rp.put("jsonFile", new File("path/to/json/file"), "application/json", "jsonFile");
rp.put("imgName", new File("path/to/img/file"), "image/jpeg", "imgName");
AsyncHttpClient ahc = new AsyncHttpClient();
ahc.post(this /* context */, URL, rp /* request params instance */, responseHandler);

authors: njgarcia smarek


text:
Justin/win32 support

Unfortunately I'm not familiar with eslint and am not sure how to get it to run so I haven't run the tests yet. I thought I'd throw it out there for now while I try to figure it out.

Nice!!! @justinmchase
Thanks a lot!
I will check it out tomorrow morning at work ( I'm in Berlin/Germany ) and will set up a contributing.md with further instructions on how to deal with tests and stuff.

@justinmchase
Had a quick look without testing it.
Big thanks man! :+1:
I left some notes. And also an update of the "Pre-requisites" section in the readme would be great to cover also the other platforms.
Will check it tomorrow in detail then.
And I'm usually picky regarding coding style, so please don't take it personally when I mark some more stuff tomorrow ( I like spaces ;) ). :)

@stefanjudis NP! Be picky I'll fix whatever you want. Also, I just confirmed that this works on linux as well (for building windows setup).
You have to apt-get wine and nsis, I'll add that in the pre-reqs page like you asked.

Thanks man!
You'll hear from me tomorrow then. :)
PS. Currently npm.debug.log is checked in. ;)

I think I've figured out a way to make the mac .dmg file from linux also. I will test that tomorrow and probably make a new pull request for it.
If it works then this means you'll be able to create installers for mac and windows from a travis-ci build, which will be really nice.

@justinmchase Man, this sounds awesome. I'm setting up the contributing.md right now. :)

@justinmchase I pushed some updates to the readme and tweaked the npm test command a bit more to include also coding style rules.
So after a quick merge master and npm test check we're ready to merge this PR.
Thanks!!! :tada:

Nice. I'll do the linux build work in another branch now. Thanks for this :D

I merged and ran eslint successfully.

@justinmchase Alright. Then let's do it!
Thanks again for your effort. :bowtie:

It's out.
https://www.npmjs.com/package/electron-builder
:sunglasses:
My test for macos worked fine. If you could confirm, that'd be great. :blush:

authors: justinmchase stefanjudis

repo: loopline-systems/electron-builder


text:
After Spring Cleaning, chat does not work

say and say_team still work in console..

+1 Chat does not work.

https://www.reddit.com/r/DotA2/comments/4buau7/chat_not_working_in_spring_cleaning/

@loopuleasa has been good about showing up when breaking bugs reared their heads in the past, so I imagine they will continue to do so. That said, the engine still has a few quirks that need to be worked out. I've contributed before but recently have been too lazy to fix anything since nothing was fully broken. We may need to organize a Spring Cleaning of our own; I propose a milestone of some kind. I'll gladly take a look through and try to fix things if we identify problem areas.
/rant
All right, back on topic: Several features in the client seem downright broken at the moment, and the syntax for commands has gotten more restrictive (Pimpmuckl detailed that little bug). Some issues may be fixed with further client updates, while others may have to be fixed by combing the config.

Use the ingame bind and -
you have to comment out 2 lines in dota2_gameplay_mode.cfg:
bind "KP_ENTER" "say"
bind "ENTER" "say
and comment out all the unbindall's from:
dota2_keybind_default and the 3 XXXX_pressed ones

@aspalmer Has this been successful for you? I commented out those two lines but chat still breaks as soon as i press space bar.

Unfortunately I won't have a chance to go through the config for at least a week due to university commitments, however after that I will make sure everything gets updated to a working state, and move on to integrate the new features from the spring cleaning update in the config, provided @loopuleasa or someone else doesn't get to it first.

@Sembrani I've just finished all my college tests and have no problem parsing through it all I just don't exactly know how to know what needs changing. Do you know of any resources to learn about this stuff?

@Acerecon You need to uncomment the 4 instances of unbind all. It's in dota2_keybind_default and the 3 XXXX_pressed ones

@aspalmer Yup I did that as well. The image is in all four pressed ones.

And just to be 100% clear these are the lines you said yuo also commented out in default?

I'm not comfortable with removing all occurrences of unbindall as a workaround due to the unintended consequences it may lead to.
unbindall is used at the beginning of each modifiers list of keybindings in order to prevent overlap from one set of bindings onto another.
For example lets say you use SPACE+F4 as your activate glyph key, and perhaps you use ALT+F4 as a binding to perform some other action, lets say the "gameui_activate" command which returns you to the main Dota menu (same as clicking the top left button in the game UI).
If you do not use the F4 naked/without a modifier as a bound key in this hypothetical example then if you accidentally press F4 without any modifier key you'll either unintentionally activate the glyph, or unintentionally return to the main menu, depending on whether you have more recently used an alt or space modifier.
Likewise any other key that you have bound as a modifier but not as an unmodified key will execute unintended commands if pressed without a modifier.
You could as a workaround replace the unbindall command with a manual list of every key you use whatsoever in the config that you wish to be unbound e.g.
unbind F1
unbind F2
...
unbind Q
unbind W
ad nauseum in order to preserve the original game UI binding of the enter key to the say command, but that's doesn't seem to be a very practical solution. Although we may be stuck with it if one does not want to be caught out by unintended bindings.
I suspect that the problem with binding a key to the say command is an unintended change from the spring cleaning patch and may potentially be fixed at Valves end, although given the amount of issues introduced by the patch it is possible this is a low priority and may be overlooked or take a while.
So while removing unbindall may be a workaround, it doesn't seem to me a proper fix and should be used with caution.

I agree, it's not a fix. But it was the fastest way to make my dota playable. I think they will fix the binding stuff in one of the hotfixes in the next day or two though and I can revert my local changes.

@aspalmer You ever try to see where our differences lie? I can't seem to get your quick fix to work.

I think the reason commenting out the first "unbindall" works, is so that the original DotA keybind ends up being used.
@Acerecon, if you want to learn, the fastest way is just to read through what is already there, and try to figure out what each line does. The biggest issue with the config right now is the fact that having " " around the bound command no longer works properly. I hope this isn't the case for aliases, though I haven't checked yet.
If someone wants to, just remove all the quotes from around bound commands, so
bind "key" "COMMAND"
becomes
bind "key" COMMAND, that would likely be the fastest way to get most things working again.

I will get on it asap when I get home.
I anticipated something like this.

@Sembrani it can't be the quotes, these manta-generated keybinds work for me:
bind "KP_0" "say_team no"
bind "KP_1" "say_team yes"
bind "KP_2" "chatwheel_say 59"
bind "KP_3" "chatwheel_say 81"
bind "KP_4" "chatwheel_say 75"
bind "KP_5" "chatwheel_say 76"
bind "KP_6" "chatwheel_say 82"
bind "KP_7" "say > That just happened."
bind "KP_8" "chatwheel_say 53"
bind "KP_9" "chatwheel_say 85"
bind "F11" "exec autoexec.cfg"

Maybe the quotes are only valid, when there actually is a space/colon, which requires them?

I suppose that is possible... Makes it a bit painful though.
On Sat, 26 Mar 2016, 00:17 Florian Wendelborn notifications@github.com
wrote:

@Sembrani https://github.com/Sembrani it can't be the quotes, these
manta-generated keybinds work for me:
bind "KP_0" "say_team no"
bind "KP_1" "say_team yes"
bind "KP_2" "chatwheel_say 59"
bind "KP_3" "chatwheel_say 81"
bind "KP_4" "chatwheel_say 75"
bind "KP_5" "chatwheel_say 76"
bind "KP_6" "chatwheel_say 82"
bind "KP_7" "say > That just happened."
bind "KP_8" "chatwheel_say 53"
bind "KP_9" "chatwheel_say 85"
bind "F11" "exec autoexec.cfg"
Maybe the quotes are only valid, when there actually is a space/colon,
which requires them?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/loopuleasa/Dota2-TheCore-Config-Engine/issues/137#issuecomment-201273283

Also I think I found a solution on how to avoid unbindall, it's not a lot of work for Manta, since it's computer-generated but would be for TheCore. Beware though, because it looks like cancer-code.
// # Unloader:
alias custom_unload "custom_unload_0; custom_unload_1; custom_unload_2; custom_unload_3; custom_unload_4; custom_unload_5; custom_unload_6; custom_unload_7; custom_unload_8; custom_unload_9; custom_unload_10"
alias custom_unload_0 "unbind 1; unbind 2; unbind 3; unbind 4; unbind 5"
[...]
alias custom_unload_10 "unbind F11"

The reason I had to split it into parts is that there is a maximum command length.

Are dota_camera_set_lookatpos calls broken too?

https://twitter.com/PimpmuckL/status/713147482285469699
bind is unchanged. It's the other commands where quotes get wonky.

apparently I won't be making the fixes today, maybe tomorrow

The latest patch fixed this issue for me.

Can confirm it's fixed.

Nice, it was apparently a general bug.
Only thing I notice now is middle mouse camera grip not working.

@loopuleasa Check my pull: it should fix that plus partially fix the autoattack, assuming that was not patched as well.

Tested both of them, they do not work currently.
Will review your pull and recheck afterwards.

@loopuleasa Strange they worked for me yesterday, I'll try today since I haven't tried on the patch yet.

I mean, tested it without the pull.
Didn't test your changes yet.

Everything seems to be working fine.
Thanks everyone.

@loopuleasa , how did you fix the chat issue?

Valve patched it. Some bug on their end, where it wouldn't let you bind the say command.

@loopuleasa can't this be closed?

Should be long closed, after all Valve fixed the bug. @Ranguvar or @loopuleasa should close this as it is a non-issue.

authors: 0x4C Acerecon AetherV Enf0 Ranguvar Sembrani Tabby- aspalmer crimsonvspurple dodekeract jaccarmac loopuleasa nickcorona


text:
Swap symbols for PS5 Create and Options buttons

Hi! Love these icons 👍 just wanted to make a small adjustment - the symbols on the PS5 Create and Options buttons seem to be swapped judging from the angle of the button outlines. The Create button is the left-leaning one and the Options button is the right-leaning one:

Here's the change:

I've only changed the source svg file for now, let me know if all looks good and I can prepare the individual svg and png files. Thanks! 😁

I seem to have issues with PS5 prompts... #12
This looks great, thank you for making a fix!
To merge though, I'll need updates to

previews/preview.svg and previews/ps5_preview.svg (and then exports to png for both). This can be done by copy/pasting the new icons over the olds ones in the svg, and
the corresponding /png and /svg icons.

Ok, I've updated all but the preview pngs. I'm missing the Megusto font so the "B" in "Mr. Breakfast" isn't quite right:

If that's the only place the font is used, could you convert that "B" to a path instead of text (like with the "M") so that Megusto isn't a dependency? I found some sites offering a free download of the font but I don't necessarily trust them.

Yes I can do that! /meta/center_title is a path version of the "Mr. Breakfast," but I'll go through this fork and make them paths

And thank you for your README copy edits and editions 😁

I mistakenly edited main and not this PR. Let me get that fixed. Sorry for the inconvenience

I mistakenly edited main and not this PR. Let me get that fixed. Sorry for the inconvenience

Done 👍

Awesome, thank you!


text:
broaden compat bounds

This broadens the compat bounds for both StructArrays and PrettyTables.  I assume there was a reason for the specific StructArrays compat bound, but this passes tests, so I'm not sure what that is.

Maybe the broken version has been yanked. Will run the CI and then merge. Thanks 👍

Isn't it easier to just do 0.6.10?  It's just a minor bugfix version difference, I wouldn't lose any sleep over disallowing older 0.6.

Indeed that one didn't work, you're right 👍

Thanks.  Just a reminder to please tag when you get a chance.

authors: ExpandingMan lorenzoh


text:
Intermittent ENOENT

Bug description
During GHA run it couldn't find diff for one of the pages for some reason
How to reproduce
Intermittent, saw it once so far
Expected behavior
No response
Lost Pixel information

lost-pixel logs from CI
Run lost-pixel/lost-pixel@v3.8.2
/usr/bin/docker run --name lostpixellostpixelv382_0c3f5f --label 09[7](https://github.com/Maxim-Mazurok/maxim.mazurok.com/actions/runs/7328462883/job/19956775494#step:11:8)6f5 --workdir /github/workspace --rm -e "COMPOSER_PROCESS_TIMEOUT" -e "COMPOSER_NO_INTERACTION" -e "COMPOSER_NO_AUDIT" -e "INPUT_FINALIZE" -e "INPUT_CACHE_KEY" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKFLOW_REF" -e "GITHUB_WORKFLOW_SHA" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "GITHUB_STATE" -e "GITHUB_OUTPUT" -e "RUNNER_OS" -e "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_ENVIRONMENT" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e "ACTIONS_CACHE_URL" -e "ACTIONS_RESULTS_URL" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/maxim.mazurok.com/maxim.mazurok.com":"/github/workspace" lostpixel/lost-pixel:v3.[8](https://github.com/Maxim-Mazurok/maxim.mazurok.com/actions/runs/7328462883/job/19956775494#step:11:9).2
Environment:
WORKSPACE=/github/workspace
CI_BUILD_ID=7328462883
CI_BUILD_NUMBER=61
EVENT_PATH=/github/workflow/event.json
COMMIT_HASH=b378d5db8ca5ba04a4ee[9](https://github.com/Maxim-Mazurok/maxim.mazurok.com/actions/runs/7328462883/job/19956775494#step:11:10)9d8bc4141de877[10](https://github.com/Maxim-Mazurok/maxim.mazurok.com/actions/runs/7328462883/job/19956775494#step:11:11)8f6
COMMIT_SHA=b378d5db8ca5ba04a4ee99d8bc4[14](https://github.com/Maxim-Mazurok/maxim.mazurok.com/actions/runs/7328462883/job/19956775494#step:11:15)1de877108f6
COMMIT_REF_NAME=main
REPOSITORY=Maxim-Mazurok/maxim.mazurok.com

Version: 3.8.2
Loading project config ...
Current working directory: /github/workspace
Looking for config file: /github/workspace/lostpixel.config.(ts|js|cjs|mjs)
✅ Found config file: /github/workspace/lostpixel.config.ts
🚀 Starting Lost Pixel in 'generateOnly' mode
📂 Creating shot folders
📸 Creating shots
Removing 0 files from .lostpixel/current/
Removing 0 files from .lostpixel/difference/
Found 0 pages from external loader

=== [Page Mode] http://[17](https://github.com/Maxim-Mazurok/maxim.mazurok.com/actions/runs/7328462883/job/19956775494#step:11:18)2.17.0.1:8080 ===

Prepared 8 pages for screenshots
[1/8] Taking screenshot of '/!index ' (/!index)
[2/8] Taking screenshot of '/blog/!index ' (/blog/!index)
[3/8] Taking screenshot of '/blog/socials-calendar ' (/blog/socials-calendar)
[4/8] Taking screenshot of '/blog/typescript-excess-property-checks ' (/blog/typescript-excess-property-checks)
[5/8] Taking screenshot of '/blog/google-ads-custom-conversion-setup ' (/blog/google-ads-custom-conversion-setup)
[1/8] Screenshot of '/!index' taken and saved to '.lostpixel/current/!index.png' in 3.072s (/!index)
[6/8] Taking screenshot of '/blog/ignore-internal-traffic-in-google-analytics ' (/blog/ignore-internal-traffic-in-google-analytics)
[3/8] Screenshot of '/blog/socials-calendar' taken and saved to '.lostpixel/current/blog/socials-calendar.png' in 3.092s (/blog/socials-calendar)
[7/8] Taking screenshot of '/blog/visual-testing-percy-gha-slack ' (/blog/visual-testing-percy-gha-slack)
[5/8] Screenshot of '/blog/google-ads-custom-conversion-setup' taken and saved to '.lostpixel/current/blog/google-ads-custom-conversion-setup.png' in 3.570s (/blog/google-ads-custom-conversion-setup)
[8/8] Taking screenshot of '/blog/meta-pixel-traps-in-app-browsers ' (/blog/meta-pixel-traps-in-app-browsers)
[2/8] Screenshot of '/blog/!index' taken and saved to '.lostpixel/current/blog/!index.png' in 4.341s (/blog/!index)
[4/8] Screenshot of '/blog/typescript-excess-property-checks' taken and saved to '.lostpixel/current/blog/typescript-excess-property-checks.png' in 4.347s (/blog/typescript-excess-property-checks)
[7/8] Screenshot of '/blog/visual-testing-percy-gha-slack' taken and saved to '.lostpixel/current/blog/visual-testing-percy-gha-slack.png' in 4.6[26](https://github.com/Maxim-Mazurok/maxim.mazurok.com/actions/runs/7328462883/job/19956775494#step:11:27)s (/blog/visual-testing-percy-gha-slack)
[6/8] Screenshot of '/blog/ignore-internal-traffic-in-google-analytics' taken and saved to '.lostpixel/current/blog/ignore-internal-traffic-in-google-analytics.png' in 4.689s (/blog/ignore-internal-traffic-in-google-analytics)
[8/8] Screenshot of '/blog/meta-pixel-traps-in-app-browsers' taken and saved to '.lostpixel/current/blog/meta-pixel-traps-in-app-browsers.png' in 5.[34](https://github.com/Maxim-Mazurok/maxim.mazurok.com/actions/runs/7328462883/job/19956775494#step:11:35)7s (/blog/meta-pixel-traps-in-app-browsers)
Screenshots done!
Creating shots took 9.174 seconds
🔍 Checking differences
Comparing 8 screenshots using 'pixelmatch' as compare engine
[1/8] Comparing '/!index' (/!index)
[2/8] Comparing '/blog/!index' (/blog/!index)
[3/8] Comparing '/blog/socials-calendar' (/blog/socials-calendar)
[4/8] Comparing '/blog/typescript-excess-property-checks' (/blog/typescript-excess-property-checks)
[5/8] Comparing '/blog/google-ads-custom-conversion-setup' (/blog/google-ads-custom-conversion-setup)
[6/8] Comparing '/blog/ignore-internal-traffic-in-google-analytics' (/blog/ignore-internal-traffic-in-google-analytics)
[7/8] Comparing '/blog/visual-testing-percy-gha-slack' (/blog/visual-testing-percy-gha-slack)
[8/8] Comparing '/blog/meta-pixel-traps-in-app-browsers' (/blog/meta-pixel-traps-in-app-browsers)
[1/8] No difference found. (/!index)
[2/8] No difference found. (/blog/!index)
[3/8] No difference found. (/blog/socials-calendar)
[4/8] No difference found. (/blog/typescript-excess-property-checks)
[5/8] No difference found. (/blog/google-ads-custom-conversion-setup)
[6/8] No difference found. (/blog/ignore-internal-traffic-in-google-analytics)
[7/8] No difference found. (/blog/visual-testing-percy-gha-slack)
❌ ENOENT: no such file or directory, open '.lostpixel/difference/blog/meta-pixel-traps-in-app-browsers.png'
Sending anonymized telemetry data.

hey @Maxim-Mazurok! thanks for the reporting! This usually happens for reasons not related to lost-pixel execution, when our runner could not open a page, for example, or the page errored by itself. My usual recommendation is to first make sure that the implementation is ok and that nothing breaks when you run your app on CI, and then, by exclusion method, try to figure out what is wrong.
If it gets reproducible though - would be super happy to look into that with you and help with the fix!

Got the same when running locally:
=== [Page Mode] http://localhost:8080/ ===

Prepared 8 pages for screenshots
[1/8] Taking screenshot of '/!index ' (/!index)
[2/8] Taking screenshot of '/blog/!index ' (/blog/!index)
[3/8] Taking screenshot of '/blog/socials-calendar ' (/blog/socials-calendar)
[4/8] Taking screenshot of '/blog/typescript-excess-property-checks ' (/blog/typescript-excess-property-checks)
[5/8] Taking screenshot of '/blog/google-ads-custom-conversion-setup ' (/blog/google-ads-custom-conversion-setup)
[2/8] Screenshot of '/blog/!index' taken and saved to '.lostpixel/current/blog/!index.png' in 2.250s (/blog/!index)
[6/8] Taking screenshot of '/blog/ignore-internal-traffic-in-google-analytics ' (/blog/ignore-internal-traffic-in-google-analytics)
[3/8] Screenshot of '/blog/socials-calendar' taken and saved to '.lostpixel/current/blog/socials-calendar.png' in 2.254s (/blog/socials-calendar)
[7/8] Taking screenshot of '/blog/visual-testing-percy-gha-slack ' (/blog/visual-testing-percy-gha-slack)
[4/8] Screenshot of '/blog/typescript-excess-property-checks' taken and saved to '.lostpixel/current/blog/typescript-excess-property-checks.png' in 2.585s (/blog/typescript-excess-property-checks)
[8/8] Taking screenshot of '/blog/meta-pixel-traps-in-app-browsers ' (/blog/meta-pixel-traps-in-app-browsers)
[1/8] Screenshot of '/!index' taken and saved to '.lostpixel/current/!index.png' in 2.881s (/!index)
[5/8] Screenshot of '/blog/google-ads-custom-conversion-setup' taken and saved to '.lostpixel/current/blog/google-ads-custom-conversion-setup.png' in 2.884s (/blog/google-ads-custom-conversion-setup)
[7/8] Screenshot of '/blog/visual-testing-percy-gha-slack' taken and saved to '.lostpixel/current/blog/visual-testing-percy-gha-slack.png' in 3.012s (/blog/visual-testing-percy-gha-slack)
[6/8] Screenshot of '/blog/ignore-internal-traffic-in-google-analytics' taken and saved to '.lostpixel/current/blog/ignore-internal-traffic-in-google-analytics.png' in 3.020s (/blog/ignore-internal-traffic-in-google-analytics)
[8/8] Screenshot of '/blog/meta-pixel-traps-in-app-browsers' taken and saved to '.lostpixel/current/blog/meta-pixel-traps-in-app-browsers.png' in 3.336s (/blog/meta-pixel-traps-in-app-browsers)
Screenshots done!
Creating shots took 6.138 seconds
🔍 Checking differences
Comparing 8 screenshots using 'pixelmatch' as compare engine
[1/8] Comparing '/!index' (/!index)
[2/8] Comparing '/blog/!index' (/blog/!index)
[3/8] Comparing '/blog/socials-calendar' (/blog/socials-calendar)
[4/8] Comparing '/blog/typescript-excess-property-checks' (/blog/typescript-excess-property-checks)
[5/8] Comparing '/blog/google-ads-custom-conversion-setup' (/blog/google-ads-custom-conversion-setup)
[6/8] Comparing '/blog/ignore-internal-traffic-in-google-analytics' (/blog/ignore-internal-traffic-in-google-analytics)
[7/8] Comparing '/blog/visual-testing-percy-gha-slack' (/blog/visual-testing-percy-gha-slack)
[8/8] Comparing '/blog/meta-pixel-traps-in-app-browsers' (/blog/meta-pixel-traps-in-app-browsers)
[1/8] Difference of 126891 pixels (3.99%) found. Difference image saved to: .lostpixel/difference/!index.png (/!index)
❌ ENOENT: no such file or directory, open '.lostpixel/difference/blog/!index.png'

Just to clarify on the above message - ENOENT: no such file or directory, open means lost-pixel did not make the screenshot of this page, means lost-pixel could not open this page properly in playwright. So first things first we need to make sure that the page you are trying to open exists & you can open it in the browser.

Just to clarify on the above message - ENOENT: no such file or directory, open means lost-pixel did not make the screenshot of this page, means lost-pixel could not open this page properly in playwright. So first things first we need to make sure that the page you are trying to open exists & you can open it in the browser.
if you can repro this locally - awesome, please verify that /!index page is accessible by the browser 🙌

Hmm, interesting, but I don't see errors regarding screenshot taking... And on local I do see the screenshot in current folder. It's the difference folder that is missing a file. I would assume it's some sort of a race

that is interesting indeed! is it always this !index page or?
Is there anything special about the page?
can you run successfully locally at least once, or it fails everytime now?

On local it is the same blog/!index page and I can't get it working at all now, fails every time
On GHA it was another page - ❌ ENOENT: no such file or directory, open '.lostpixel/difference/blog/meta-pixel-traps-in-app-browsers.png'
Nothing special about the pages I think... They all are here: https://maxim.mazurok.com/
I might try remove ! from the name

Looks like it's related to / in the names.
I did this and it works fine now:
import { CustomProjectConfig } from 'lost-pixel';
import { getUrlsFromSitemap } from './src/helpers';
import { readFileSync } from 'fs';

export const config: CustomProjectConfig = {
  pageShots: {
    pages: getUrlsFromSitemap(readFileSync('./sitemap.xml', 'utf-8')).map(
      x => ({
        path: x.pathname,
        name: (x.pathname.endsWith('/') ? `${x.pathname}index` : x.pathname)
          .replace(/\//g, '_')
          .replace(/^_/g, ''),
      })
    ),
    baseUrl: 'http://172.17.0.1:8080', // this has to be internal IP of the docker container inside of Github Actions
  },
  generateOnly: true,
  failOnDifference: true,
};

hmm, great catch! wanna give a proper fix a spin? :D I think you are already pretty much caught the exact problem so fix might not be that complicated 🤔

Well, the exact problem is that lost-pixel doesn't work great with folders... So we could either a - replace all / in names with _ or something. Or b - make lost-pixel work well with folders.
I think option b is the best, but I don't have bandwidth for now. I am just annoyed that percy is giving me 1px diff every day, so trying out lost-pixel, if it works well for me I might consider adding folders support, but tbh probably not anytime soon as I don't have many pages for now. Anyway, hope this helps, cheers!

yup, some legit good thoughts, thanks Maxim! we are happy to help you with your migration from Percy anytime both for personal & work projects 😉 we have bunch of people migrating & the fact that you could choose individual thresholds on per page level is usually helping a ton already with those 1-2px flakiness

authors: Maxim-Mazurok d-ivashchuk

repo: lost-pixel/lost-pixel


text:
Commit/push on workspace close

I understand the intervals (auto-commit every 30 secs), but I wish there were a checkbox to say, "If I close the workspace, and it's dirty, auto-commit and auto-push for me."
This is in the event that I make changes and close the workspace before it hits the next interval.

This has now been addressed. By default, changes will be automatically committed when you close VS Code, but this can be disabled by setting the GitDoc: Commit on Close setting to false. Thanks!

authors: jsjoeio lostintangent

repo: lostintangent/gitdoc