text:
Command-line output is cleared when focusing a different program window

Describe the bug
Vim in the terminal doesn't seem to support the FocusGained or FocusLost events.
But in some terminals (like xterm and st), it's possible to restore them by setting 't_ti' and 't_te' appropriately.
However doing so makes Vim redraw the screen and clear a multi-line output of an Ex command when focusing a different program window (like the one of the web browser for example).
To Reproduce

Write these lines in /tmp/vimrc:
 let &t_ti = "\e[?1004h"
 let &t_te = "\e[?1004l"
 exe "set <S-F18>=\e[O"
 exe "set <S-F19>=\e[I"
 fu! s:do(event) abort
     if exists('#'.a:event)
         exe 'do '.a:event.' <nomodeline> %'
     endif
 endfu
 nno <silent> <S-F18> :<c-u>call <sid>do('FocusLost')<cr>
 nno <silent> <S-F19> :<c-u>call <sid>do('FocusGained')<cr>
 augroup restore_focus_events
     au!
     au FocusGained * echom 'FocusGained was fired'
     au FocusLost * echom 'FocusLost was fired'
 augroup END

From xterm, start Vim with this minimal vimrc:
 $ vim -Nu /tmp/vimrc

Run an Ex command whose output contains multiple lines:
 :echo "foo\nbar"

Focus a different program window (web browser, email client, ...).

Focus back the xterm window.

The output of :echo "foo\nbar" has been cleared.

Expected behavior
I would expect the output of :echo to have been preserved even after focusing a different program window.
Environment

vim --version: VIM - Vi IMproved 8.1  Included patches: 1-1282
OS: Ubuntu 16.04.6 LTS
Terminal: st

Additional context
gVim does support FocusGained and FocusLost, and when you run an Ex command from gVim, whose output contains multiple lines, you can focus a different window without the command-line being cleared.
So, making Vim in a terminal preserve a multi-line output when focusing a different window, would make the latter more consistent with gVim.

The previous minimal vimrc can be reduced to these 2 lines:
let &t_ti = "\e[?1004h"
let &t_te = "\e[?1004l"

But if you want to avoid E349, you need these 2 additional statements:
exe "set <S-F18>=\e[O"
exe "set <S-F19>=\e[I"

If you want the code to be useful, you need these 7 additional lines:
fu! s:do(event) abort
    if exists('#'.a:event)
        exe 'do '.a:event.' <nomodeline> %'
    endif
endfu
nno <silent> <S-F18> :<c-u>call <sid>do('FocusLost')<cr>
nno <silent> <S-F19> :<c-u>call <sid>do('FocusGained')<cr>

And if you want the events to be restored in all modes, not just normal mode, you need 2 additional mappings for each missing mode.

@lacygoill Why close this? Is there a solution already?

@lacygoill Why close this? Is there a solution already?

No, but tweaking these particular terminal options looks like a hack, which is not worth being fixed.  The proper solution is to use the FocusGained and FocusLost events.  They are not yet available in the terminal, but there is a todo item:
https://github.com/vim/vim/blob/bb0956fc65ebe8df1da823f9c4d6a0013d9ba5c1/runtime/doc/todo.txt#L547-L549
As well as an open issue: https://github.com/vim/vim/issues/609.

No, but tweaking these particular terminal options looks like a hack, which is not worth being fixed.  The proper solution is to use the FocusGained and FocusLost events.  They are not yet available in the terminal, but there is a todo item:
https://github.com/vim/vim/blob/bb0956fc65ebe8df1da823f9c4d6a0013d9ba5c1/runtime/doc/todo.txt#L547-L549
As well as an open issue: https://github.com/vim/vim/issues/609.

@lacygoill I don't get it, I have vim --version:
❯ vim --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 04 2021 20:30:52)
macOS version - arm64
Included patches: 1-3290
Compiled by Homebrew

but FocusGained/FocusLost are still not fired within tmux. I have xterm-256color outside, and tmux-256color inside tmux. The focus events seem to be firing outside tmux though...

You might need to set the terminal options :help 't_fe' and :help 't_fd'.
Try something like this:
if &term =~ 'tmux\|screen' && &t_fe == ''
    let &t_fe = "\<Esc>[?1004h"
    let &t_fd = "\<Esc>[?1004l"
endif

See :help xterm-focus-event.
Vim automatically sets these options when it thinks that the terminal supports the focus tracking feature.  Inside tmux, Vim doesn't know the true identity of the outer terminal, so it doesn't set these options for you ($TERM is tmux, screen or some derivatives, but the outer terminal could be anything).

In tmux, you also need to make sure that  the server option focus-events is set:
set-option -s focus-events on

We might want to document this:
diff --git a/runtime/doc/term.txt b/runtime/doc/term.txt
index 811d50752..9c757d0d6 100644
--- a/runtime/doc/term.txt
+++ b/runtime/doc/term.txt
@@ -556,6 +556,11 @@ If this feature is enabled by the 't_fe' sequence, special key sequences are
 sent from the terminal to Vim every time the terminal gains or loses focus.
 Vim fires focus events (|FocusGained|/|FocusLost|) by handling them accordingly.
 Focus event tracking is disabled by a 't_fd' sequence when exiting "raw" mode.
+
+If the feature is not enabled, you might need to set the options like this:
+	`let &t_fe = "\<Esc>[?1004h"`
+	`let &t_fd = "\<Esc>[?1004l"`
+
 If you would like to disable this feature, add the following to your .vimrc:
 	`set t_fd=`
 	`set t_fe=`

@lacygoill That worked, except that now when I the focus moves into vim from another pane (which just has my zsh login shell), at times it adds some weird escape sequence on top of text in vim buffer. Maybe its some tmux-vim interaction @ncim. I'll be away from computer, its late night here. Can add more logs tomorrow, but it could be related to this https://github.com/tmux/tmux/issues/2844. Though my machine is Mac, and I see this only with your suggested change to vimrc & when focus moves within vim (1 out of 20 times). It does not even happen with neovim...

