Bot won't start and chat becomes unresponsive

Okay so I'm having this weird issue with only one bot. I'm sure if I restart ASF it will work as expected, but maybe this can help fix some potential bug. Ok, so all my bots started normally (even the one that I'm having issues with), and all of them are redeeming keys too, except one bot, which is returning Timeout:
[8:02:57 PM] master: !redeem buggy_bot XXXXX-XXXXX-XXXXX
<slave_1> Key: XXXXX-XXXXX-XXXXX| Status: Timeout!

The ASF output looks like this:
2016-07-30 20:02:59.9729|ERROR|ArchiSteamFarm.Logging|buggy_bot|RedeemKey()
I've had this issue a couple of times and generally I just have to restart the bot to make it work again. But this time, I tried to !stop it and I got no response (I spammed some commands three times and I still didn't got any response):
[8:03:07 PM] master: !stop buggy_bot
[8:03:11 PM] master: !start buggy_bot
[8:04:05 PM] master: !stop buggy_bot

The ASF output after the first !stop:
2016-07-30 20:03:11.1083|INFO|ArchiSteamFarm.Logging|buggy_bot|Stop() Stopping...

Since bot slave_1's chat window became unresponsive, I tried to issue the commands to slave_2, but doing that, made slave_2 freeze too:
[8:06:29 PM] master: !statusall
[8:06:31 PM] slave_2:
<a reaaaally long response that isn't important>
[8:06:54 PM] master: !stop buggy_bot
[8:06:56 PM] slave_2: That bot instance is already inactive!
[8:06:59 PM] master: !start buggy_bot
[8:07:25 PM] master: !statusall

ASF didn't show any relevant information to above commands. I'm using the latest stable version: V<IP_ADDRESS>

Okay, so I scrolled up my ASF's log window and I saw this (I have ASF running for about 1 day, btw):
<...>
2016-07-30 12:59:04.7139|ERROR|ArchiSteamFarm.Logging|buggy_bot|Init()
2016-07-30 12:59:04.7139|INFO|ArchiSteamFarm.Logging|buggy_bot|Start() Starting...
<...>

And after that I didn't receive any information about that bot (about ~8 hours ago).

Can you show me all log lines of this bot instance instead of just selected few?
Use something like grep or even Notepad++ for showing only lines containing |buggy_bot|.

Yup. Here you go:
http://pastebin.com/raw/H5LWHj5G

Did you modify logging layouts? Those errors should have message with them, ASF prohibits logging of null or empty messages.

Shit, I honestly don't know. I mean I have a NLog.config that I probably got from the Wiki page (I didn't know and thought it was mandatory to have this file :S). Anyway here it is:
<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <targets>
        <target xsi:type="ColoredConsole" name="ColoredConsole" />
        <target xsi:type="File" name="File" fileName="NLog.txt" deleteOldFileOnStartup="true" />
    </targets>
    <rules>
        <logger name="*" minlevel="Trace" writeTo="ColoredConsole" />
        <logger name="*" minlevel="Trace" writeTo="File" />
    </rules>
</nlog>

Remove NLog.config if you use default settings, there is no need to override them if you don't have a reason.
Judging from the fact that it was in ArchiWebHandler, most likely it was some kind of networking problem - steam didn't announce end of connection, so SteamClient probably is trying to end it gracefully while not receiving any response.
This would make sense as SteamClient.Connect() should always disconnect the old session and initiate a connect, instead, it's stuck in your case, and SK2 still reports that SteamClient.IsConnected.
I'm not sure if there is anything that ASF can do in this case, it should be handled in SK2 library, preferably implementing a timeout and force reconnect instead of something like this. I've already experienced this problem - it's very rare, but it looks like SteamClient simply freezes and it's not possible to make it reconnect even with SteamClient.Connect() - that's why your keys redeeming requests are failing, because ASF properly tries to send the request, but Steam network never responds back, as SteamClient is frozen. It became frozen the moment it tried to log in to ISteamUserAuth the last time (and failed) - that initiated a reconnect request that was never fullified.
It's probably best to ask SK2 devs if they have any clue why SteamClient can reach such state of being unable to operate, and if perhaps it's possible to do anything to overcome this problem apart from throwing away old object and creating new SteamClient(). Maybe @Netshroud could say something about that.

Oh, good to know. So the bots not answering the commands can't be handled by ASF? Like a 1 minute timeout to "abort" if SK2 don't respond or something... Anyway, like you said it's indeed very rare (in fact it happened a veeery few times before). I'll just restart ASF then. Thanks for your attention!

If SteamClient is frozen then no request can reach ASF, even if you do make it reach ASF, through other bot instance (like you did), then redeem request will timeout anyway as SteamClient is non-operative. Thing is, during normal and even faulty operation SteamClient should NEVER reach such state, as SteamClient.Connect() should always force a reconnect.
This is somehow problematic as the workaround for this issue would require throwing away currently coded nice way of SteamClient.Disconnect() and SteamClient.Connect() and instead initialize new object on each reconnect attempt. I don't want to do this as this doesn't make any sense - SteamClient should be reusable and there should be never a need to throw it away, unless we're done with it for good.
So for now I don't have any real workaround for this, I might need to look into SK2 code and check how the whole connection is being handled to spot the deadlock/issue we're seeing, but hopefully @Netshroud or other dev from @SteamRE/SteamKit2 can at least confirm if my assumptions are right.
Because this is the only possible reason why SteamClient.Connect() freezes and doesn't return any callback - neither OnConnected() nor OnDisconnected().

Can you map those line logs to SteamKit2 / callbacks / function calls? I'm not going to read through all of ASF to find all log output lines.
Also, are you using TCP or UDP?

Not sure if you are asking me, but I can only answer the second question: TCP.

Sorry Netshroud, I'm mapping it for you right now.
It's TCP - the current web session expired, so ASF called ISteamUserAuth dynamically here with proper nonce. That request failed here so ASF initiated SteamClient reconnect here.
We reached Starting... in the log, so ASF's last call was SteamClient.Connect() here - after that no callback arrived - neither OnConnected() nor OnDisconnected().
That's what I can read from the log posted by @GUiHKX, but that already happened to me in ArchiBoT IIRC - it's basically SteamClient becoming frozen, any request results in timeout.
This issue is very rare, so I suspect it's specific TcpClient issue or something like this, but I didn't look carefully in SK2 code yet so this is only my guess for now.
Let me know if you need any more info.

BTW, @GUiHKX can you double-check there is no exception thrown around 2016-07-30 12:58:04.6885? I have unhandled exception and unobserved exception handler, so if there is anything weird in SK2 code or anywhere else we should take a look at this.

I checked both ASF console and NLog.txt file and unfortunately nothing showed up...

This can be true as I didn't spot any exception back when I had this issue for the first time in ArchiBoT as well, thanks for checking.

Update: It seems that this can be also triggered with going into Windows hibernate mode. @Netshroud

So you have debuglog output from it?

No repro on the hiberation.
I connected to Steam then hibernated for 12 minutes. After resuming, SteamKit's TcpConnection got an IOException, cleanly disconnected and the loop I inserted into Sample1 to reconnect after disconnecting got hit and called steamClient.Connect(), which resulted in a successful reconnection.
This was even without Azuisleet's latest change around calling WaitOne.

I'll notify you once we have something to work with.
Notice for everybody facing this issue: enable ASF Debug mode in order to record debug log from the freeze. Once recorded, pack whole debug directory together with log.txt to zip and send it on my e-mail: JustArchi[at]JustArchi[dot]net, as it can contain sensitive information.

Also it's interesting because when SteamClient goes into such freeze state, all async jobs are failing instantly:
2016-08-06 16:37:58|INFO|MrMousePT|RefreshSessionIfNeeded() Refreshing our session!
2016-08-06 16:37:59|ERROR|MrMousePT|RefreshSession() SteamKit2.AsyncJobFailedException

The above is happening with await SteamUser.RequestWebAPIUserNonce();.

I noticed something very similar to this issue, but with new HeartBeat I added recently it seems to at least cause SteamClient to be "unstuck":
2016-08-23 05:51:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 05:51:41|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 05:51:41|INFO|archi|StopFarming() Sending signal to stop farming
2016-08-23 05:51:41|INFO|archi|StopFarming() Waiting for reaction...
2016-08-23 05:51:41|INFO|archi|Farm() Stopped farming: 463150 (BARRIER X)
2016-08-23 05:51:42|INFO|archi|StopFarming() Farming stopped!
2016-08-23 05:51:53|INFO|archi|OnConnected() Connected to Steam!
2016-08-23 05:51:53|INFO|archi|OnConnected() Logging in...
2016-08-23 05:52:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 05:53:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 05:54:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 05:55:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 05:56:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 05:57:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 05:58:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 05:59:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 06:00:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 06:01:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 06:02:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 06:03:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 06:04:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 06:05:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 06:06:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 06:07:41|WARN|archi|HeartBeat() Connection to Steam Network lost, reconnecting...
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnDisconnected() Disconnected from Steam!
2016-08-23 06:08:19|INFO|archi|OnConnected() Connected to Steam!
2016-08-23 06:08:19|INFO|archi|OnConnected() Logging in...
2016-08-23 06:08:19|INFO|archi|OnLoggedOn() Successfully logged on!
2016-08-23 06:08:19|INFO|archi|Init() Logging in to ISteamUserAuth...
2016-08-23 06:08:21|INFO|archi|Init() Success!

SteamClient "died" for more than 15 minutes, and all scheduled requests including their callbacks got frozen for that period - it's clearly visible with HeartBeat() trying to SteamClient.Connect() every minute to finally wake it up.
Really strange :confused:

Interesting that you had 16 failed heartbeat attempts, then 16 disconnected callbacks all at the same time.
Are you sure you're calling the CallbackManager appropriately?

Feel free to check - I didn't spot any issue related to this function, recently I even added extra check that makes sure to run this function while SteamClient.IsConnected. KeepRunning is set to false after starting only in Stop() function, but that one requires somebody to call !stop and results in appropriate Stopping... result in a log, so I'm sure that my callback loop was working properly.

BTW, I'm very grateful you're trying to help us Netshroud, I appreciate that. I'm also doing my own research regarding that, including running my bots with DebugLog so I can potentially check if there is something weird going on.
My main suspect for now is TCP socket that somehow "blocks" for given timeout during network issues or malfunctions, preventing CMClient from communication. That is however only wild guess based on logs and situations, I hope to reproduce it with debug log and proper log.

Finally after nearly a week of hunting I think I managed to reproduce this issue, and while socket timeout after ~15 minutes is another one, this issue is mostly caused by very rare situation of concurrent calls to SteamClient's Connect() and Disconnect(), which should be fixed in https://github.com/SteamRE/SteamKit/commit/330fe9bea8b80b3cf484ba09611b2e53948eefb3.
I wrapped ASF calls in lock() statements for now before fix above lands in SK2 code, and I consider this issue as fixed until somebody will be able to reproduce this on ASF V<IP_ADDRESS>+ (which will be released soon). I'm still actively watching this to ensure that the fix indeed works, but due to nature of the bug such thing can be stated semi-reliably only after longer period of tests.
Thanks to all who spent their time on trying to help and find the culprit, especially to @Netshroud for offering his helpful hand despite of not being directly connected with ASF project :smiley:
I consider this issue closed until somebody (including me) will be able to reproduce it once again in ASF V<IP_ADDRESS>+.


Added Weather App

I have tried to develop this app so that more features could be added to it in future. I have also created the README file in a way in which beginners can relate to the app development process in a realistic manner. Please let me know if there could be any improvements

@shivamag00 great work, please take sometime out to write an article for this medium.

@dubesar Sure...I will write an article on medium for  this project. Meanwhile, please add the label hacktoberfest-accepted to this PR


Coredump when calling grpc::ServerContext::~ServerContext

What version of gRPC and what language are you using?
GRPC-1.0.0/ C++
What operating system (Linux, Windows, …) and version?
Ubuntu 4.8.4-2ubuntu1~14.04.3
What runtime / compiler are you using (e.g. python version or version of gcc)
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
What did you do?
I kept sending messages through an async bi-directional stream to a server. After a minute I will destruct the server class and exit the server.
The exit order in server side I use:

grpc::Server::Shutdown
cq->Shutdown
destruct ServerContext and its related Stream.
destruct Service
Am I wrong?

What did you expect to see?
The server side exits safely without crashing.
What did you see instead?
The server crashed when destructing the ServerContext.
core stack:
Thread 1 (Thread 0x7f220f760700 (LWP 25678)):
#0  0x00007f220f797c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f220f79b028 in __GI_abort () at abort.c:89
#2  0x0000000000545f3d in gpr_mu_lock ()
#3  0x0000000000541a97 in grpc_mdstr_unref ()
#4  0x00000000005380b9 in ?? ()
#5  0x000000000054bf17 in grpc_exec_ctx_flush ()
#6  0x000000000053a72f in grpc_call_destroy ()
#7  0x00000000005363b7 in grpc::ServerContext::~ServerContext() ()

I0714 16:14:01.839092 25707 cq_mgr.xxx] Server CompletionQueue (0xf6b030) is quiting.
D0714 16:14:01.840290526   25677 metadata.c:238]             WARNING: 2 metadata elements were leaked                                                                                D0714 16:14:01.840330045   25677 metadata.c:238]             WARNING: 1 metadata elements were leaked
D0714 16:14:01.840347491   25677 metadata.c:251]             WARNING: 1 metadata strings were leaked                                                                                D0714 16:14:01.840357418   25677 metadata.c:255]             LEAKED: <IP_ADDRESS>:19998
D0714 16:14:01.840367198   25677 metadata.c:251]             WARNING: 1 metadata strings were leaked                                                                                D0714 16:14:01.840401554   25677 metadata.c:255]             LEAKED: Cancelled on the server side
D0714 16:14:01.840412870   25677 metadata.c:251]             WARNING: 1 metadata strings were leaked                                                                                D0714 16:14:01.840421944   25677 metadata.c:255]             LEAKED: /xx.Service/xxx
D0714 16:14:01.840431340   25677 metadata.c:251]             WARNING: 1 metadata strings were leaked                                                                                D0714 16:14:01.840440064   25677 metadata.c:255]             LEAKED: /xxx.Service/xxx
D0714 16:14:01.840449180   25677 metadata.c:251]             WARNING: 2 metadata strings were leaked                                                                                D0714 16:14:01.840457679   25677 metadata.c:255]             LEAKED: /xxx.Service/xxx
D0714 16:14:01.840466259   25677 metadata.c:255]             LEAKED: /xxx.Service/xxx                                                                                D0714 16:14:01.840476286   25677 metadata.c:251]             WARNING: 1 metadata strings were leaked
D0714 16:14:01.840485106   25677 metadata.c:255]             LEAKED: /xxx.Service/xxx
D0714 16:14:01.840494269   25677 metadata.c:251]             WARNING: 1 metadata strings were leaked
D0714 16:14:01.840502673   25677 metadata.c:255]             LEAKED: /xxx.DictService/xxx                                                                                D0714 16:14:01.840511522   25677 metadata.c:251]             WARNING: 1 metadata strings were leaked
D0714 16:14:01.840520015   25677 metadata.c:255]             LEAKED: /xxx.Service/xxx                                                                                D0714 16:14:01.840529058   25677 metadata.c:251]             WARNING: 2 metadata strings were leaked
D0714 16:14:01.840546748   25677 metadata.c:255]             LEAKED: grpc-c++/1.0.0 grpc-c/1.0.0 (linux; chttp2)                                                                                D0714 16:14:01.840555922   25677 metadata.c:255]             LEAKED: /xxx.Service/List
W0714 16:14:01.939550 25678 zookeeper_context.cpp:1009] Disconnect from ZooKeeper now                                                                                I0714 16:14:01.939929 25678 zookeeper_watcher.cpp:329]   --> Number of watchers notified: 1
I0714 16:14:01.939936 25678 zookeeper_watcher.cpp:330]   --> Callback time used(us): 17                                                                                W0714 16:14:01.939949 25678 zookeeper_context.cpp:187] ZookeeperContext destructed, this: 0x7f2208001710
I0714 16:14:01.939959 25678 brain_daemon.cpp:545] BrainDaemon session watcher destruction.                                                                                I0714 16:14:01.939970 25678 dict_service.cpp:42] DICT DictService stopped.
E0714 16:14:01.940076878   25678 sync_posix.c:51]            **assertion failed: pthread_mutex_lock(mu) == 0**

Anything else we should know about your project / environment?
No

I found it will not crash after I destructed ServerAsyncReaderWriter before destructing ServerContext.
I'm not sure if this is the root cause. Could anyone help to conclude?