Those are 2 identical SGR sequences:
^[[<0;70;52m

They report the position of the mouse using an encoding scheme allowing to go beyond the ordinate 223 (255 - 32).  It seems that Vim doesn't understand the sequence.  This suggests that the 'ttymouse' option is not set correctly.  It should have the value sgr, because that's the scheme which is used by your terminal to encode the ordinates of your mouse position.
Try to add this in your vimrc:
if &term =~ 'screen\|tmux'
    set ttymouse=sgr
endif

It's probably not set correctly inside tmux, because – again – Vim doesn't know the true identity of the outer terminal.  It relies on the Vim option 'term', whose value is derived from the environment variable $TERM, which – in tmux – must be tmux, screen or some derivative.  Since Vim doesn't know what are the true capabilities of the outer terminal, it falls back on the value xterm when setting 'ttymouse'; in turn, this prevents Vim from understanding the sgr encoding scheme, causing any sequence using this scheme to be simply sent back to the terminal which prints it on the screen.
We might need to either better detect the true identity of the outer terminal and automatically set those options correctly, or at least add a help tag for tmux/screen users, telling them which options they should set, why, and how (i.e. with which values).

or at least add a help tag for tmux/screen users, telling them which options they should set, why, and how (i.e. with which values).

As a suggestion, here is a patch:
diff --git a/runtime/doc/term.txt b/runtime/doc/term.txt
index 811d50752..99f053444 100644
--- a/runtime/doc/term.txt
+++ b/runtime/doc/term.txt
@@ -127,6 +127,42 @@ automatically, you can try using something like this: >
 	  exec "set t_PE=\e[201~"
 	endif
 <
+							*tmux-integration*
+
+If you experience issues when running Vim inside tmux, try this: >
+
+    if !has('gui_running') && &term =~ '^\%(screen\|tmux\)'
+        " better mouse support
+        " see :help 'ttymouse'
+        set ttymouse=sgr
+
+        " enable true colors
+        " see :help xterm-true-color
+        let &termguicolors = v:true
+        let &t_8f = "\<Esc>[38;2;%lu;%lu;%lum"
+        let &t_8b = "\<Esc>[48;2;%lu;%lu;%lum"
+
+        " enable bracketed paste mode
+        " see :help xterm-bracketed-paste
+        let &t_BE = "\<Esc>[?2004h"
+        let &t_BD = "\<Esc>[?2004l"
+        let &t_PS = "\<Esc>[200~"
+        let &t_PE = "\<Esc>[201~"
+
+        " enable focus event tracking
+        " see :help xterm-focus-event
+        let &t_fe = "\<Esc>[?1004h"
+        let &t_fd = "\<Esc>[?1004l"
+
+        " enable modified arrow keys
+        " see :help xterm-modifier-keys
+        execute "silent! set <xUp>=\<Esc>[@;*A"
+        execute "silent! set <xDown>=\<Esc>[@;*B"
+        execute "silent! set <xRight>=\<Esc>[@;*C"
+        execute "silent! set <xLeft>=\<Esc>[@;*D"
+    endif
+<
+
 							*cs7-problem*
 Note: If the terminal settings are changed after running Vim, you might have
 an illegal combination of settings.  This has been reported on Solaris 2.5

@lacygoill I already had ttymouse=sgr so there is something different going on. From my .vimrc:
set mouse=a
if !has('nvim')
    set ttymouse=sgr
    if &term =~ 'tmux\|screen' && &t_fe == ''
        let &t_fe = "\<Esc>[?1004h"
        let &t_fd = "\<Esc>[?1004l"
    endif
endif

OK, a few questions:

The issue happens when you focus back the Vim window, right?

Does it happen outside tmux, or only inside?

How do you focus back the Vim window?  Alt-Tab, left-click mouse, tmux key binding, ...
Does it even matter?

Which terminal are you using?

Can you reproduce in xterm, or is it specific to some terminal(s)?

If there is no issue outside tmux, what's the value of $TERM (again outside tmux)?

If the issue is specific to tmux, then it's probably related to a Vim (terminal) option.  If so, I know how to find which one(s) need(s) to be set, but the debugging process might take some time if you need a few dozen tests to reproduce the issue; which is why – ideally – I would prefer being able to reproduce on my machine (I can't).
The basic idea is to dump all the terminal options in a file outside tmux, then restart Vim sourcing this file.  For each test, you disable half of the file and start a bisecting process, until you find which option is the culprit.
You can dump all the terminal options in a file with :put =execute('set termcap').  The options are not split one per line (which helps to start bisecting); but I have a plugin which does this automatically.

Also, even if you've set ttymouse correctly, make sure that it has not been reset later:
:echo &ttymouse
sgr

And make sure you have the mouse_sgr feature:
:echo has('mouse_sgr')
1

Just checked, it happens outside of tmux inside vim when t_fe & t_fd are not manually set in .vimrc.

IIUC, if t_fe and t_fd are manually set, the issue is present outside tmux, but absent inside.
It might be caused by a terminal option.
If I were you, I would first try to get a diff of :set termcap inside vs outside tmux; both times with t_fe and t_fd set.
The default output is not suitable for a diff (because multiple settings are written on the same line), but I have a plugin which provides a :DebugTerminfo command to format the output 1 setting per line.  You don't need to install the plugin definitively; if you're interested, temporarily add this block in your vimrc:
set pp+=/tmp/.vim
let dir = '/tmp/.vim/pack/debug/opt/debug'
if !dir->isdirectory()
    call mkdir(dir, 'p')
    call system('git clone https://github.com/lacygoill/vim-debug ' .. dir)
endif
packadd debug

Then:

start Vim outside tmux (and with t_fe and t_fd manually set)
run :DebugTerminfo, then :saveas /tmp/inside_tmux.vim
restart Vim inside tmux (and with t_fe and t_fd manually set)
run :DebugTerminfo, then :saveas /tmp/outside_tmux.vim
get a diff of /tmp/inside_tmux.vim and /tmp/outside_tmux.vim

Also, you could get a log file:
$ vim +"call ch_logfile('/tmp/logfile', 'w')"

Reproduce the issue then look for the pattern [< and see whether there is something interesting around it.  As an example, here is what I get when I change the focus from xterm+Vim to a different window, then focus xterm+Vim back, using a left-click both times:
==== start log session ====
  0.000016 : raw terminal output: "^[[2 q^[[2;1H▽^[[6n"
  0.000051 : raw terminal output: "^[[2;1H  ^[[3;1H^[Pzz^[\^[[0%m^[[6n"
  0.000097 : raw key input: "^[[2;2R"
  0.000113 : raw key input: "^[[3;1R"
  0.000151 : raw terminal output: "^[]10;?^G^[]11;?^G"
  0.004814 : raw key input: "^[]10;rgb:3737/3b3b/4141^G^[]11;rgb:dbdb/d6d6/d1d1^G"
  0.008562 : SafeState: Start triggering
  0.012113 : raw terminal output: "^[[26;1H                                                           ^[[27;1H                                                           ^[[28;1H                                                           ^[[29;1H                                                           ^[[30;1H                                                           ^[[31;1H                                                           ^[[m^[[38;2;78;78;78m^[[48;2;208;208;208m^[[32;1H^[[1m^[[7m^[[38;2;135;95;95m^[[48;2;215;215;175m ^[[m^[[38;2;78;78;78m^[[48;2;208;208;208m^[[1m^[[38;2;135;95;95m^[[48;2;215;215;175m[No Name]^[[m^[[38;2;78;78;78m^[[48;2;208;208;208m^[[1m^[[7m^[[38;2;135;95;95m^[[48;2;215;215;175m                                       0,1  100% ^[[m^[[38;2;78;78;78m^[[48;2;208;208;208m^[[33;1H                                                           ^[]2;[No Name] - VIM^G"
  0.012439 : looking for messages on channels
  0.012451 : SafeState: back to waiting, triggering SafeStateAgain
  1.724664 : raw key input: "^[[O"
  1.725121 : looking for messages on channels
  1.725150 : SafeState: back to waiting, triggering SafeStateAgain
  4.524284 : raw key input: "^[[I"
  4.524393 : looking for messages on channels
  4.524411 : SafeState: back to waiting, triggering SafeStateAgain
  4.524921 : raw key input: "^[[<0;57;18M"
  4.525073 : SafeState: reset: key typed
  4.525108 : SafeState: Start triggering
  4.525666 : looking for messages on channels
  4.525684 : SafeState: back to waiting, triggering SafeStateAgain
  4.591695 : raw key input: "^[[<0;57;18m"
  4.591833 : SafeState: reset: key typed
  4.591856 : SafeState: Start triggering
  4.592119 : looking for messages on channels
  4.592127 : SafeState: back to waiting, triggering SafeStateAgain
  6.594258 : SafeState: reset: key typed
  6.647365 : SafeState: Start triggering
  6.647571 : looking for messages on channels
  6.647578 : SafeState: back to waiting, triggering SafeStateAgain
  6.850199 : raw key input: ":"
  6.850260 : SafeState: reset: key typed
  6.881682 : SafeState: Start triggering
  6.881723 : looking for messages on channels
  6.881729 : SafeState: back to waiting, triggering SafeStateAgain
  6.986116 : raw key input: "q"
  6.986178 : SafeState: reset: key typed
  6.986205 : SafeState: Start triggering
  6.986237 : looking for messages on channels
  6.986245 : SafeState: back to waiting, triggering SafeStateAgain
  7.074100 : raw key input: "!"
  7.074164 : SafeState: reset: key typed
  7.074229 : SafeState: Start triggering
  7.074263 : looking for messages on channels
  7.074270 : SafeState: back to waiting, triggering SafeStateAgain
  7.326184 : raw key input: "^M"
  7.326248 : SafeState: reset: key typed
  7.328328 : Exiting...
  7.340434 : ui_delay(1)
  7.341889 : ui_delay(1)
  7.343105 : ui_delay(1)
  7.344451 : ui_delay(1)
  7.345689 : ui_delay(1)
  7.346897 : ui_delay(1)
  7.348191 : ui_delay(1)
  7.349376 : ui_delay(1)
  7.350578 : ui_delay(1)
  7.352816 : closing channel log in the child process
  7.352995 : closing logfile /tmp/logfile
  7.368496 : raw terminal output: "^[]2;[No Name] - VIM^G"
  7.368646 : raw terminal output: "^[[?1006l^[[?1002l^[[?2004l"
  7.368662 : raw terminal output: "^[]2;xterm^G"
  7.368702 : raw terminal output: "^[[33;1H^[[K^[[33;1H^[[?1004l^[[?2004l^[[?1l^[>"

Notice that the pattern [< is present on these 2 lines:
4.524921 : raw key input: "^[[<0;57;18M"
4.591695 : raw key input: "^[[<0;57;18m"

^[[ is CSI (Control Sequence Introducer).
0 is the encoded button value (here a left-click).
57 and 18 are the mouse ordinates.
The final m means that the button was released, while a final M means that the button was pressed.

Thanks for the detailed steps. Some update, it happens both outside and inside tmux when t_fe & t_fd are manually set in .vimrc. Here are the files:
inside_tmux.txt
outside_tmux.txt
Here's what I had in .vimrc. I removed the test for terminal because you asked to manually set it in .vimrc in both cases (outside tmux I use xterm-256color, and inside I use tmux-256color)
set mouse=a " Enable mouse for all modes, including terminal!
if !has('nvim')
    set ttymouse=sgr
    "if &term == 'tmux-256color' && &t_fe == ''
        let &t_fe = "\<Esc>[?1004h"
        let &t_fd = "\<Esc>[?1004l"
    "endif
endif

Given the files are short, I am attaching it here too:
inside_tmux.txt:
vim9script

   # Terminal codes

set t_AU=              \ t_da=              \ t_le=            \ t_RT=              \ t_te=     \ t_WP=
set t_AL=[%p1%dL     \ t_db=              \ t_mb=         \ t_RV=              \ t_TE=              \ t_WS=
set t_al=          \ t_DL=[%p1%dM     \ t_md=         \ t_Sb=              \ t_ti=     \ t_xn=y
set t_bc=              \ t_dl=          \ t_me=         \ t_SC=              \ t_TI=              \ t_xs=
set t_BE=              \ t_EC=              \ t_mr=         \ t_se=        \ t_Ts=              \ t_ZH=
set t_BD=              \ t_EI=[2\ q        \ t_ms=y             \ t_Sf=              \ t_ts=              \ t_ZR=
set t_cd=          \ t_fs=              \ t_nd=          \ t_SH=              \ t_u7=         \ t_8f=
set t_ce=          \ t_fd=     \ t_op=     \ t_SI=[5\ q        \ t_ue=        \ t_8b=
set t_cl=     \ t_fe=     \ t_RF=              \ t_Si=              \ t_us=         \ t_8u=
set t_Ce=              \ t_GP=              \ t_RB=              \ t_so=         \ t_ut=y
set t_Co=256           \ t_IE=              \ t_RC=              \ t_SR=[4\ q        \ t_vb=
set t_CS=              \ t_IS=              \ t_RI=[%p1%dC     \ t_sr=M           \ t_vi=
set t_Cs=              \ t_ke=>     \ t_Ri=              \ t_ST=              \ t_VS=
set t_CV=              \ t_ks==     \ t_RS=              \ t_Te=              \ t_vs=
set t_AB=[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m
set t_AF=[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m
set t_cm=[%i%p1%d;%p2%dH
set t_cs=[%i%p1%d;%p2%dr
set t_ve=

   # Terminal keys

set t_ #2 <S-Home>       t_k2 <F2>        OQ      t_k; <F10>       [21~    t_kh <Home>      [1~
set t_ #4 <S-Left>       t_k3 <F3>        OR      t_kB <S-Tab>           t_kl <Left>      OD
set t_%i <S-Right>      t_k4 <F4>        OS      t_kD <Del>       [3~     t_kr <Right>     OC
set t_*7 <S-End>        t_k5 <F5>        [15~    t_kI <Insert>    [2~     t_ku <Up>        OA
set t_@7 <End>       [4~     t_k6 <F6>        [17~    t_kN <PageDown>  [6~          <SgrMouse>  [<*M
set t_F1 <F11>       [23~    t_k7 <F7>        [18~    t_kP <PageUp>    [5~          <Mouse>
set t_F2 <F12>       [24~    t_k8 <F8>        [19~    t_kb <BS>                     <FocusGained>
set t_k1 <F1>        OP      t_k9 <F9>        [20~    t_kd <Down>      OB           <FocusLost>

set <SgrMouseRelease> [<*m

outside_tmux.txt:
vim9script

   # Terminal codes

set t_AU=[58;5;%dm   \ t_cd=          \ t_Cs=              \ t_EC=            \ t_IE=            \ t_md=         \ t_RF=]10;?     \ t_RT=      \ t_SH=[%p1%d\ q    \ t_ST=      \ t_Ts=         \ t_vb=              \ t_xs=
set t_AL=[%p1%dL     \ t_ce=          \ t_CV=              \ t_EI=[2\ q        \ t_IS=]1;         \ t_me=          \ t_RB=]11;?     \ t_RV=[>c         \ t_SI=[5\ q        \ t_Te=        \ t_ts=]2;         \ t_ve=       \ t_ZH=
set t_al=          \ t_cl=     \ t_da=              \ t_fs=            \ t_ke=>     \ t_mr=         \ t_RC=[?12$p      \ t_Sb=              \ t_Si=      \ t_te=     \ t_u7=         \ t_vi=       \ t_ZR=
set t_bc=              \ t_Ce=              \ t_db=              \ t_fd=     \ t_ks==     \ t_ms=y             \ t_RI=[%p1%dC     \ t_SC=]12;        \ t_so=         \ t_TE=[>4;m       \ t_ue=          \ t_VS=       \ t_8u=
set t_BE=     \ t_Co=256           \ t_DL=[%p1%dM     \ t_fe=     \ t_le=            \ t_nd=          \ t_Ri=      \ t_se=        \ t_SR=[4\ q        \ t_ti=     \ t_us=         \ t_vs=
set t_BD=     \ t_CS=              \ t_dl=          \ t_GP=        \ t_mb=         \ t_op=     \ t_RS=P$q\ q\    \ t_Sf=              \ t_sr=M           \ t_TI=[>4;2m      \ t_ut=y             \ t_xn=y
set t_AB=[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m
set t_AF=[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m
set t_cm=[%i%p1%d;%p2%dH
set t_cs=[%i%p1%d;%p2%dr
set t_WP=[3;%p1%d;%p2%dt
set t_WS=[8;%p1%d;%p2%dt
set t_8f=[38;2;%lu;%lu;%lum
set t_8b=[48;2;%lu;%lu;%lum

   # Terminal keys

set t_ #2 <S-Home>       t_F2 <F12>       [24;*~  t_KB <kPoint>    O*n     t_KJ <k7>        O*w     t_k4 <F4>        [14;*~  t_kD <Del>       [3~     t_kr <Right>     O*C          <xEnd>      O*F          <kDel>      [3;*~
set t_ #4 <S-Left>       t_K1 <kHome>     [1;*~   t_KC <k0>        O*p     t_KK <k8>        O*x     t_k5 <F5>        [15;*~  t_kI <Insert>    [2;*~   t_ku <Up>        O*A          <zEnd>      [8;*~        <FocusGained>
set t_%1 <Help>      [28;*~  t_K4 <kEnd>      [4;*~   t_KD <k1>        O*q     t_KL <k9>        O*y     t_k6 <F6>        [17;*~  t_kN <PageDown>  [6;*~        <SgrMouse>  [<*M         <xHome>     O*H          <FocusLost>
set t_%i <S-Right>      t_K6 <kPlus>     O*k     t_KE <k2>        O*r     t_PE <PasteEnd>  [201~   t_k7 <F7>        [18;*~  t_kP <PageUp>    [5;*~        <Mouse>                <zHome>     [7;*~
set t_&8 <Undo>      [26;*~  t_K7 <kMinus>    O*m     t_KF <k3>        O*s     t_PS <PasteStart> [200~  t_k8 <F8>        [19;*~  t_kb <BS>                     <xF1>       O*P          <xUp>       [@;*A
set t_*7 <S-End>        t_K8 <kDivide>   O*o     t_KG <k4>        O*t     t_k1 <F1>        [11;*~  t_k9 <F9>        [20;*~  t_kd <Down>      O*B          <xF2>       O*Q          <xDown>     [@;*B
set t_@7 <End>       [1;*F   t_K9 <kMultiply> O*j     t_KH <k5>        O*u     t_k2 <F2>        [12;*~  t_k; <F10>       [21;*~  t_kh <Home>      [1;*H        <xF3>       O*R          <xLeft>     [@;*D
set t_F1 <F11>       [23;*~  t_KA <kEnter>    O*M     t_KI <k6>        O*v     t_k3 <F3>        [13;*~  t_kB <S-Tab>           t_kl <Left>      O*D          <xF4>       O*S          <xRight>    [@;*C

set <SgrMouseRelease> [<*m

Also, unlike what you said, the options don't seem to get printed one per line, unless I am missing something...

Sorry, I have health issues, so I don't have much time at the moment.  However:

Also, unlike what you said, the options don't seem to get printed one per line by :DebugTerminfo, unless I am missing something...

That's weird.  It works for me with and without config; I don't know why it fails in your case.  I'll have to think about it later.

Update: There could be something off with my terminfo. Check this out for instance: andmarti1424/sc-im#604 (comment)

Yes, in the linked thread, this comment seems relevant:

There's more than one xterm mouse-protocol. The one you're using is the older one, which is limited to 224x224. Here's an output from infocmp showing alacritty's version versus ncurses (ncurses on the left):

That could explain your issue.  If your terminal uses an old encoding which is limited to 224 columns and you click beyond the 224th column, Vim will probably receive an escape sequence which it doesn't understand.  You might need to update/fix the terminfo entry for the xterm terminal, or whatever $TERM you're actually using.
Here is how to update the whole database:
curl -LO http://invisible-island.net/datafiles/current/terminfo.src.gz
gunzip terminfo.src.gz
tic -sx terminfo.src

This link might give a little more info.

authors: lacygoill liskin reportaman


text:
Vim9: FuncUndefined event is not triggered when the function is called in a function

Describe the bug
In Vim9 script, FuncUndefined event is not triggered when the function is called in a function.
To Reproduce
Run this shell command:
vim -Nu NONE -S <(cat <<'EOF'
  vim9script
  autocmd FuncUndefined * echo 'FuncUndefined triggered.'
  def Foo()
    Bar()
  enddef
  Foo()
EOF
)

FuncUndefined event is not triggered when Bar is called, so the message "FuncUndefined triggered." doesn't appear.
Expected behavior
FuncUndefined event is triggered when Bar is called and the message "FuncUndefined triggered." appears.
Screenshots
-
Environment (please complete the following information):

Vim version: 8.2 with patches 1-2146
OS: Amazon Linux release 2 / CentOS Linux release 7.7.1908 / macOS 10.15.7
Terminal: tmux in iTerm2

Additional context
Vim8 script is OK. And top-level calling is OK even if in Vim9 script.
Vim8 script:
vim -Nu NONE -S <(cat <<'EOF'
  autocmd FuncUndefined * echo 'FuncUndefined triggered.'
  function Foo()
    call Bar()
  endfunction
  call Foo()
EOF
)

Vim9 script but top-level calling:
vim -Nu NONE -S <(cat <<'EOF'
  vim9script
  autocmd FuncUndefined * echo 'FuncUndefined triggered.'
  Foo()
EOF
)

FuncUndefined event is triggered and the message "FuncUndefined triggered." appears when running these shell scripts.

This is an old mechanism I think we should not carry over to Vim9 script.
You can use an autoload function, as mentioned at the help for FuncUndefined.
Or you can import the function, that is not only when it's used though.
I'll add a remark at the help for FuncUndefined.

Thanks for the reply.
I would be happy if FuncUndefined event was supported in Vim9 script because it is used for dein.vim's lazy loading feature, which can add plugins' runtimepaths when plugins' functions are called. But I'll try another way.
Thank you for all your development. Best regards.

Thanks for the reply.
I would be happy if FuncUndefined event was supported in Vim9 script
because it is used for
dein.vim's lazy loading feature,
which can add plugins' runtimepaths when plugins' functions are
called. But I'll try another way.

The problem is that if we allow for undefined functions in a :def
function we can't give good error messages at compile time.
A workaround is to use a legacy function and call it from the :def
function.  That is a bit of a hack, but since this would be rarely
needed I consider that a valid solution.
def SomeFunc()
   # this can be found at compile time
   LoadOnDemand()
enddef

func LoadOnDemand()
   " this may trigger FuncUndefined
   call UnknownFunc()
endfunc

defcompile

--
Your company is doomed if your primary product is overhead transparencies.
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Thank you for your kind explanations and an advice of workaround. I didn't have the workaround idea.
I updated my Vim9 scripts. And now they don't depend on FuncUndefined event. I wrap a plugin's function and manually add its runtimepath if needed.
# Case 1: in my vimrc
def MyWrapperFunction()
  if !dein#is_sourced("some-plugin")
    dein#source("some-plugin")
  endif

  SomePluginsOriginalFunction()
enddef

# Case 2: in autoload/my/wrapper.vim
if !dein#is_sourced("some-plugin")
  dein#source("some-plugin")
endif

def my#wrapper#function()
  SomePluginsOriginalFunction()
enddef

I'll consider your advice if I encounter a similar situation. Thank you very much!!

source: gharchive/issue

repo: vim/vim

license: Vim

license_type: permissive

license_source: github-api


text:
Add a option set callback function variable to the vimoption table

Move the callback function for options that take no arguments to the vimoption table.  In a following
PR, move option callback functions will be moved.

Yegappan wrote:

Move the callback function for options that take no arguments to the
vimoption table.  In a following
PR, move option callback functions will be moved.

Thanks for doing this.  Getting rid of the long chain of "else if" is a
nice improvement.
Several functions that are not yet in the array take arguments.  Having
"opt_did_set_cb_T" take an argument that is a struct would be best.  Not
only makes this possible to pass arguments such as "opt_flags",
"opt_idx", "oldval" that some functions will need, it will also allow
for similar options to be handled by one function.  Using a struct
avoids having to change all the called functions when we add another
argument.
--
I wish there was a knob on the TV to turn up the intelligence.
There's a knob called "brightness", but it doesn't seem to work.
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

source: gharchive/pull-request

authors: brammool yegappan


text:
fix: bash ver check

// i have no macos and windows machines, but try this one, perhaps help the test work through.

Well,

it's an array, so you need to use [0] to check the major version number
I would keep the [[ since it's clear this is using bash here anyhow.

but happy to keep the default value  substitution

the major version number

seems it default was major,
and to be more compatible and it is scripting actually.
// e.g against to dash, and no req strict type checking here.

and to be more compatible and it is scripting actually.

But it is not. It only goes into that part, if the shell ends with bash. So you don't need to worry about bashism

goes into that part, if the shell ends with bash. So you don't need to worry about bashism

ok, but this made it work even it goes wrong, or i cannot image other various cases, maybe there.
--
shane.xb.qian

don't understand. What exactly do you think can go wrong?

    if (shell_style == STYLE_ECHO)
    {
       if (strstr((char *)gettail(p_sh), "bash") != NULL)
	    shell_style = STYLE_GLOBSTAR;

currently it is relying on p_sh (which is 'shell') set correctly and shell_style check correctly, or someone did not link /bin/sh to something else, this pr make it at least not err at checking bash ver.
// maybe a bit extreme, but tiny change seems better.

yes exactly, we only run that part of the code, if the users shell option is set to bash. So I am still not sure what problem you are trying to fix.
I would be okay with this patch however:
diff --git a/src/os_unix.c b/src/os_unix.c
index c5a54e419..cebcdc1dc 100644
--- a/src/os_unix.c
+++ b/src/os_unix.c
@@ -6711,7 +6711,7 @@ mch_expand_wildcards(
                // vimglob() function to define for Posix shell
     static char *sh_vimglob_func = "vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >";
                // vimglob() function with globstar setting enabled, only for bash >= 4.X
-    static char *sh_globstar_opt = "[[ ${BASH_VERSINFO[0]} -ge 4 ]] && shopt -s globstar; ";
+    static char *sh_globstar_opt = "[[ ${BASH_VERSINFO[0]:-0} -ge 4 ]] && shopt -s globstar; ";

     *num_file = 0;     // default: no files found
     *file = NULL;

I'd like to keep the [[  and the [0], because this part will only be run by a bash shell anyhow and it is clear from the code we are trying to access an Bash array variable

not sure what problem you are trying to fix.

trying to kill any chance (wish) it was not bash or not right bash.

yes, but that shouldn't happen

um, i wish so, but just to make sure even it happened would not impact this bash ver check.
// i know it is a bit extreme. so if you felt not like or not worthy to merge, i am ok to pull back.

i know it is a bit extreme. so if you felt not like or not worthy to merge, i am ok to pull back.

please make the adjustments I have mentioned above a few times

i know it is a bit extreme. so if you felt not like or not worthy to merge, i am ok to pull back.

please make the adjustments I have mentioned above a few times

that adjustment i think should be not required if your assumption it really was and right ver was bash.

authors: Shane-XB-Qian chrisbra


text:
Makefile for running indent tests on OS Windows.

Problem: On OS Windows there is no makefile for testing indents.
Solution: Add Make_mvc.mak to the "runtime/indent" directory.
Also:
"indent/testdir/runtest.vim" — bit optimized.
"indent/Makefile" — added rules .PHONY and .SUFFIXES
"Filelist" — added the file "runtime/indent/Make_mvc.mak". Some files have been moved to more logically appropriate variables (macros).

Can you please next time make sure, to not add un-related changes to it? I find it hard to review, if you change all the commens only slightly.

Can you please next time make sure, to not add un-related changes to it? I find it hard to review, if you change all the commens only slightly.

I understood. I'm sorry. I will roll back these made changes to the "Filelist" except for "Make_mvc.mak". And we will discuss these changes in another PR, if necessary. Ok?

no problem. Leave the PR as is. Just for the next time please :)

authors: RestorerZ chrisbra


text:
Adding RelLineAbove and RelLineBelow highlight groups

I wanted my relative line numbers to be colored differently above and below the
cursor line.  I believe a highlight group applied conditionally is the correct
way to achieve this.
This is my first foray in to the vim sources, so please let me know if I missed
the mark or could do things differently/better.

I think it is easier for Bram to apply if you squash it into a single commit, so there is only one single patch. BTW: could you please provide a screenshot?

@chrisbra Thanks, I have squashed everything in to one commit, which hopefully should by typo free.  Here is a screenshot of the syntax group in action.  Please ignore my tortured and hacked .vimrc.  The lines used to change the colors are highlighted in purple.

Thanks. This looks useful. Can you please also add some documentation at syntax.txt below  :h highlight-groups

@chrisbra I have added some documentation for the new highlight groups.  Thanks!

@chrisbra Is there any thing else that is needed?  Github tells me on conflicts have crept up since I authored the PR.  Thanks!

🎉

authors: Phrohdoh chrisbra shaunbrady


text:
Make Test_exit_error_reading_input() actually fail without patch 8.2.4438

VimLeave is executed before free_all_mem(), so a segfault in free_all_mem() doesn't affect it. The correct way seems to be checking v:shell_error instead.
Maybe the cmdwin_type = 0 can be moved to free_all_mem()?

This still doesn't pass ASAN. I'll add another commit to move the cmdwin_type = 0 to free_all_mem(), as that should cover more edge cases.

This still doesn't pass ASAN. I'll try to move it to win_feee_all() then.

Hmm, this still doesn't pass ASAN...

Maybe this is not the proper way to close a cmdwin?

OK, this makes it work on MS-Windows.  But that ASAN error remains.
When I run the script under gdb I do see the memory is cleaned up.

With cmdwin_type = 0 removed this fails correctly on Linux and macOS:
Test_exit_error_reading_input line 8: Expected 1 but got 139

With almost the some code this still fails on MS-Windows. How did it pass previously then?

authors: brammool zeertzjq


text:
Rename internal packages

Rename internal packages to "vimeda" so that go get can resolve them
Update readme

Closing, will use the replace directive to use the correct fork.

repo: vimeda/goengine

license: MIT


text:
Add gitignore file to not track node_modules

This PR fixes #17

Closing as already there is another PR

repo: vinitshahdeo/Quotter


text:
Create a phone auth route

Is your feature request related to a problem? Please describe.
Some features/routes need the user to be verified.
Describe the solution you'd like
Implement firebase phone auth.
Additional context

Firebase Auth Docs
Medium Article 1

Note: Create PR to feature/backend-node

@ArpitKotecha May I work on this. I'm a GSSoC participant and would like to contribute to this preoject

@ArpitKotecha May I work on this?
I'm a GSSoC participant and would like to contribute to this project

@abhu-A-J Yeah sure.
Try to complete the task by tuesday.

authors: ArpitKotecha abhu-A-J

repo: vinitshahdeo/Water-Monitoring-System


text:
WIP: starter code for manual approval flow

no tests yet, expect failures
the general idea is to split out soft failures, and if all errors are in that bucket, save the batch change.
have not yet actually assigned any errors as soft or decided what to save for those on the single change (use a list of error codes? save something in system message? something else?). These will all be followup

closing, this work has been pulled into other PRs

repo: vinyldns/vinyldns


text:
VC-4227: Add msg create wallet.

Description
Closes: #XXXX

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[ ] included the correct type prefix in the PR title
[ ] added ! to the type prefix if API or client breaking change
[ ] targeted the correct branch
[ ] provided a link to the relevant issue or specification
[ ] added a changelog entry to CHANGELOG.md
[ ] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[ ] reviewed "Files changed" and left comments if necessary
[ ] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed ! in the type prefix if API or client breaking change
[ ] confirmed all author checklist items have been addressed
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

LGTM

LGTM

authors: Chuiko-GIT alex-bodnar vasylNaumenko

repo: vipcoin-gold/bdjuno


text:
Support for 'VssOption'

Is your feature request related to a problem? Please describe.
VM's running databases like MSSQL-Server have issues when the qemu-agent is using full VSS freezing.
Reference: Proxmox Backups breaking SQL-Backups
Grepping over the whole repository did not show any references to 'VssOptions' (see below)
Describe the solution you'd like
Implement the VssOption setting as seen in these qemu commits:

qemu VSS backup type
qemu installer VssOption

Describe alternatives you've considered
Disabling qemu VSS handling

Hi @NiceRath,
VssOption is a setting of QEMU guest agent. This repository does not edit the QEMU guest agent.  https://github.com/virtio-win/virtio-win-guest-tools-installer contains an installer but it also does not touch the QEMU guest agent, it just gets compiled qga.msi and runs it as is.
Please describe what you mean by "Support for 'VssOption'" in this repository.

Greetings!
@kostyanf14 Thank you for the clarification.
If I understand it correctly the installers listed at https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/ are compiled like that, am I correct?
So in the next virtio-win version (the last one seems to be from Jan 2023) this option should be available?
I understand if that information is not known to you - but it would be important to know for users that have these issues with their virtio-win installation.

@NiceRath

So in the next virtio-win version (the last one seems to be from Jan 2023) this option should be available? (as the option as commited at Mar 2023 to qemu)

Yes, in the next release, this option should be available.

@kostyanf14 Thank you for the helpful information!
Is there any known release-schedule for the virtio-win installers? (6 months, 1 year)
I haven't seen any mentioned in the 'virtio-win-guest-tools-installer' repository readme.
Just so the affected users know how long they will approximately need to wait.
Have a nice day!

Hi @vrozenfe,
Can you please answer about "release-schedule for the virtio-win installers"?

Seems there was a new release in the meantime.

Technically we can publish a new stable virtio-win package every 6 months approximately.
This schedule is mostly related to our internal virtio-win package releasing work flow.
Best regards,
Vadim.

Thank you for the information.
Have a nice day!

authors: NiceRath kostyanf14 vrozenfe

repo: virtio-win/kvm-guest-drivers-windows

license_source: bigquery


text:
added translation to app.html

added google translate to top of app.html
Note: app.html still has the old footer

can you make button shorter?

manually pushed. next time make sure to:

don't commit useless files like .DS_store  (it happens if you do git add . which is very dangerous, its better to use git add -p
in your ~/.gitconfig file update your email address to be @users.noreply.github.com

make sure the tabs/spacing of new code is correct


text:
NetworkServer/NetworkClient: add/remove from transport events instead of overwriting them. This allows addons to hook into Transport OnConnect/OnData/etc.

prepare for networkstatistics.
cleaner.
allows addons to hook into transport events too.
IMPORTANT: need to test with all transports.
some might need to invoke events lazily so they always use the 'current' events.

kcp?
telepathy?
libuv?
litenet?
ignorance?
websockets?
epic?

closing. not for lts.

closing. not for lts.


text:
Uncaught TypeError: undefined is not a function

I run 112 tests, all tests using superagent. Sometimes happened this message for random api calls.
Uncaught TypeError: undefined is not a function
at Socket.socketOnEnd [as onend] (http.js:1572:9)
at _stream_readable.js:943:16

Why closed?

I'm guessing because you didn't provide any information about your issue.
If you want to help, reduce your code to the minimum amount that still produces an error. Then post that code, the command you used to run it, the version of superagent you used, and the complete stacktrace.

authors: ajnisbet crypti

repo: visionmedia/superagent

license: mit


text:
how can i get the base64 of web image using superage

the code:
superagent.get('http://image.jpg')             .end(function (err, res) {                 console.log(res);             })
i want transfer response body to base64 using Buffer(response.body).toString('base64')
but the response body is null
i transfer response.text to base as Buffer(response.text).toString('base64')
but it is not right

We don't have buffer output yet: #871

will add the feature?

Sorry, correction. We do have buffer output if Content-Type of the response is image/-something. In that case response.body will be a buffer.
If MIME type is not right, it gets complicated: #950

Thanks, I Have Solve The Problem By Other Way, Not Get The base64 Of Image

authors: pornel zxyah


text:
ensure query string is appended when doing stream.pipe(request)

Query string is missing from request path when using stream.pipe(request)
node repl test case:
var express = require('express'), fs = require('fs'), request = require('superagent');
express().put('/', function(req,res){ console.log("url=" + req.url) }).listen(3006);
fs.createReadStream('README.md').pipe(request.put('http://localhost:3006/?foo=bar'));

expected output: url=/?foo=bar
actual output: url=/
The problem: the query is appended to req.path in end() which is run after the
headers have been sent when the request is treated as a writable stream, so the
path sent to the server is always missing the query.
My attempt at a fix: the first time write() is called, set a flag indicating
that the request is being treated as a writable stream.  If this is the case we
need to append the query string to req.path before the first write() causes
the headers to be sent.
I'm not super familiar with this library, but this seemed like decent
fix that would solve the problem while keeping the existing behavior of
passing any query-related error to the end() callback, for the more common
case of calling req.end() rather than stream.pipe(req) to send the request.

Seems reasonable to me, but also probably worth some detailed review. @pornel @olalonde thoughts?

It's an interesting bug, and potentially very annoying gotcha, so we definitely should fix it. I'm not familiar with the code enough myself to be sure what would be an ideal solution.
However, flags like that are a shared mutable state, and code that modifies query string is now duplicated. So while this fixes this particular bug, I'm afraid it could be easily broken later (e.g. if qs serialization is updated in end() but not in write()).

OK, it's better to fix this. We'll worry about a stateful property later.

authors: focusaurus keeth pornel


text:
unchecking all checklist options doesn't fire

I'm not 100% convinced this is a bug because it works on your demo page, but I had nowhere else to ask.
I have a checklist with two items and editable is set on the textarea.  I have another checklist with three items, also using a textarea.  The one with three items has some pretty long items, so that's why I went with textarea, if that makes a difference.
When I click on the textarea, the checklist popup comes up correctly.  When I uncheck all items and click OK, nothing happens.  If I make any other change and click OK, it correctly updates the text area.  Now if I go back and uncheck everything, I can save the change.  I tried putting breakpoints in success and error, but neither one fire. Just validate.  The way I worked around it was to put a check in validate to see if the new value='', and if so then set the textarea value to ''.  Here's the code for one of them:
$('.editable-source').editable({
    type        : 'checklist',
    title       : 'Select One',
    emptytext   : '',
    source      : [
                    {value:'ABC', text:'ABC'},
                    {value:'123', text:'123'}
                  ],
    success     : function(response, newValue){
      $(this).val(newValue.join(" "));
    },
    validate    : function(value) {
      if (value ==''){
        $(this).val('');
      }
    }
  });

Any thoughts on what might be happening?

Just noticed something that may help.  ABC is checked by default.  I click to open the popup.  I uncheck ABC and click OK.  My validate correctly blanks out the textarea, and if I click save changes, the change is saved correctly.  But, before I save, if I click on the textarea again ABC is checked in the popup.
In the javascript console $('#source').val()=''.  But inspecting the textarea shows "ABC".  If I pop open the editor again and check both ABC and 123, then $('#source').val()='ABC 123', with the space separator  from newValue.join(" ").  But if I inspect the element again, I get"ABC123".  So it is like unchecking all the checkboxes doesn't clear out the value if that's the first change you make.

repo: vitalets/x-editable


text:
Support React 18?

Whether consider support React 18?

Yes!

Is it coming soon? I'm using vite-plugin-react-pages to custom my starter-vite-react-library[WIP], and it's not easy to integrate with PageStrategy as my mind 😂

What problem do you encounter with PageStrategy ? It is related to React 18?

Is it coming soon?

I expect one week of work to do the migration (React Router 6 + React 18).

What problem do you encounter with PageStrategy ? It is related to React 18?

No, just react-dom warning in console. Convention over configuration, maybe provide a official PageStrategy auto load page data is better. like: https://d.umijs.org/guide/basic

What problem do you encounter with PageStrategy ? It is related to React 18?

Convention over configuration, maybe provide a official PageStrategy auto load page data is better. like: https://d.umijs.org/guide/basic

Agreed. Currently the default "convention" is only suitable for app. I should provide a PageStrategy that can be reused by library developer. dumi is indeed a great project to learn from.

Maybe I can do something for the repo, is there a roadmap?

That would be greate! Contributions are very welcome. You can start with writing (or improve) playground and template (demos) to satisfy specific needs of users.
For example, your library template would be a great demo for users that want to create a library. Currently our library template is not very practical because it doesn't include build scripts to build the library (it only have scripts to run and build demo). The document site in the demo is also not very practical.
We need to create more practical and complex demos (we can learn from docusaurus, dumi, and storybook.js). By doing that, we can know what features are valuable for users, and implement them in the theme-doc or vite-pages-core! Hopefully, you will be familiar with this repo by then, and be able to implement those features!

is there a roadmap?

I use issues to track TODO (clear feature demand) . I have some vague ideas in my mind (such as more powerful demo rendering like storybook.js, better TS interface info extraction), but they are not clearly designed yet.

Great, start with my lib template is good idea, but there is a question, how to integrate with my template, I will improve it continuously. By init script or others?

Great, start with my lib template is good idea, but there is a question, how to integrate with my template, I will improve it continuously. By init script or others?

You can continue improve your template in your repo. And when it is ready, we can add a build script before publishing create-vite-pages to pull your template into this package.

So where to place pull-template-lib script? I'm not understand.

In the package.json of create-vite-pages: https://github.com/vitejs/vite-plugin-react-pages/issues/create-vite-pages
I will run the script before publishing the package.

I just updated the url in the previous comment. Sorry for the broken url 😂

Got it. I'm working on it now, the aim today is working as my expected routes 😂

@csr632 Is it updated?

@csr632 Is it updated?

Sorry for the delay! I haven't implement it because of lack of time. But since somebody have request for it, I will put more priority on it. I will implement this in a week.

@csr632 are waiting哈哈😂

@csr632 How long will it take for React Router 6 + React 18 to release a version，

@csr632 How long will it take for React Router 6 + React 18 to release a version，

I am working on a version that:

upgrade react to 18.x (will fix this issue)
upgrade react-router to 6.x (will fix https://github.com/vitejs/vite-plugin-react-pages/issues/72)
upgrade mdx to 2.x (will fix https://github.com/vitejs/vite-plugin-react-pages/issues/69)

And it will be a new major version. I will release an alpha version this week.

@csr632 Thanks for your hard work，If it is successful, please tell me, I will always pay attention

A new alfa version is published, check it out:
https://github.com/vitejs/vite-plugin-react-pages/pull/96

authors: Evansy csr632 qiaogaolong yunsii

repo: vitejs/vite-plugin-react-pages


text:
Break up the spatialLayers coordination types

User story
The spatialLayers coordination type should be broken into multiple coordination types. At least for T and Z dimensions.
In this demo I cannot coordinate the two images along the time axis while using different channel setting, because the spatialLayers coordination type currently includes both dimension selections and channel settings in the same array/object
Preferred solution
We should break out the T and Z dimensions into global coordination types such as targetT and targetZ. We should not name these coordination types with the prefix spatial (as we do with spatialTargetX/spatialTargetY) because we may eventually want to see different scatterplot / heatmap data based on the temporal axis as well.
Note: this would be a breaking change for existing view configs, but we would be able to update current view configs automatically with an upgrade function and a new view config schema version

Proposal
Goes along with #1128.
Background / motivation
Along with the spatialRasterLayer coordination type, we also
currently have the two coordination types spatialCellsLayer and spatialMoleculesLayer.
In #1209 I wanted to use obs to represent observations, where the value for obsType might be cell or molecule.
Then we would need to convert spatialCellsLayer and spatialMoleculesLayer to spatialObsLayer but we currently render cells and molecules differently (cell segmentation polygons/bitmasks and scatterplot/pointcloud, respectively).
Renaming current coordination types
Instead, I propose renaming these coordination types using the visualization/rendering terminology rather than the data/entity terminology:

spatialRasterLayer (current name)
spatialCellsLayer -> spatialSegmentationLayer
spatialMoleculesLayer -> spatialPointLayer

Breaking up current JSON object coordination values
Then, we can break up the values which are currently large/nested JSON objects

Example of current JSON object values
coordinationSpace: {
  spatialRasterLayer: {
    A: [
      {
      "type": "raster",
      "index": 0,
      "visible": true,
      "colormap": null,
      "opacity": 1,
      "domainType": "Min/Max",
      "transparentColor": null,
      "renderingMode": "Additive",
      "use3d": false,
      "channels": [{
        "selection": {
          "c": 0,
          "z": 0,
          "t": 0
        },
        "color": [255, 0, 0],
        "visible": true,
        "slider": [0, 255]
      }, {
        "selection": {
          "c": 1,
          "z": 0,
          "t": 0
        },
        "color": [0, 255, 0],
        "visible": true,
        "slider": [0, 255]
      }, {
        "selection": {
          "c": 2,
          "z": 0,
          "t": 0
        },
        "color": [0, 0, 255],
        "visible": true,
        "slider": [0, 255]
      }]
    }, {
      "type": "raster",
      "index": 1,
      "visible": true,
      "colormap": null,
      "opacity": 1,
      "domainType": "Min/Max",
      "transparentColor": [0, 0, 0],
      "renderingMode": "Additive",
      "use3d": false,
      "channels": [{
        "selection": {
          "c": 0,
          "z": 0,
          "t": 0
        },
        "color": [0, 0, 255],
        "visible": true,
        "slider": [1024, 23753]
      }, {
        "selection": {
          "c": 1,
          "z": 0,
          "t": 0
        },
        "color": [0, 255, 0],
        "visible": true,
        "slider": [373, 9848]
      }, {
        "selection": {
          "c": 2,
          "z": 0,
          "t": 0
        },
        "color": [255, 0, 255],
        "visible": true,
        "slider": [326, 14084]
      }]
    }, {
      "type": "raster",
      "index": 2,
      "visible": true,
      "colormap": null,
      "opacity": 1,
      "domainType": "Min/Max",
      "transparentColor": [0, 0, 0],
      "renderingMode": "Additive",
      "use3d": false,
      "channels": [{
        "selection": {
          "c": 0,
          "z": 0,
          "t": 0
        },
        "color": [0, 0, 255],
        "visible": true,
        "slider": [0.7109375, 2817.15283203125]
      }, {
        "selection": {
          "c": 1,
          "z": 0,
          "t": 0
        },
        "color": [0, 255, 0],
        "visible": true,
        "slider": [7.094120025634766, 50509.515625]
      }, {
        "selection": {
          "c": 2,
          "z": 0,
          "t": 0
        },
        "color": [255, 0, 255],
        "visible": true,
        "slider": [0.5399665832519531, 1078.9984130859375]
      }, {
        "selection": {
          "c": 3,
          "z": 0,
          "t": 0
        },
        "color": [255, 255, 0],
        "visible": true,
        "slider": [0.28322410583496094, 1108.6363525390625]
      }],
      "modelMatrix": [20, 0, 0, 0, 0, 20, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1]
    }, {
      "type": "raster",
      "index": 3,
      "visible": true,
      "colormap": null,
      "opacity": 1,
      "domainType": "Min/Max",
      "transparentColor": [0, 0, 0],
      "renderingMode": "Additive",
      "use3d": false,
      "channels": [{
        "selection": {
          "c": 0,
          "z": 0,
          "t": 0
        },
        "color": [0, 0, 255],
        "visible": true,
        "slider": [1.335814118385315, 1839.003662109375]
      }, {
        "selection": {
          "c": 1,
          "z": 0,
          "t": 0
        },
        "color": [0, 255, 0],
        "visible": true,
        "slider": [4.591888427734375, 5142.390625]
      }, {
        "selection": {
          "c": 2,
          "z": 0,
          "t": 0
        },
        "color": [255, 0, 255],
        "visible": true,
        "slider": [0.2421875, 314.395751953125]
      }, {
        "selection": {
          "c": 3,
          "z": 0,
          "t": 0
        },
        "color": [255, 255, 0],
        "visible": true,
        "slider": [0.4366779327392578, 390.0624084472656]
      }],
      "modelMatrix": [20, 0, 0, 0, 0, 20, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1]
    }
    ]
  }
}

datasets: [
  {
    uid: "xyz",
    files: [
      {
        dataType: "raster",
        fileType: "raster.ome-tiff",
        options: {
          // TODO: switch from the current value in spatialRasterLayer[].transparentColor:
          // the image file contents OR the options array for an image should define this if it does not use the default.
          transparentColor: [0, 0, 0],
          // TODO: switch from the current value in spatialRasterLayer[].index:
          // for instance, maybe the mapping between spatialRasterLayer identifier and the image data is an index in OME-TIFFs.
          rasterLayerIndex: {
            PAS: 0,
            AF: 1,
          },
        }
      },
      {
        dataType: "raster",
        fileType: "raster.ome-ngff",
        options: {
          // TODO: switch from the current value in spatialRasterLayer[].transparentColor:
          // the image file contents OR the options array for an image should define this if it does not use the default.
          transparentColor: [0, 0, 0],
          // TODO: switch from the current value in spatialRasterLayer[].index:
          // for instance, maybe the mapping between spatialRasterLayer identifier and the image data is a path in OME-NGFFs.
          rasterLayerPath: {
            IMSPosMode: ["ims", "0"],
            IMSNegMode: ["ims", "1"],
          },
          bitmaskLayerPath: {
            cell: ["ims", "cell_segmentations"],
            nucleus: ["ims", "nuclear_segmentations"],
          },
        }
      }
    ]
  }
],
coordinationSpace: {
  obsType: {
    A: 'cell',
    B: 'molecule',
    C: 'nucleus',
  },
  spatialRasterLayer: {
    // TODO: switch from the current object to just a string identifier for each layer:
    // In automatic conversion, take those layer objects with type: "raster"
    PAS: 'PAS', // the image file contents OR the options array for an image should define the mapping between this string value and a particular image in the file (since some image files can contain multiple images).
    AF: 'AF',
    IMSPosMode: 'IMSPosMode',
    IMSNegMode: 'IMSNegMode',
  },
  spatialPointLayer: {
    // TODO: switch from the current object in spatialMoleculesLayer to just a string identifier for each layer:
    molecule: 'molecule',
  },
  spatialSegmentationLayer: {
    // TODO: switch from the current object in spatialRasterLayer to just a string identifier for each layer:
    // In automatic conversion, take those layer objects with type: "bitmask"
    cell: 'cell',
    nucleus: 'nucleus',
  },
  spatialRasterChannel: {
    // TODO: switch from the current object in spatialRasterLayer with "channels" array to just a string identifier for each channel:
    // In automatic conversion, take those layer objects with type: "raster"
    PAS_A: 'PAS_A',
    PAS_B: 'PAS_B',
    ...,
    IMSN_D: 'IMSN_D',
  },
  spatialTargetX: {
    ...
  },
  spatialTargetY: {
    ...
  },
  spatialTargetC: {
    // TODO: switch from the current value in spatialRasterLayer[].channels[].selection.c:
    // the image file contents OR the options array for an image should define the mapping if it does not use the default axis key (e.g., "c" for OME-NGFF)
    PAS_A: 0,
    PAS_B: 1,
    ...,
    IMSN_D: 3,
  },
  spatialTargetZ: {
    // TODO: switch from the current value in spatialRasterLayer[].channels[].selection.z:
    // the image file contents OR the options array for an image should define the mapping if it does not use the default axis key (e.g., "z" for OME-NGFF)
    A: 0,
  },
  spatialTargetT: {
    // TODO: switch from the current value in spatialRasterLayer[].channels[].selection.t:
    // the image file contents OR the options array for an image should define the mapping if it does not use the default axis key (e.g., "t" for OME-NGFF)
    A: 0,
  },
  spatialPointRadius: {
    // TODO: switch from the current value in spatialMoleculesLayer[].radius:
    molecule: 5,
  },
  spatialLayerVisible: {
    // TODO: switch from the current values in spatial_____Layer[].visible:
    PAS: true,
    AF: true,
    IMSPosMode: true,
    IMSNegMode: true,
    cell: true,
    nucleus: true,
    molecule: true
  },
  spatialRasterChannelVisible: {
    // TODO: switch from the current value in spatialRasterLayer[].channels[].visible:
    PAS_A: true,
    PAS_B: true,
    ...,
    IMSN_D: true,
  },
  spatialRasterColor: {
    // TODO: switch from the current value in spatialRasterLayer[].channels[].color:
    PAS_A: [255, 0, 0],
    PAS_B: [0, 255, 0],
    ...,
    IMSN_D: [0, 255, 255],
  },
  spatialRasterColormap: {
    // TODO: switch from the current value in spatialRasterLayer[].colormap:
    PAS: null,
    AF: null,
    IMSPosMode: null,
    IMSNegMode: null,
  },
  spatialRasterColormapRangeType: {
    // TODO: switch from the current value in spatialRasterLayer[].domainType:
    PAS: "Min/Max",
    AF: "Min/Max",
    IMSPosMode: "Min/Max",
    IMSNegMode: "Min/Max",
  },
  spatialRasterColormapRange: {
    // TODO: switch from the current value in spatialRasterLayer[].channels[].slider:
    PAS_A: [0, 255],
    PAS_B: [0, 255],
    ...,
    IMSN_D: [1024, 23753],
  },
  spatialRenderingMode: {
    // TODO: switch from the current value in spatialRasterLayer[].use3d:
    A: '2D',
  },
  spatialRasterVolumeRenderingMethod: {
    // TODO: switch from the current value in spatialRasterLayer[].renderingMode:
    A: 'Additive',
  },
  spatialLayerOpacity: {
    // TODO: switch from the current value in spatial_____Layer[].opacity:
    PAS: 1,
    AF: 1,
    IMSPosMode: 1,
    IMSNegMode: 1,
    cell: 1,
    nucleus: 1,
    molecule: 1,
  },
  spatialModelMatrix: {
    IMS: [20, 0, 0, 0, 0, 20, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1],
  },
},
layout: [
  {
    component: 'spatial',
    coordinationScopes: {
      // TODO: ensure that any coordinationScope value here that is an arrays has a key that is valid for coordinationScopesBy:
      // - dataset
      // - spatialRasterLayer
      // - spatialBitmaskLayer
      // - spatialPointLayer
      // - spatialRasterChannel
      dataset: 'A',
      spatialTargetX: 'A',
      spatialTargetY: 'A',
      spatialTargetT: 'A', // TODO: implement global T slider (move out of per-layer)
      spatialTargetZ: 'A', // TODO: implement global Z slider (move out of per-layer)
      spatialRenderingMode: 'A',  // if 3D, then will _currently_ render the first raster layer that has spatialLayerVisible: true.
      spatialRasterVolumeRenderingMethod: 'A',
      // TODO: ensure that the ordering of the spatialRasterLayer array
      spatialRasterLayer: ['PAS', 'AF', 'IMSPosMode', 'IMSNegMode'], // the ordering here will also dictate the render ordering
      spatialSegmentationLayer: ['cell', 'nucleus'], // the ordering here will also dictate the render ordering
      spatialPointLayer: ['molecule'],
    },
    coordinationScopesBy: {
      // TODO: need to check that all keys are coordination types that are valid for coordinationScopesBy OR a plugin coordination type:
      // one of:
      // - dataset
      // - spatialRasterLayer
      // - spatialBitmaskLayer
      // - spatialPointLayer
      // - spatialRasterChannel
      dataset: { },
      spatialRasterLayer: {
        // TODO: need to check that all keys of the value objects are valid spatialRasterLayer coordination values.
        // TODO: need to check that all keys are coordination types that are valid for per-spatialRasterLayer coordination OR a plugin coordination type:
        // one of:
        // - spatialLayerVisible
        // - spatialRasterColormap
        // - spatialRasterColormapRangeType
        // - spatialLayerOpacity
        // - spatialRasterChannel
        spatialLayerVisible: { PAS: 'PAS', AF: 'AF', IMSPosMode: 'IMSPosMode', IMSNegMode: 'IMSNegMode' },
        spatialRasterColormap: { PAS: 'PAS', AF: 'AF', IMSPosMode: 'IMSPosMode', IMSNegMode: 'IMSNegMode' },
        spatialRasterColormapRangeType: { PAS: 'PAS', AF: 'AF', IMSPosMode: 'IMSPosMode', IMSNegMode: 'IMSNegMode' },
        spatialLayerOpacity: { PAS: 'PAS', AF: 'AF', IMSPosMode: 'IMSPosMode', IMSNegMode: 'IMSNegMode' },
        spatialRasterChannel: {
          PAS: ['PAS_A', 'PAS_B', 'PAS_C', 'PAS_D'],
          AF: ['AF_A', 'AF_B', 'AF_C', 'AF_D'],
          IMSPosMode: ['IMFP_A', 'IMFP_B', 'IMFP_C', 'IMFP_D'],
          IMSNegMode: ['IMFN_A', 'IMFN_B', 'IMFN_C', 'IMFN_D'],
        },
        spatialModelMatrix: {
          IMSPosMode: 'IMS',
          IMSNegMode: 'IMS',
        }
      },
      spatialSegmentationLayer: {
        // TODO: need to check that all keys of the objects are valid spatialBitmaskLayer coordination values.
        // TODO: need to check that all coordination types are valid for per-spatialBitmaskLayer coordination:
        // one of:
        // - obsType
        // - spatialLayerVisible
        // - spatialLayerOpacity
        // - spatialRasterColormapRangeType
        // - spatialLayerOpacity
        // - spatialRasterChannel
        obsType: {
          cell: 'A',
          nucleus: 'C',
        },
        spatialLayerVisible: { cell: 'cell', nucleus: 'nucleus' },
        spatialLayerOpacity: { cell: 'cell', nucleus: 'nucleus' },
      },
      spatialPointLayer: {
        // TODO: need to check that all keys of the objects are valid spatialPointLayer coordination values.
        // TODO: need to check that all coordination types are valid for per-spatialPointLayer coordination:
        // one of:
        // - obsType
        // - spatialPointRadius
        // - spatialLayerVisible
        // - spatialLayerOpacity
        obsType: {
          molecule: 'B',
        },
        spatialPointRadius: { molecule: 'molecule' },
        spatialLayerVisible: { molecule: 'molecule' },
        spatialLayerOpacity: { molecule: 'molecule' },
      },
      spatialRasterChannel: {
        // TODO: need to check that all keys of the objects are valid spatialRasterChannel coordination values.
        // TODO: need to check that all coordination types are valid for per-spatialRasterChannel coordination:
        // one of:
        // - spatialTargetC
        // - spatialRasterChannelVisible
        // - spatialRasterColor
        // - spatialRasterColormapRange
        spatialTargetC: {
          PAS_A: 'PAS_A', PAS_B: 'PAS_B', PAS_C: 'PAS_C', PAS_D: 'PAS_D',
          AF_A: 'AF_A', AF_B: 'AF_B', ...
        },
        spatialRasterChannelVisible: {
          PAS_A: 'PAS_A', PAS_B: 'PAS_B', PAS_C: 'PAS_C', PAS_D: 'PAS_D',
          AF_A: 'AF_A', AF_B: 'AF_B', ...
        },
        spatialRasterColor: {
          PAS_A: 'PAS_A', PAS_B: 'PAS_B', PAS_C: 'PAS_C', PAS_D: 'PAS_D',
          AF_A: 'AF_A', AF_B: 'AF_B', ...
        },
        spatialRasterColormapRange: {
          PAS_A: 'PAS_A', PAS_B: 'PAS_B', PAS_C: 'PAS_C', PAS_D: 'PAS_D',
          AF_A: 'AF_A', AF_B: 'AF_B', ...
        },
      },
    },
  }
]

Relevant slides from my recent lab meeting presentation

Fixed by #1581

repo: vitessce/vitessce


text:
Add an option to save/load scripts

Add an option to save/load scripts

You mean scripts types into the editor? It currently saves last script into local storage. You can also cut/paste them. Not sure I see much benefit, as editor is mainly for playing with the page. All scripts should be developed through manifest files.

repo: vitmalina/bela


text:
wait until route to host is up

i know this from my ansible scripts. just retry 3 times and everything runs
Traceback (most recent call last):
	14: from /var/lib/gems/2.7.0/gems/hetzner-k3s-0.2.0/lib/hetzner/k3s/cluster.rb:144:in `block (2 levels) in create_resources'
	13: from /var/lib/gems/2.7.0/gems/hetzner-k3s-0.2.0/lib/hetzner/k3s/cluster.rb:438:in `wait_for_ssh'
	12: from /var/lib/gems/2.7.0/gems/hetzner-k3s-0.2.0/lib/hetzner/k3s/cluster.rb:438:in `loop'
	11: from /var/lib/gems/2.7.0/gems/hetzner-k3s-0.2.0/lib/hetzner/k3s/cluster.rb:439:in `block in wait_for_ssh'
	10: from /var/lib/gems/2.7.0/gems/hetzner-k3s-0.2.0/lib/hetzner/k3s/cluster.rb:452:in `ssh'
	 9: from /var/lib/gems/2.7.0/gems/net-ssh-6.1.0/lib/net/ssh.rb:251:in `start'
	 8: from /var/lib/gems/2.7.0/gems/net-ssh-6.1.0/lib/net/ssh.rb:251:in `new'
	 7: from /var/lib/gems/2.7.0/gems/net-ssh-6.1.0/lib/net/ssh/transport/session.rb:73:in `initialize'
	 6: from /usr/lib/ruby/2.7.0/socket.rb:632:in `tcp'
	 5: from /usr/lib/ruby/2.7.0/socket.rb:227:in `foreach'
	 4: from /usr/lib/ruby/2.7.0/socket.rb:227:in `each'
	 3: from /usr/lib/ruby/2.7.0/socket.rb:642:in `block in tcp'
	 2: from /usr/lib/ruby/2.7.0/socket.rb:137:in `connect'
	 1: from /usr/lib/ruby/2.7.0/socket.rb:64:in `connect_internal'
/usr/lib/ruby/2.7.0/socket.rb:64:in `connect': No route to host - connect(2) for 116.203.69.124:22 (Errno::EHOSTUNREACH)

0.3.0 now handles this case and retries. Thanks for the suggestion!

authors: thelittlebug vitobotta


text:
New Cottontail API, PolyphenyDB

In the future, this PR will include updates to the Cottontail API and a Polypheny Adapter.
Currently, it is open as a reference to show if (i) it could be merged and (ii) the status of CI builds.

@sauterl  @silvanheller Whoever created the DB integration tests should have a look at  DBIntegrationTest.entriesExistById() and DBBooleanIntegrationTest.entriesExistById() I see the following issue:
PersistencyWriter.exists() and PersistencyWriter.idExists() (which are used by those tests) both expect the ID to be a string. However, the entities we create for the test have long and int ID columns. Therefore, these tests will always fail, since Cottontail DB doesn't do type casting. Has this test ever worked?
I see three options:

Remove tests or perform them in different setting
Generalize PersistencyWriter.exists() to use PrimitiveTypeProvider instead of a String
Change unit tests to use string IDs

Any thoughts?

@silvanheller @ppanopticon My two cents are the generalisation of the exists() -- I don't see why this should be hardcoded as a string there.
However, iirc the tests were written by @silvanheller ...

@silvanheller @ppanopticon My two cents are the generalisation of the exists() -- I don't see why this should be hardcoded as a string there.
However, iirc the tests were written by @silvanheller ...

I see your point. But then on the other hand, the data model of Cineast currently expects IDs to be strings, which is hardcoded during entity creation. Adding this level of indirection to the two methods alone would not thus not give us the freedom to choose the type of the ID column.

I see your point. But then on the other hand, the data model of Cineast currently expects IDs to be strings, which is hardcoded during entity creation. Adding this level of indirection to the two methods alone would not thus not give us the freedom to choose the type of the ID column.

Fair enough, then I'd suggest to go with option C) -- use strings (consistently as we do anywhere else).

I agree with @sauterl, we can simply make the unit tests expect strings

PR is ready for review.
Major Changes

Updated Cottontail DB connector to version 0.13.x
Added Polypheny DB connector (experimental)
Deprecated ADAMpro connector
Refactored DB integration tests to me more in line with Cineast API
Changed connection management in Cineast (which is going to be part of a future discussion)

Breaking

Versions of Cottontail DB older than 0.13.0 are no longer supported.

@sauterl @lucaro @ppanopticon I merged the branch with the current master (which was heavily reformatted in #244), so it should now be ready for review & merging again

Just FYI @ppanopticon none of the unit tests currently work for polypheny

Just FYI @ppanopticon none of the unit tests currently work for polypheny

I have fixed a few issues in the DB connector and adjusted the unit tests. Main reasons for failure:

Polypheny DB requires a PK field, which was not specified in the Unit Test (i.e., all tests failed)
Minor issues in the implementation

Currently, two tests are failing:

testBetweenANDInQuery():  Here the issue seems to lie in the abstract implementation because I have actually not implemented this method.
entriesExistById(): There seems to be a Polypheny DB issue here. I have to check with Marco.

@lucaro @sauterl @silvanheller  (no idea who built this) I noticed that there is a version conflict between the ProtoBuf / gRPC version used by Cottontail DB and the one used by Cineast itself, which manifests itself by a crashing gRPC service in Cineast upon startup.
Would it be possible and safe to bump the versions for Cineast?

I don't see why not. I built the gRPC API for cineast a while ago, mostly as an attempt to cleanly specify all the calls and messages from scratch and also to make it easier to interface with other systems. It might already be outdated again though and nobody has used it since.

I fixed the exists() unit test by changing the query, since I do not have any influence over how and when the causing bug will be fixed in Polypheny DB.
As to handling of connections between Cottontail DB and Polypheny DB: I don't see an inconsistency here. JDBC connections are closed right away after an instance of a DAO is closed(). This is a bit different to gRPC, because the general recommendation for ManagedChannels is to keep them open for multiple calls. This is why there is some kind of connection pooling in the CottontailWrapper.
I don't have any troubles running either unit test locally.

I have addressed all the issues. This PR is ready for final review.
I will open an issue regarding DB connection handling in Cineast.

LGTM, thanks to everyone for all the work! I've tested this on the VBS data manually a bit and found no issues

authors: lucaro ppanopticon sauterl silvanheller

repo: vitrivr/cineast


text:
[BUG] Incorrect segmentation in FFMpegVideoDecoder when Audio is disabled

Description
If one disables audio on FFmpegVideoDecoder only one Segment on each source is emitted.
Steps To Reproduce
extract two video files with:
      "decoder": {
        "timeWindowMs": "1000",
        "audio": "false"
      },

Environment

MS Windows 10, dev #9a4bc2680a52a82fe7f942b6f38b5b7fd0f478b8

After the first segment is emitted, the flags videoReady and audioReady are set to false. But since audio = false, the audioReady flag remains false because there are no audio frames to trigger it again. So, no subsequent segments are actually emitted. Even if additional video frames are collected for further segments, the emit() function isn’t triggered.
In dev #de301d75e015992ea5be82fbeff59aba56a0577a, I changed the condition so that it only depends on videoReady if audio = false.

I have changed your change again so that the mechanism works as intended (it was basically copied from the VideoDecoder facility).
Can this bug be closed?

repo: vitrivr/vitrivr-engine


text:
Add support for creation and deletion of ConfigMaps and Secrets

Right now we are only able to update the configmaps and secrets, add support for creation and deletion also.

We have recently merged the change to delete the resource, we now have to work on supporting create.

repo: viveksinghggits/kuui


text:
DAM file replacement on upload

Description
DAM files are often used in multiple locations, and manually updating each instance when replacing a file can be time-consuming. This Pull Request introduces a feature that allows you to replace DAM files seamlessly, without needing to manually update their usage locations.
Screenshots/screencasts
Replacement dialog with cropping warning

Image replacement with cache handling via contentHash in url
https://github.com/user-attachments/assets/14455240-61e0-4306-94a2-5e40c52283af
Test image url without optional contentHash
https://github.com/user-attachments/assets/0b23ad16-0292-4847-8cb4-aab2b7848476
Test url with optional contentHash removed
https://github.com/user-attachments/assets/e28930a4-8a2f-4113-8474-68f1e0938072
Related tasks and documents
https://vivid-planet.atlassian.net/browse/COM-1133

@johnnyomair @jamesricky @VP-DS I addressed the open issues and added some changes I deemed necessary. This PR is now ready for review.
@VP-DS Feel free to also add your review regarding the changes I made
I will add the capability to replace a file by ID (to replace a file directly in the DAM detail page) in a follow-up PR.

I targeted a feature branch because I probably have to change the API of replace in the service a bit in my follow-up PR

repo: vivid-planet/comet


text:
Menubar refactor

Refactor the structure and style for the menu bar (logo, file, play, user, and help buttons).

Fix button heights
Remove forced navbar and user-pulldown styling
and fix Login and Signup button heights.

Closing this since the new design is coming and the issues will need to be relevant to that.

authors: kschzt wd-vizor

repo: vizorvr/vizor-create


text:
Tracking fixes

fix signup flow on save (open save dialog after signup/login)
add GA tracking for save, join, leave; frontpage; signup and login dialogs and completion

If you can confirm point (2) in my comment is not a problem, lgtm

Yeah, point 2 isn't a problem because the existing dialog flow is interrupted, that's why it's important also to use / resolve the same deferred as returned to the original caller, so that it can show eg. the Save dialog.

authors: kkananen kschzt


text:
Improve results handling

It should be possible to query the current state of application results.
enum for status (pass, fail, not run, exception), exit code, exception if one was raised

Implemented on https://github.com/vkottler/runtimepy/pull/152.

repo: vkottler/runtimepy


text:
Any way to ask the bucket how long until next token?

I'm considering using bucket4j to rate limit calling a rate limited API. In one case I need to be able to report, if the rate limit is reached,  how long until a new token will be available.
Is there a way to do this?
Cheers
Cameron

Currently there is no API to achieve this in effective way. I plan to release new version "2.1" in few days. I will add this issue to the scope, it looks closely similar to main goal of release described there #31

Thank you. That sounds great

Implemented.  "2.1" will be release soon. Example of usage can be found in the bottom of this page.

version 2.1.0 has been released

authors: cameronbraid vladimir-bukhtoyarov


text:
Do not use System.currentTimeMillis() to measure elapsed time

Hi,
Thank you for this great library, I particularly appreciate your HdrHistogram-backed Reservoirs with reset capabilities.
However I noticed that you use System.currentTimeMillis() throughout the code to measure elapsed time, e.g. here.
Shouldn't you be using System.nanoTime() instead? What happens if the machine's wall-clock time goes adrift, e.g. when changing daylight savings time?

What happens if the machine's wall-clock time goes adrift, e.g. when changing daylight savings time?

Amount of problems depends from reset policy. Uniform and ResetOnSnapshot are not affected, ResetePeriodically and ResetPeriodicallyByChunks will produce inaccurate snapshots:

If system time going forward then histogram will evict freshly recorded data, and client will miss measures.
If system time going back then histogram will report obsolete data.

Thanks for attention for details, you are raised interesting problem. I will provide the fix in few days.

I will provide the fix in few days.

Timezones with summer/winter time are not the problem, because System.currentTimeMillis() returns milliseconds in UTC, which by itself has no daylight savings time.
To summarize the impact:
The  System.currentTimeMillis() leads to inaccurate retention when machine time changed by administrator, or by unexpected reason.

Thank you for looking into this!
When you switch to nanoseconds, please be sure to account for numeric overflows, as explained in the javadocs of System.nanoTime():

To compare elapsed time against a timeout, use
if (System.nanoTime() - startTime >= timeoutNanos) ...
instead of
if (System.nanoTime() >= startTime + timeoutNanos) ...
because of the possibility of numerical overflow.

Done. will be released in scope of 3.0

Thank you!

authors: adutra vladimir-bukhtoyarov

repo: vladimir-bukhtoyarov/rolling-metrics


text:
OWA configuration options

I'm trying to understand how to set config options in the container, specifically e-mail server settings for password resets. According to the owa wiki, you modify the owa-config.php file. Where's this file in this container? I'm using docker-compose. Do I need to set a persistent volume to somewhere?
Thanks

Bump. Anyone?

Not sure if you've solved this already, but the configuration file is located at /var/www/html/owa-config.php after you've configured the container.
I added a volume mount for the file to my docker compose so that the configuration isn't reset:
owa:
    image: vladk1m0/docker-owa:latest
    container_name: owa
    depends_on:
      - owa_db
      - nginx
    networks:
      - owa_net
      - network_all
    environment:
      - TIME_ZONE="Canada/Montreal"
    volumes:
      - /mnt/data/owa/owa-config.php:/var/www/html/owa-config.php

Actually I abandoned OWA and went to Matomo and haven't looked back

authors: deeztek iwismer