Could you try with a more recent version of grpc?

Already update to 1.4.2 and this problem vanishes.


Place Personas onto Affinity Map

[x] Place the personas on the affinity map so that the axis correlate to different ends of each perspective

Affinity Map with Personas placed on the map:

@Fatiha897

Update affinity map with new persona:


Table widget panics when table doesnt fit screen

Describe the bug
The table widget is panicking when it doesn't for the screen
Here is the stack trace thrown at https://github.com/kdash-rs/kdash/blob/main/src/ui/overview.rs#L262
thread '<unnamed>' panicked at 'Trying to access position outside the buffer: x=189, y=16, area=Rect { x: 0, y: 0, width: 189, height: 40 }', /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/buffer.rs:217:9
   0: kdash::panic_hook
             at src/main.rs:57:46
   1: kdash::main::{{closure}}::{{closure}}
             at src/main.rs:76:5
   2: std::panicking::rust_panic_with_hook
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:581:17
   3: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:484:9
   4: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:153:18
   5: rust_begin_unwind
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483:5
   6: std::panicking::begin_panic_fmt
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:437:5
   7: tui::buffer::Buffer::index_of
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/buffer.rs:217:9
   8: tui::buffer::Buffer::get_mut
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/buffer.rs:184:17
   9: tui::buffer::Buffer::set_style
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/buffer.rs:358:17
  10: tui::widgets::table::render_cell
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/widgets/table.rs:513:5
  11: <tui::widgets::table::Table as tui::widgets::StatefulWidget>::render
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/widgets/table.rs:440:17
  12: tui::terminal::Frame<B>::render_stateful_widget
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/terminal.rs:137:9
  13: kdash::ui::overview::draw_nodes
             at src/ui/overview.rs:304:5
  14: kdash::ui::overview::draw_active_context_tabs
             at src/ui/overview.rs:116:10
  15: kdash::ui::overview::draw_overview
             at src/ui/overview.rs:22:5
  16: kdash::ui::draw
             at src/ui/mod.rs:49:7
  17: kdash::start_ui::{{closure}}::{{closure}}
             at src/main.rs:179:23
  18: tui::terminal::Terminal<B>::draw
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/terminal.rs:259:9
  19: kdash::start_ui::{{closure}}
             at src/main.rs:179:5
  20: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/future/mod.rs:80:19
  21: kdash::main::{{closure}}
             at src/main.rs:122:3
  22: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/future/mod.rs:80:19
  23: tokio::park::thread::CachedParkThread::block_on::{{closure}}
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/park/thread.rs:263:54
  24: tokio::coop::with_budget::{{closure}}
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/coop.rs:106:9
  25: std::thread::local::LocalKey<T>::try_with
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:272:16
  26: std::thread::local::LocalKey<T>::with
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:248:9
  27: tokio::coop::with_budget
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/coop.rs:99:5
      tokio::coop::budget
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/coop.rs:76:5
      tokio::park::thread::CachedParkThread::block_on
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/park/thread.rs:263:31
  28: tokio::runtime::enter::Enter::block_on
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/runtime/enter.rs:151:13
  29: tokio::runtime::thread_pool::ThreadPool::block_on
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/runtime/thread_pool/mod.rs:71:9
  30: tokio::runtime::Runtime::block_on
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/runtime/mod.rs:452:43
  31: kdash::main
             at src/main.rs:73:1
  32: core::ops::function::FnOnce::call_once
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
  33: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:137:18
  34: std::rt::lang_start::{{closure}}
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:66:18
  35: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ops/function.rs:259:13
      std::panicking::try::do_call
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:381:40
      std::panicking::try
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:345:19
      std::panic::catch_unwind
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panic.rs:382:14
      std::rt::lang_start_internal
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:51:25
  36: std::rt::lang_start
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:65:5
  37: main
  38: __libc_start_main
  39: _start
────────────────

To Reproduce
I couldnt reproduce this on a standalone setup as it seems to work fine with same data as in error case. Below are the table rows when error happened
vec![
                    "gke-hello-hipster-default-pool-cddd8f85-0t5r",
                    "Ready",
                    "<none>",
                    "v1.18.16-gke.2100",
                    "7",
                    "950m",
                    "2828",
                    "15%",
                    "20%",
                    "6d23h",
                ],
                vec![
                    "gke-hello-hipster-default-pool-cddd8f85-9gzv",
                    "Ready",
                    "<none>",
                    "v1.18.16-gke.2100",
                    "7",
                    "900m",
                    "2820",
                    "20%",
                    "20%",
                    "6d23h",
                ],

So i'm unable to pinpoint whats going wrong here
Expected behavior
Should not panick regardless of screen size
Desktop (please complete the following information):

OS: Fedora 32. Kernel 5.11.10-100.fc32.x86_64
Terminal Emulatoron Yakuake, Tilix, Konsole and VSCode terminal
Font [Monospace]
Crate version [0.14]
Backend [crossterm]

I had something similar happen to me that seems to have been due to moving the Layout out of the loop. I have this:
        let v = Layout::default() // v for vertical
        .direction(Direction::Vertical)
        .margin(1)
        .constraints(
            [
                Constraint::Min(3),
                Constraint::Percentage(30),
                Constraint::Percentage(70),
            ]
            .as_ref(),
        )
        .split(terminal.size().unwrap());        let v = Layout::default() // v for vertical
        .direction(Direction::Vertical)
        .margin(1)
        .constraints(
            [
                Constraint::Min(3),
                Constraint::Percentage(30),
                Constraint::Percentage(70),
            ]
            .as_ref(),
        )
        .split(terminal.size().unwrap());

Then there's a loop and the terminal displays with all of the widgets. Later on I ended up moving this out of the loop (thinking that it made sense because I use this layout each time) and that's when it started panicking by saying that the index is (some number+1) while the length is (some number).
Not sure if that helps you but seems similar enough to mention. Here's what the stack trace looked like:
 thread 'main' panicked at 'index out of bounds: the len is 918 but the index is 919', C:\Users\mithr\.cargo\registry\src\github.com-1ecc6299db9ec823\tui-0.14.0\src\buffer.rs:185:14
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0\/library\std\src\panicking.rs:493
   1: core::panicking::panic_fmt
             at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0\/library\core\src\panicking.rs:92
   2: core::panicking::panic_bounds_check
             at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0\/library\core\src\panicking.rs:69
   3: tui::buffer::Buffer::set_style
   4: <tui::widgets::block::Block as tui::widgets::Widget>::render
   5: tui::terminal::Terminal<B>::draw
   6: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
   7: ZN4core3ptr622drop_in_place$LT$core..iter..adapters..map..map_fold$LT$$RF$tui..layout..Constraint$C$tui..layout..Rect$C$$LP$$RP$$C$tui..layout..split..$u7b$$u7b$closure$u7d$$u7d$$C$core..iter..traits..iterator..Iterator..for_each..call$LT$tui..layout..Rec
   8: std::rt::lang_start::{{closure}}
   9: core::ops::function::impls::{{impl}}::call_once
             at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0\library\core\src\ops\function.rs:280
  10: std::panicking::try::do_call
             at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0\/library\std\src\panicking.rs:379
  11: std::panicking::try
             at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0\/library\std\src\panicking.rs:343
  12: std::panic::catch_unwind
             at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0\/library\std\src\panic.rs:431
  13: std::rt::lang_start_internal
             at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0\/library\std\src\rt.rs:51
  14: main
  15: invoke_main
             at D:\agent\_work\9\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  16: __scrt_common_main_seh
             at D:\agent\_work\9\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  17: BaseThreadInitThunk
  18: RtlUserThreadStart

Hi @Dhghomon thanks for the info, just a quick question, when you mean you moved the layout out of the loop, what does it mean? I also have common util functions that builds the layout but in the end they are still called inside the UI loop for rendering.
The issue keeps happening for me when the table is bigger than window and during resize. Aso your error seems to index out of bounds where as for me its Trying to access position outside the buffer so I think the reason could be different as well.
The weird thing is this does not happen on VSCode terminal often and in Yakuake it happens more often and in Tilix it happens all the time. So may be this is dependent on the emulator as well
The error always comes from this function in tui-rs (src/buffer.rs:217:9) so possibly the size update calculation hapens slower due to some race condition
    pub fn index_of(&self, x: u16, y: u16) -> usize {
        debug_assert!(
            x >= self.area.left()src/buffer.rs:217:9
                && x < self.area.right()
                && y >= self.area.top()
                && y < self.area.bottom(),
            "Trying to access position outside the buffer: x={}, y={}, area={:?}",
            x,
            y,
            self.area
        );
        ((y - self.area.y) * self.area.width + (x - self.area.x)) as usize
    }

Ah, probably a different issue then. What I meant by moving out of the loop is that I have a loop where all the Widgets are created on the fly and used as instant commands (as tui says to do) and one day I got the idea that it might be more efficient to keep the Layout outside of the loop (since it doesn't change) and then only call render_widget on each of the parts of the layout inside of the loop, and that's when the problems began.
The code's a bit different now but you can see it here:
https://github.com/Dhghomon/dictionariums/blob/main/src/main.rs
The part that I moved to the top out of the loop is this one:
    let v = Layout::default() // v for vertical
        .direction(Direction::Vertical)
        .margin(1)
        .constraints(
            [
                Constraint::Min(3),
                Constraint::Percentage(30),
                Constraint::Percentage(70),
            ]
            .as_ref(),
        )
        .split(terminal.size().unwrap());

Ah ok. Hmmm, I think that indeed could be problematic as I assume that some layout related stuff needs to be calculated on the fly especially the area on loop to accomodate for resize etc. But its just a guess. My issue is quite different indeed.

I'm willing to try and fix this but I would need some guidance as i'm very new to TUI

@deepu105 Hey 👋 . This looks like an off by one error in the computation of the widths of the table columns. More than the data passed to the widget, I would be interested by the values of all parameters passed to the Table builder methods such as column_spacing, widths, highlight_symbol and the area StatefulWidget::render is called with.

Hi this is one of the table https://github.com/kdash-rs/kdash/blob/main/src/ui/overview.rs#L265 let me know if this helps. Else I can try to create a standalone sample

Ok I was finally able to reproduce it with a standalone sample. If you resize the terminal fast enough, this breaks
#[allow(dead_code)]
mod util;

use crate::util::event::{Event, Events};
use std::{error::Error, io};
use termion::{event::Key, input::MouseTerminal, raw::IntoRawMode, screen::AlternateScreen};
use tui::{
    backend::TermionBackend,
    layout::{Constraint, Layout, Direction},
    style::{Color, Modifier, Style},
    widgets::{Block, Borders, Cell, Row, Table, TableState},
    Terminal,
};

pub struct StatefulTable<'a> {
    state: TableState,
    items: Vec<Vec<&'a str>>,
}

impl<'a> StatefulTable<'a> {
    fn new() -> StatefulTable<'a> {
        StatefulTable {
            state: TableState::default(),
            items: vec![
                vec![
                    "gke-hello-hipster-default-pool-cddd8f85-0t5r",
                    "Ready",
                    "<none>",
                    "v1.18.16-gke.2100",
                    "7",
                    "950m",
                    "2828",
                    "15%",
                    "20%",
                    "6d23h",
                ],
                vec![
                    "gke-hello-hipster-default-pool-cddd8f85-9gzv",
                    "Ready",
                    "<none>",
                    "v1.18.16-gke.2100",
                    "7",
                    "900m",
                    "2820",
                    "20%",
                    "20%",
                    "6d23h",
                ],
                vec![
                    "gke-hello-hipster-default-pool-cddd8f85-9gzv",
                    "Ready",
                    "<none>",
                    "v1.18.16-gke.2100",
                    "7",
                    "900m",
                    "2820",
                    "20%",
                    "20%",
                    "6d23h",
                ],
            ],
        }
    }
    pub fn next(&mut self) {
        let i = match self.state.selected() {
            Some(i) => {
                if i >= self.items.len() - 1 {
                    0
                } else {
                    i + 1
                }
            }
            None => 0,
        };
        self.state.select(Some(i));
    }

    pub fn previous(&mut self) {
        let i = match self.state.selected() {
            Some(i) => {
                if i == 0 {
                    self.items.len() - 1
                } else {
                    i - 1
                }
            }
            None => 0,
        };
        self.state.select(Some(i));
    }
}

fn main() -> Result<(), Box<dyn Error>> {
    // Terminal initialization
    let stdout = io::stdout().into_raw_mode()?;
    let stdout = MouseTerminal::from(stdout);
    let stdout = AlternateScreen::from(stdout);
    let backend = TermionBackend::new(stdout);
    let mut terminal = Terminal::new(backend)?;

    let events = Events::new();

    let mut table = StatefulTable::new();

    // Input
    loop {
        terminal.draw(|f| {
            let chunks = Layout::default()
            .constraints(vec![Constraint::Length(2), Constraint::Min(0)])
            .direction(Direction::Vertical)
            .margin(1)
            .split(f.size());

            let block = Block::default().borders(Borders::TOP).title("Table Title test");
            let rows = table.items.iter().map(|item| {
                let style = Style::default().fg(Color::Green);

                let cells: Vec<Cell> = item.iter().map(|c| Cell::from(*c)).collect();
                Row::new(cells).style(style)
            });

            let header = Row::new(vec![
                "Name", "Status", "Roles", "Version", "Pods", "CPU", "Mem", "CPU %", "Mem %", "Age",
            ])
                .style(Style::default().fg(Color::Green))
                .bottom_margin(0);

            let t = Table::new(rows)
                .header(header)
                .block(block)
                .highlight_style(Style::default().add_modifier(Modifier::REVERSED))
                .highlight_symbol("=>")
                .widths(&[
                    Constraint::Percentage(30),
                    Constraint::Percentage(10),
                    Constraint::Percentage(15),
                    Constraint::Percentage(10),
                    Constraint::Percentage(5),
                    Constraint::Percentage(5),
                    Constraint::Percentage(5),
                    Constraint::Percentage(5),
                    Constraint::Percentage(5),
                    Constraint::Percentage(10),
                ]);

            f.render_stateful_widget(t, chunks[1], &mut table.state);
        })?;

        if let Event::Input(key) = events.next()? {
            match key {
                Key::Char('q') => {
                    break;
                }
                Key::Down => {
                    table.next();
                }
                Key::Up => {
                    table.previous();
                }
                _ => {}
            }
        };
    }

    Ok(())
}

Hello all. I've been getting a similar crash:
thread 'main' panicked at 'Trying to access position outside the buffer: x=98, y=11, area=Rect { x: 0, y: 0, width: 98, height: 26 }
Here's the table:
  let selected_style = Style::default().bg(Color::Blue).fg(Color::Black);
  let t = Table::new(rows)
      .header(header)
      .block(
          Block::default()
              .borders(Borders::ALL)
              .border_type(BorderType::Rounded)
              .title("scoreboard"),
      )
      .highlight_style(selected_style)
      .highlight_symbol(">> ")
      .widths(&[
          Constraint::Percentage(15),
          Constraint::Percentage(15),
          Constraint::Percentage(25),
          Constraint::Percentage(45),
      ]);

Things I've tried:

removing the trailing space in the highlight_symbol: ">>". This fixed it when the terminal was at 98 width, but crashed again when at 97.
removing the border from the block, or just deleting it entirely. Again, fixed at 98 but crashed at 97.
terminal height seems to have no effect
subtracting 1 from the last width Constraint to Constraint::Percentage(44). This seems to fix it in all terminal sizes I've tried so far.

Not sure why the Constraint seemed to do it. Happy to help further if needed!

^ Oops, sorry, didn't realize that would link back to this issue 🤦

Seems like the workaround doesnt help always. I did that for every table and it still crashes at times

@andschneider for your workaround does it matter if I subtract 1 from last or any column?

@andschneider for your workaround does it matter if I subtract 1 from last or any column?

I only tried with the last column. I thought it would work with any of them though.

This is becoming quite an annoying issue as more and more people are opening crash reports in KDash due to this. I would be happy to try and fix this, but I have no idea where to start. @fdehau if you can point me in the right direction may be I can give it a shot

Hey @deepu105, I started digging around last week and think I can fix it (at least with a small hack).
Can you post the tables that are causing a crash so I can test them? Mostly need the widths, highlight symbol, block, and column spacing.

I was able to reproduce it with this sample, but not always, only if I resize fast enough
https://github.com/fdehau/tui-rs/issues/470#issuecomment-831171722

@deepu105 I added that one as a test case, it was happening at 189 width as can be seen in the stack trace from your first comment. Part of the trouble with this is seems to happen at various widths...
Do you know if that's the same table your users are reporting a crash on as well? Would love to get more tests cases if possible.
In the meantime, I opened a PR with my fix. Feel free to try it and see if it helps!

Actually it happens on almost all tables when the data is as long as the
column and resize happens
On Wed, 21 Jul 2021, 8:36 pm Andrew Schneider, @.***>
wrote:

@deepu105 https://github.com/deepu105 I added that one as a test case,
it was happening at 189 width as can be seen in the stack trace from your
first comment. Part of the trouble with this is seems to happen at various
widths...
Do you know if that's the same table your users are reporting a crash on
as well? Would love to get more tests cases if possible.
In the meantime, I opened a PR with my fix. Feel free to try it and see if
it helps!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fdehau/tui-rs/issues/470#issuecomment-884406190, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIOKF3AUZ2QCS66OREWVJDTY4HTXANCNFSM43B4KZ4A
.


LanceDB Support

It would be wonderful to see support for LanceDB—a fast, serverless vector store that's incredibly easy to use.

A community member made an integration: https://haystack.deepset.ai/integrations/lancedb


Continuing development of this Project

Current State of this Project
So if you are aware of what is happening right now, this repo is not maintained much anymore. I have tried reaching @HofmannZ here but got no reply, hope he reaches back soon. I am however continuing development of this project in my repo which I will share here later today. If @HofmannZ comes back to maintaining the repo, I will, of course, be happy to merge it back into this repo. Thank you.
Here is the new repo https://github.com/juicycleff/flutter-graphql

Cool ! So I'll create my MR's on your repo directly.

@olup yes sir. I cleaned up and here is the link https://github.com/juicycleff/graphql-flutter/tree/master

I also published to pub dart
https://pub.dartlang.org/packages/flutter_graphql

Will be removing the entire branches saving master. I will draw some plans and go from there. But you can send your PRs

Hello everyone,
As you all know we've not been able to maintain this project. This was due to some rearrangements of our resources in private projects. Simply put, we did not have enough time to also maintain this project. As a result, both the issue and PRs are piling up.
We really believe in the Flutter, especially in combination with GraphQL and are therefore currently working on a way to keep this project rolling.
We're planning to have a short planning session (SCRUM-ish) this weekend followed by a coding session that same weekend. Since we look at this as a community project, we'd like to collect as much input as possible. Therefore we're creating a survey to get some general insight into the community. We also like you to join us this weekend with either writing some code or doing some code reviews.
We are excited to pick up this project again, and we hope that you are too.
Zino

I'll update this post with the link to the survey tomorrow.

@HofmannZ Nice for you to show back. I will halt whatever I am doing until this weekend. Can't wait to see the outcome 😄

@juicycleff not sure if you get an update when I edit a comment so here’s the link to the survey: https://goo.gl/forms/WZ5JlNWASxd1ojfG3

Hi, great that you want to make a survey. But I guess you have to check the permissions. I get an error that says only users in the owners organization can see the form.

Yeah, please check settings and open up the form for every one.

@wwwdata @olup Oh, did not know it locks it down by default. Updated the settings, and it should work now!

I could not make it past page 2 in the survey.. Clicking the next button does not do anything for me. Was using Chrome browser. I don't know if that is a problem that you can fix or some google forms problem 🤷♂

@wwwdata Could reproduce, looks like it's solved now.

@HofmannZ @juicycleff
This is good news. I think most of us would like to know what is left to get a stable/beta 1.0.0 version and how long that would take between those involved.
If we could have an indication of that by after this weekend it will be great, as that will definitely help other devs in deciding to use this package or not.

Hi @HofmannZ, I didn't get a notification. I filled in the survey. What next?

@robert-stevens from my test, time should be spent on the cache and also pluggable persistent storage. Following the apollo-link-state pattern, so it is extensible. I am waiting for @HofmannZ plans. I halted my project for this so, I might jump back to dev if it delays too long

Hello everyone,
Thanks for all the great feedback on the survey! We think the answers added some great insights into the project. And since it did not include any sensitive data, we've enabled you to view the results.
We really want to push this project to a stable version and are therefore dedicating more time to maintaining it. We also think it's good to let you guys decide which features will end up in the client. Therefore we're requiring 3 peer-review per pull request, encouraging you more developers to get involved into the pull requests.
Today we also made some first steps by releasing our first beta. You can get it in your project today by requiring graphql_flutter: ^1.0.0-beta.
We hope we can continue building something great!
Zino

@HofmannZ -- With over 15 years experience with Opensource Software, may I make a humble suggestion and to OPEN this project, since it's so critical to many people, as a real open source with more contributors, people who can pub etc.  I would certainly nominate @juicycleff to be a core contributor etc. and maybe 1 or 2 others .  That way there isn't a "single" source (1 company) change of being abandoned with no ability for anyone to take over and keep it moving.

@sjmcdowall Definitely a great suggestion! @juicycleff are you open to joining as a core contributor?

Happy to hear that you guys are back and the development of this great library continues! We've been using the next branch with good success in an internal project so far. ❤
I like @juicycleff suggestion of following the apollo-link pattern, but I think this somewhat implies a more modular approach to GraphQL in Dart. What do you think of decoupling the internal GraphQL part from Flutter? There are no real dependencies on Flutter when using GraphQL with Dart. Furthermore there could be a smaller library on top of that providing the Flutter widgets (think react-apollo).
This would allow anyone wanting to work with GraphQL and Dart to use the "base" library which is then accompanied by Flutter widgets library for anyone who is using Flutter. Furthermore we could test all the core business logic without having to depend on Flutter.
What do you think? This isn't something which should be done for the release of a stable 1.0.0 version, but might be an interesting thought for the future.

@dbanck When we build the first version of the client, we took a load of inspiration from Apollo. This was done assuming that most people would already be familiar with the Apollo project and could, therefore, find there way around more easily.
The survey showed that the assumption was quite accurate, 89% of the respondents used Apollo before using this client. We, therefore, think it's a good decision to also use the modular link approach. We already made the first link available AuthLink, which does by popular request, provide a single point to provide Authorization.
Decoupling Dart from Flutter is definitely something we would like to do in the future. Though we think the current focus should lay on setting up a solid open source community. Hence we created a poll where we everyone can vote on who should become the new core contributors for this project.
https://goo.gl/forms/19KNF9IMuBKGngrz2
Zino

There is a lot to learn from Apollo and basing this library on their architecture is definitely a good decision.
@HofmannZ You might have to check the permissions of the new survey, I'm getting the "This form can only be viewed by users in the owner's organization." error.

@dbanck Should be fixed now

@HofmannZ
Thanks for the updates, I am going to check out the beta, any news/progress on optimistic results?

@sjmcdowall Definitely a great suggestion! @juicycleff are you open to joining as a core contributor?

Yes, I am definitely

FWIW -- I'd be ok as a backup publisher / merger / reviewer etc. too if desired...

On Feb 19, 2019, at 11:50 AM, Rex Raphael<EMAIL_ADDRESS>wrote:
@sjmcdowall https://github.com/sjmcdowall Definitely a great suggestion! @juicycleff https://github.com/juicycleff are you open to joining as a core contributor?
Yes, I am definitely
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/zino-app/graphql-flutter/issues/168#issuecomment-465215354, or mute the thread https://github.com/notifications/unsubscribe-auth/AB8M7Zq4TVhzrTJWvsr5MC4cz05Ucx4Yks5vPCtVgaJpZM4a0PRI.

Okay, the poll has three clear preferences: @cal-pratt, @camuthig and @juicycleff.
Are you guys cool with helping maintain the project? If so, shoot me an email to<EMAIL_ADDRESS>and I'll add you to the project.

@HofmannZ Hey, everyone. Thanks a lot for including me in this vote, but I'm going to take my hat out of the ring. I've become fairly busy with other priorities and havent been able to continue my Flutter experiments as I'd like. I would be happy to help in code reviews or general discussion from time to time, but I dont think I have enough cycles in the day to act as a useful core contributor. Thanks again!

I appreciate the vote of confidence, but I don't believe I can help out. I haven't worked with Dart since nearly my last commit to this project and already have other projects in the works that are taking up my bandwidth.

@cal-pratt @camuthig I understand that you do not have time to help to maintain the project. I just dropped in all the contributors into the hat ;)
@degroote22 @micimize You both received a load of votes as well. Do you guys have the time and willingness to help to maintain the project with us?
If so, shoot me an email to<EMAIL_ADDRESS>and I'll add you to the project.

@HofmannZ I'd be happy to! I have been fairly swamped recently, but that should be letting up soon and then I'll have time to focus on flutter stuff a lot more.
@robert-stevens (also maybe @juicycleff) It's not robust/tested enough to PR yet, but the most recent work I did on my fork was on adding optimism

@HofmannZ I'd be happy to! I have been fairly swamped recently, but that should be letting up soon and then I'll have time to focus on flutter stuff a lot more.
@robert-stevens (also maybe @juicycleff) It's not robust/tested enough to PR yet, but the most recent work I did on my fork was on adding optimism

@micimize that's awesome. Would you like to finish it off, or someone else picks it up?

@juicycleff if someone else wants to pick it up that's fine with me, not sure what condition it's in though - might be out of sync, definitely doesn't have enough tests. I'll hopefully have time to get back to it sometime soon

@micimize that's fine. I would like to take a look, but I want to focus on persistent caching for now. However @HofmannZ I didn't get the invitation, did you send it?

Hi @juicycleff, the invitation should've been in your inbox on the 26th. I just resend you the invitation link. Can you let me know if you've received it this time?

Yeah I did

Thank you :)

@juicycleff @HofmannZ There is a lot of discussions internally in our company on which package, and version to use. I assume that after this last few messages, we should stick on using this version of the package which @juicycleff will be merging his improvements and making core contributions to does that sound right?

@leoafarias Yes, unless you want to make use of @juicycleff's changes right this second, that's correct.

Correct

@juicycleff @HofmannZ sorry, there seems to be now another version of flutter-graphql.
https://github.com/snowballdigital/flutter-graphql
An updated readme on this repository pointing to this new version would be great

@leoafarias that is @juicycleff's fork of this repository, although I'm not sure if it's intended to replace this one.

quite confused right now. Which of the repos are maintained now? This? https://github.com/juicycleff/flutter-graphql  or https://github.com/snowballdigital/flutter-graphql this?  OR  https://github.com/zino-app/graphql-flutter ?

@ChristBKK those two are just unofficial forks and not intended to replace the current one.

@eusdima  yeah but this one seems to be lost? isn't @juicycleff  maintaining it well? Why can't he takeover or commit to this one here then?

@ChristBKK The plan was to pick people that are willing to continue developing this repo and @juicycleff was one of them. Since I didn't see him having any activity here, but he maintains mostly his forks, I removed him from graphql-fluter.

If you want to help the project you can respond to #196

The snowballdigital fork is also @juicycleff's fork. He'll probably consolidate them soon, and has expressed interest in making PR's and consolidating efforts, but has been quite busy (like all of us).
I'd recommend following #197 for tracking the progress we make on consolidation.

Hi sorry for all the confusion. My fork at https://github.com/juicycleff/flutter-graphql  was little messed up because I had stripped of a lot of this repo branches and tags and did a lot of change to simplify the process of contributing and that was before Hoffman responded. However, I found out the pace of reviewing PRs here was quite slow and is affecting my project and I also have people in my company interested in Flutter and I decided to have work on this at my own pace and have my colleagues contribute. As moving forward. The two forks are still quite different and I am still considering an approach. I recently relocated to Norway so I was quite unavailable. I just need to get my project fully functional hence I need a replica of react-apollo asap for flutter, which means I will hold on to my repo for a bit. There are great possibilities to merge in the future, but for now, I just need this on RAD. I hope this clears out any confusion.

@juicycleff I am sorry I overreacted about what I said. But I want this project to move forward faster. The goal of GraphQL-flutter was always to become an apollo-client. Would be great if you could join the discord channel referenced in #196 where I would like to hear more about the great work that you are doing in your library and possibly discuss the roadmap.

Its fine @eusdima. Sorry I saw the discussion last night, but I had to sleep as it was a bit late and I'm getting used to weather


[Authoring] Allow custom overloads

Closes #1569.
Closes #667.

I think we would need a projection that doesn't have overloads, which from my understanding is none.

Mh. I mean, changes seem fine to me, let's just see if @manodasanW thinks we need tests or not 🙂

Oh, one more thing. This change doesn't seem to work with CsWinMD (not the source generator itself), probably due to the Windows.winmd file not being imported properly, though CsWinMD is probably low priority at the moment.

I think we would need a projection that doesn't have overloads, which from my understanding is none.
Or possibly an IL inspector? I'm not sure if we have any ATM.

Mh. I mean, changes seem fine to me, let's just see if @manodasanW thinks we need tests or not 🙂

Can't we just add another pair of functions similar to this with a different method name and then use the Overload attribute on them to define the name that should be used for the overload?

Can't we just add another pair of functions similar to this with a different method name and then use the Overload attribute on them to define the name that should be used for the overload?

I’m not sure how that would work for the test. Don’t we have to check the WinMD?


EventBus should trigger registered listeners in the same session synced

We need to check if listeners in the same session called async or sync....
At the end the eventBus must execute all listeners that are part of the same DolphinContext sync. All other should be handled async.

see #269


wiringPiSetup: Must be root. (Did you forget sudo?)

Raspberry Pi Zero
Raspbian: Linux raspberrypi 4.4.38+ #938 Thu Dec 15 15:17:54 GMT 2016 armv6l GNU/Linux
node: v6.9.5
npm:3.10.10
Hello,
First when i tried to install :    sudo npm install -g raspi-io --unsafe-perm --force
I've got following error :
make: Entering directory '/usr/lib/node_modules/raspi-io/node_modules/raspi/build'
  CXX(target) Release/obj.target/addon/src-native/addon.o
  CXX(target) Release/obj.target/addon/src-native/init.o
../src-native/init.cc:25:22: fatal error: wiringPi.h: No such file or directory
 #include <wiringPi.h>

To solve this issue i've installed :
sudo apt-get install wiringpi
sudo npm install -g raspi-wiringpi --unsafe-perm --force

Then i tried to use it with johnny-five (installed by : sudo npm install -g johnny-five --unsafe-perm --force) over node-red i ve got the following blocking error:
wiringPiSetup: Must be root. (Did you forget sudo?)
Welcome to Node-RED
===================
14 Feb 23:23:28 - [info] Node-RED version: v0.16.2
14 Feb 23:23:28 - [info] Node.js  version: v6.9.5
14 Feb 23:23:28 - [info] Linux 4.4.38+ arm LE
14 Feb 23:23:33 - [info] Loading palette nodes
pi : TTY=unknown ; PWD=/home/pi ; USER=root ; COMMAND=/usr/bin/python -u /usr/lib/node_modules/node-red/nodes/core/hardware/nrgpiopy info
pam_unix(sudo:session): session opened for user root by (uid=0)
pam_unix(sudo:session): session closed for user root
14 Feb 23:24:01 - [warn] ------------------------------------------------------
14 Feb 23:24:01 - [warn] [sensehat] Error: Can't find Sense HAT python libraries. Run sudo apt-get install sense-hat
14 Feb 23:24:01 - [warn] ------------------------------------------------------
14 Feb 23:24:01 - [info] Settings file  : /home/pi/.node-red/settings.js
14 Feb 23:24:01 - [info] User directory : /home/pi/.node-red
14 Feb 23:24:01 - [info] Flows file     : /home/pi/.node-red/flows_raspberrypi.json
14 Feb 23:24:01 - [info] Server now running at http://<IP_ADDRESS>:1880/
14 Feb 23:24:01 - [debug] loaded flow revision: 51859858b072360ca45c68d82fd5d322
14 Feb 23:24:01 - [debug] red/runtime/nodes/credentials.load : no user key present
14 Feb 23:24:01 - [debug] red/runtime/nodes/credentials.load : using default key
14 Feb 23:24:01 - [info] Starting flows
wiringPiSetup: Must be root. (Did you forget sudo?)
nodered.service: main process exited, code=killed, status=6/ABRT
Unit nodered.service entered failed state.
nodered.service holdoff time over, scheduling restart.
Stopping Node-RED graphical event wiring tool....
Starting Node-RED graphical event wiring tool....
Started Node-RED graphical event wiring tool..

Did you have an idea ?
Thks for your help

A couple of notes:

sudo npm install -g raspi-wiringpi --unsafe-perm --force is not necessary, and may even cause issues. You should only need to do sudo apt-get install wiringpi
You should not install johnny-five globally, or as root. Instead, you should run npm install johnny-five raspi-io from your project directory.
When you run the program, it must be run as root. Normally this is done via sudo node myapp.js, but I see you're running Node-Red, so it's different. I don't know much about Node-Red, so you'll need to consult the Node-Red documentation. FWIW, this error is coming from Wiring Pi itself, not from raspi-io.

ok thks for help :)


Restore last session after closing wezterm

It would be nice to restore your session from where you left off after opening wezterm for the first time after closing all wezterm processes.
This would probably require storing state about the last active workspace or similar

Yes, I like the granularity of Resurrect and Smart Workspace. However, having the ability to save the whole session when quitting (or crashing, if possible) and restoring it upon re-entry would be very sweet.

Yes, I like the granularity of Resurrect and Smart Workspace. However, having the ability to save the whole session when quitting (or crashing, if possible)

From what I could gather from the last time I looked into this (#4 ), this isn't as easy as there is no exit event to hook into for saving the current state.
However if this keybinding is something that is desired, then please let me know by commenting or opening a new issue.

and restoring it upon re-entry would be very sweet.

I think this is possible with the gui-events and by saving meta data about the latest session in a file, I just havn't had time to come around to this yet.
I am currently super busy with University until at least the 16th of Dec. so I cannot give any promises for when this feature will be implemented. However I do plan to implement this in the upcoming future and if no one else beats me to it, then you can probably expect it at the latest around new years. However if you or anyone else wants to give it a try before new years, then I would love to ping pong and review a PR :smile:
Also thanks for commenting, I had not seen that this issue had 3 likes as I don't get notified about likes, but it seems that this is a much desired feature, so comments like this reminds me of what to prioritize :smile:


Bug in BioSchema implementation

JSON contains linebreaks in some places which is not permitted, e.g.

To be valid JSON-LD IDs the spaces need to be escaped, so ""Open Life Science-OLS Introduction-1" becomes "Open%20Life%20Science-OLS%20Introduction-1" for example.
there is another slight issue with that too, because @ids are URIs, so the above would actually be the short form of https://openlifesci.org/openseeds/Open Life Science-OLS Introduction-1 which does not actually resolve to any page.
typically when using an @id that does not point to a URL, you can use # at the start, so altogether it would look something like "@id" : "#Open%20Life%20Science-OLS%20Introduction-1

idk if this is related or not to the failures of structured metadata warnings we've been getting from google's search dashboard - flagging for @NPDebs's attention.

Thanks for flagging!
It most likely is related. This is on my radar now, so we'll see. 👀


fix(common): Ensure server.$beforeRoutesInit priority

:tada: This PR is included in version 6.95.8 :tada:
The release is available on:

v6.95.8
GitHub release

Your semantic-release bot :package::rocket:


replace commons.lang3.StringUtils with springframework.util.StringUtils

Replaces usage of org.apache.commons.lang3.StringUtils with org.springframework.util.StringUtils.
org.apache.commons:commons-lang3 is not needed anymore and could be removed from dependency management (currently not declared explicityl but picked up transiently)

Looks great, will have a look again when the PR is marked as 'ready for review'


Failed to calculate diff: FetchError -- returns 404

This is for a private organization repository that uses SSO, so I'm not sure if this is an expected behaviour or not. I made sure to authorize the personal access token for the organization, but still no luck.
When I run this on the command line ( with the token, owner, repo, & pull number filled in properly ) it does return a JSON response though:
curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/repos/OWNER/REPO/pulls/PULL_NUMBER

The extension makes a network request in the background, could you inspect it and compare the request that's returning a 404 with the one from the CLI that works?

Enter chrome://extensions in your navigation bar
Ensure "Developer Mode" is turned on, there's a switch in the top right corner
Find "GitHub: Better Line Counts" and inspect the service worker
Switch to the network tab in the devtools window
Reload the page (there's a cache, so maybe visit a PR on the same repo you haven't looked at recently?)

The URL should look more like this:
https://api.github.com/repos/wxt-dev/wxt/pulls/344/files?page=1&per_page=100

Actually, are you using github.com, or are you using a <company-name>.github.com/github.<company-name>.com? All API calls are made to github.com, so that would explain your 404.

I don't know what changed, but it's all working now:

( from a PR I'm working on right now )


Auto renew subscriptions

It may be nice to have an --autorenew subscription flag for the register message so the client does auto-register with the tower if it gets out of appointments, especially if the tower is offering the subscription altruistically.
Currently, if the subscription expires and the user does not realize, pending appointments may start to pile up and waste user resources.

Turns out CoreLN does not support options, only positional (or named) parameters.

I know this is not a solution but I have this command running in a cron to autorenew, if that helps someone:
lightning-cli listtowers | jq -r 'to_entries | map(.value += {id:.key} | .value) | map(select(.available_slots<1000))[] | [ .id + "@" + .net_addr|sub("http://";"")|s ub("https://";"")] | @tsv' | xargs lightning-cli registertower

@3cola that's actually pretty cool. There is an open PR adding this functionality to the plugin though 😁
https://github.com/talaia-labs/rust-teos/pull/164

Closed via #164

Closed via https://github.com/talaia-labs/rust-teos/pull/164


Update webpack to fix dynamic imports

In v3.0.1, using<EMAIL_ADDRESS>dynamic imports fail. See the issue here. The issue's been fixed since 4.30.0, with the latest current version at 4.35.0
When will react-scripts be updated with the fixed version of webpack? I imagine it's a simple dependency update, but I don't know how the latest version will affect CRA

I didn't realize this issue had been fixed in webpack. Thanks for pointing that out. We'll try and get a new version released in the next few days, provided the webpack upgrade doesn't introduce any other issues.

@LinusBorg maybe you should update webpack version now too?

In case anyone comes across this issue, this won't affect new installs.
If you have an existing install you can try removing node_modules and your lock file, then reinstalling. This will give you the latest Webpack version.

In case anyone comes across this issue, this won't affect new installs.
If you have an existing install you can try removing node_modules and your lock file, then reinstalling. This will give you the latest Webpack version.

This does not work for our project, the problem is till there.
So we are waiting for the next CRA release.

This should work @lucamartini, did you check what Webpack version you had installed?

it works with yarn, but not with npm.

That's interesting. And not what I would have expected... it's not ideal, but you could also update package-lock.json to point to the latest version. We're working on the next version now.
@iansu, this might warrant a quick patch-release.

I created a new CRA+TS project a couple days ago.  I got<EMAIL_ADDRESS>and it also explicitly points to<EMAIL_ADDRESS>using Yarn 1.16.
Any news on getting this out as an update?

@markerikson it should be next week.

Warning: Dirty dirty solution below
This is what I did to temporarily solve this issue
In the root of my CRA project:
$ npm install webpack # This gave me<EMAIL_ADDRESS>$ rm -fr node_modules/react-scripts/node_modules/webpack/*
$ cp -r node_modules/webpack/* node_modules/react-scripts/node_modules/webpack/
$ vim node_modules/react-scripts/package.json # Change  "webpack": "4.29.6",  ->  "webpack": "4.38.0",

The last step is needed for CRA's preflight check to pass

Or use Yarn's "resolutions" to force the use of an updated Webpack version:
https://yarnpkg.com/lang/en/docs/selective-version-resolutions/

Had to automate this step for our CI setup. Added a "postinstall" script to package.json
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "postinstall": "rm -fr node_modules/react-scripts/node_modules/webpack/* && cp -r node_modules/webpack/* node_modules/react-scripts/node_modules/webpack/ && sed -i -e 's/\"webpack\": \"4.29.6\"/\"webpack\": \"4.39.0\"/' ./node_modules/react-scripts/package.json"
  },

@Tobbe, you shouldn't need to do that. Are you in npm or Yarn?

@mrmckeb I'm using npm
$ node -v
v12.7.0
$ npm -v
6.10.0

This is fixed and will be released in 3.1 so I'm going to close this issue.


Allow user-defined model name in the defineObjectsTag

the <neba:defineObjects /> tag currently always uses the key "m" for model publication. Users should be allowed to override this with an arbitrary variable name.

Implemented, done!


fix qif export to SDCard

:+1: thanks :)

@fefe982, beware this PR reverts the changes that fixed #357. Also, it's not considered good practice to have a method do more than what it's expected from its name (this confused me a lot while reading the code to fix the bug).
I think we should be careful with SD card operations. It seems there's some inconsistency in how different devices handle it's access. That may be the cause of the export issues.

@rivaldi8 so does it mean that sharing multiple files (split into QIF) is what causes the sharing file to fail.
Also, we rely on the Android getExternalStorageDirectory API. The assumption is that this will return us a location where can safely store the files.
In the future I'm thinking of changing that to use the cache for the temporary internal export before we move the file to the location desired by the user.

@rivaldi8 I've already merged this request.
I was just thinking, since you identified the cause of the problem with file sharing to 3rd party services, maybe we can fix it without breaking QIF exports. Any ideas?

@codinguser The problem with file sharing is that copyFile() doesn't copy the file src to dst, if src is a Qif. Instead, it calls splitQif(), which splits src into multiple files with dst as file name suffix.
The general problem, I think, is that splitQif() should be only called once as part of the process of exporting to QIF. Then, all export options should deal with multiple files per export.
@fefe982 Could you describe the issue you are fixing with this PR so I can try to reproduce it?

This issue being fixed is that QIF file was not  being split into the
different currencies.  Or at least, if it was, then only the original
unsplit version was given to the user as the result of the export.
@rivaldi8 Does this mean that the problem of not being able to export is
again present on your device after this patch?
If so then maybe we can do it as you suggest and  treat all exports as a
list of files. Which would be 1 for XML and multiple for OFX.
I'll look into it.
On Nov 5, 2015 17:58, "Àlex Magaz Graça"<EMAIL_ADDRESS>wrote:

@codinguser https://github.com/codinguser The problem with file sharing
is that copyFile() doesn't copy the file src to dst, if src is a Qif.
Instead, it calls splitQif(), which splits src into multiple files with
dst as file name suffix.
The general problem, I think, is that splitQif() should be only called
once as part of the process of exporting to QIF. Then, all export options
should deal with multiple files per export.
@fefe982 https://github.com/fefe982 Could you describe the issue you
are fixing with this PR so I can try to reproduce it?
—
Reply to this email directly or view it on GitHub
https://github.com/codinguser/gnucash-android/pull/419#issuecomment-154122046
.

Yes, it's failing again.

@codinguser, are you working on this? If not, I can look into fixing it.

@rivaldi8 please go ahead and look into it.
Won't have time the next few days
Thanks

@rivaldi8 have you been able to look into it yet?

Yes, I'm working on it.

@codinguser It have taken more time than I thought but I've finally finished with the fix. I just need some more time to review the changes, do some further clean up, and testing. I'll send a pull request tomorrow.

@rivaldi8 great! looking forward to it...


Nushell: Completions results in surprising expansions of arguments passed to subcommands via uv run

I was trying to run a command such as
uv run pyright.cmd .\src\ -p pyright_ci_config.json

This fails with
Unexpected option --python.
pyright --help for usage

adding verbose and I see
DEBUG Running `pyright.cmd --python .\pyright_ci_config.json`

It seems that since uv it self has a -p/--python arg the -p arg to powershell is expanded to --python
A similar effect can be observed with -m which is expanded to --module if you run uv run python -m build
After some debugging, I found out that this only happens in nushell and only if I have source the uv generated completions.
uv generate-shell-completion nushell o> uv.nu

in config.uv
source uv.nu

uv 0.5.6 (b70c4f30e 2024-12-03)
nu 0.100.0
Windows 11

I run uv 0.5.6 and Nushell 0.100.0 on Windows 10. I freshly generated the shell completion and ran
uv run pyright.cmd .\src\ -p pyright_ci_config.json

Granted, I don't have Pyright in my path, nor is there a pyright_ci_config.json in my working directory, but in the logs I get:
DEBUG Running `pyright.cmd .\src\ -p pyright_ci_config.json`

as expected. Same if I run the command from PowerShell.
It's also funny that the .\src\ disappears from your logs. Does any of this happen when you run Nushell without config (nu -n) ?

@dedebenui Thanks for your comments. Yes it does also happen in a fresh shell (nu -n)
Specifically I do
source nu.env

and then
uv run --verbose python -m build

or
uv run python -m build

fails with
DEBUG Running `python --module build`
unknown option --module

However, running
uv --verbose run python -m build

or
uv run python `-m` build

Runs as expected.
Furthermore, the syntax high lighting seems to indicate that the commands are interpreted differently.
Compare

and

With respect to ./src that may have just been missed when I pasted.


Could we support the Radial progress for Flowbite?

I'd very like the flowbite used in my project, but seems it doesn't support radial progress, right?
I just found this horizontal progress bar instead of radial progress(circle).
So, could we support it?

Such as this:

Hey @PublicWorld,
Thanks for the suggestion - already handed this over to our design team :) @robert1508
Cheers,
Zoltan


Detect Rectangle on Canny Edge image

Summary of your issue
I have used Magick.NET to create a binary image where the edges in the image are ìn white and the rest of the image in black. How can I use the latest version of OpenCvSharp to detect the rectangle on the image as the code am using has Cv2 while the library that I installed has no such class.

Environment
.NET core with Rider and C# 7.0
Write your environment.
What did you do when you faced the problem?
Tried to make chat GPT generate the code
Write here
Example code:

//load the image
Mat mat = new Mat("image.jpg", ImreadModes.GrayScale);
//the image is already in binary form
//how can I use OpenCvSharp to detect rectangle on the image
paste your core code

Output:

What did you intend to be?
I expect the code to return a rectangular object on where the square or rectangle is located

If you already have the image binarized, all you need to do is call the CV2.Canny method:
Mat mat= new Mat("Image.jpg", ImreadModes.GrayScale);
Cv2.Canny(mat, mat, [threshold1], [threshold2])
Replace the [threshold1] and [threshold2] with the numeric values you want to use.


MDTT-18: Automated quality checks

Codecov Report

Merging #20 (959aad0) into main (f8faeea) will increase coverage by 5.35%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##               main      #20      +/-   ##
============================================
+ Coverage     11.31%   16.66%   +5.35%
- Complexity      128      130       +2
============================================
  Files            19       19
  Lines           380      384       +4
============================================
+ Hits             43       64      +21
+ Misses          337      320      -17

Impacted Files
Coverage Δ

src/DataSource/DataSource.php
100.00% <100.00%> (+100.00%)
:arrow_up:

src/DataSource/Database.php
20.83% <100.00%> (+20.83%)
:arrow_up:

src/Definition/Validate/DataSource/Validator.php
39.58% <0.00%> (+20.83%)
:arrow_up:

src/Definition/Validate/DataSource/Database.php
100.00% <0.00%> (+100.00%)
:arrow_up:

Continue to review full report at Codecov.

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


error when starting dtwsagent

Error when starting dtwsagent
$ sudo service dynaTraceWebServerAgent start

OUTPUT:
File not found or not executable: /opt/dynatrace-6.2-agent/dynatrace/agent/lib/dtwsagent

Can you provide your overrides and a view into your filesystem at '/opt/dynatrace-6.2-agent'? Does it work when you don't change the prefix and leave it as '/opt'?

I ran a quick test using Test Kitchen (described in README.md).
Asnode['dynatrace']['wsagent_package']['linux']['installer']['prefix_dir'] I used /opt/dynatrace-6.2-agent:
kitchen converge wsagent-package-debian
kitchen login wsagent-package-debian

Inside the Docker container, an ls -l /opt/dynatrace-6.2-agent shows me:
lrwxrwxrwx 1 root      root        38 Aug 18 18:29 dynatrace -> /opt/dynatrace-6.2-agent/dynatrace-6.2
drwxr-xr-x 5 dynatrace dynatrace 4096 Aug 18 18:29 dynatrace-6.2

...and a service dynaTraceWebServerAgent status shows:
dynaTrace WebServer Agent daemon is running:
999       6284     1  0 18:44 ?        00:00:01 /opt/dynatrace-6.2-agent/dynatrace/agent/lib64/dtwsagent

Not sure where things break on your end, but I am curious to learn.

Can I close the issue?

I am very sorry @metmajer I haven't yet had a chance to look into this. Will check as soon as I get a chance. Will keep you posted.


An issue exists on a mac if you ctrl+click on a sortable element

after the contextual menu is dismissed, the element starts sorting

cancel the sorting if it is a ctrl click
workaround jquery-ui bug for cancelling an in-progress sort

Caveat

there is a flash of element movement that is undesirable in order
to cancel the sort. blame jquery-ui

part 1 of the bug.