<EMAIL_ADDRESS>[Failed to use built-in test cases] self-test cases fail to be executed

Instructions: Replace the template text and remove irrelevant text (including this line)
Hello,I meet a problem about self-test cases fail to be executed in<EMAIL_ADDRESS>Describe the bug
A clear and concise description of what the bug is.
(Issues related to the runtime files should be reported to their maintainer, check the file header.)
[root@centos8 vim]# ls
CONTRIBUTING.md  LICENSE   README.md   README_VIM9.md  ci         nsis     removed_la_files.txt  src    uninstall.txt  vimtutor.com
Filelist         Makefile  README.txt  READMEdir       configure  pixmaps  runtime               tools  vimtutor.bat
[root@centos8 vim]#make test
-------------------------------
Executed:  3478 Tests
 Skipped:   303 Tests
  FAILED:     6 Tests

Failures:
        From test_edit.vim:
        Found errors in Test_edit_file_no_read_perm():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2560-dlgauv2r2mk3n4hutdy53qy5hxrg6llc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_edit_file_no_read_perm line 8: Expected 1 but got 0
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2560-dlgauv2r2mk3n4hutdy53qy5hxrg6llc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_edit_file_no_read_perm line 9: Expected [''] but got ['one', 'two']
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2560-dlgauv2r2mk3n4hutdy53qy5hxrg6llc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_edit_file_no_read_perm line 10: Pattern '\\[Permission Denied\\]' does not match '\n"Xfile" \r\n"Xfile" 2L, 8B'
        From test_excmd.vim:
        Found errors in Test_redir_cmd():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2560-dlgauv2r2mk3n4hutdy53qy5hxrg6llc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_redir_cmd line 20: command did not fail: redir! > Xfile
        From test_help.vim:
        Found errors in Test_helptag_cmd():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2560-dlgauv2r2mk3n4hutdy53qy5hxrg6llc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_helptag_cmd line 20: command did not fail: r-xr--r--
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2560-dlgauv2r2mk3n4hutdy53qy5hxrg6llc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_helptag_cmd line 31: command did not fail: -w-------
        From test_matchfuzzy.vim:
        Found errors in Test_matchfuzzy():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2560-dlgauv2r2mk3n4hutdy53qy5hxrg6llc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_matchfuzzy line 54: Expected 1 but got 4
        From test_writefile.vim:
        Found errors in Test_write_readonly_dir():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2560-dlgauv2r2mk3n4hutdy53qy5hxrg6llc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_write_readonly_dir line 9: command did not fail: write
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2560-dlgauv2r2mk3n4hutdy53qy5hxrg6llc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_write_readonly_dir line 14: Expected 'E509:' but got '"Xdir/Xfile1" E510: Can''t make backup file (add ! to override)': write
        From test_alot.vim:
        Found errors in Test_recover_root_dir():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2560-dlgauv2r2mk3n4hutdy53qy5hxrg6llc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_recover_root_dir line 11: command did not fail: split Xtest

TEST FAILURE
make[2]: *** [Makefile:49: report] Error 1
make[2]: Leaving directory '/tmp/root/spack-stage/spack-stage-vim-8.2.2560-dlgauv2r2mk3n4hutdy53qy5hxrg6llc/spack-src/src/testdir'
make[1]: *** [Makefile:2257: scripttests] Error 2
make[1]: Leaving directory '/tmp/root/spack-stage/spack-stage-vim-8.2.2560-dlgauv2r2mk3n4hutdy53qy5hxrg6llc/spack-src/src'
make: *** [Makefile:39: test] Error 2

I know that the problem is caused by the incorrect source code of the test case. After the change, the test can pass, but I wonder why the test code is different from that in the code.
The error message "assert_equal and assert_match" is incorrect. If I change them, the test is passed. Will the patch be modified later?

Expected behavior
A clear and concise description of what you expected to happen.
Environment (please complete the following information):

Python: 3.6.8
Platform: linux-centos8-aarch64
Concretizer: original

Additional context
Add any other context about the problem here.

Is this a problem specific for CentOS?  It looks like the file could be read, even though read permissions are off.
Note that the test succeeds on all platforms where we run CI.

@brammool It's a lot of that problem, and now it's the same problem with the latest version 8.2.2569:
[root@centos8 vim]# make test
……
-------------------------------
Executed:  3482 Tests
 Skipped:   302 Tests
  FAILED:     6 Tests

Failures:
        From test_edit.vim:
        Found errors in Test_edit_file_no_read_perm():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_edit_file_no_read_perm line 8: Expected 1 but got 0
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_edit_file_no_read_perm line 9: Expected [''] but got ['one', 'two']
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_edit_file_no_read_perm line 10: Pattern '\\[Permission Denied\\]' does not match '\n"Xfile" \r\n"Xfile" 2L, 8B'
        From test_excmd.vim:
        Found errors in Test_redir_cmd():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_redir_cmd line 20: command did not fail: redir! > Xfile
        From test_help.vim:
        Found errors in Test_helptag_cmd():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_helptag_cmd line 20: command did not fail: r-xr--r--
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_helptag_cmd line 31: command did not fail: -w-------
        From test_matchfuzzy.vim:
        Found errors in Test_matchfuzzy():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_matchfuzzy line 54: Expected 1 but got 4
        From test_writefile.vim:
        Found errors in Test_write_readonly_dir():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_write_readonly_dir line 9: command did not fail: write
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_write_readonly_dir line 14: Expected 'E509:' but got '"Xdir/Xfile1" E510: Can''t make backup file (add ! to override)': write
        From test_alot.vim:
        Found errors in Test_recover_root_dir():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_recover_root_dir line 11: command did not fail: split Xtest

TEST FAILURE
make[2]: *** [Makefile:49: report] Error 1
make[2]: Leaving directory '/tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir'
make[1]: *** [Makefile:2257: scripttests] Error 2
make[1]: Leaving directory '/tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src'
make: *** [Makefile:39: test] Error 2

And I'll show you the system I'm using：
[root@centos8 vim]# uname -a
Linux centos8 4.18.0-193.el8.aarch64 #1 SMP Fri May 8 11:05:12 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
[root@centos8 vim]# cat /proc/cpuinfo
processor       : 0
BogoMIPS        : 100.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics cpuid asimdrdm dcpop
CPU implementer : 0x48
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd01
CPU revision    : 0

I don't know if you say that all platforms can run successfully. However, the test result always tells me that the error is displayed and whether the source code is running properly. It tells us which line of error is reported.

@Tom-python0121  wrote:
[root@centos8 vim]# uname -a

Hmmm, why do you run as root user?  That's a bad idea.
You should almost never need to login as root.
Running all vim tests as root seems very dangerous. It's a recipe for messing up your system.
Anyway, I tried to run that test as root on xubuntu-18.04 and it indeed fails:
First as regular user, the test passes when doing:
$ cd vim/src/testdir
$ make test_edit

Then same test as root:
$ sudo su
# make test_edit
Executed 64 tests                        in   9.340343 seconds
1 FAILED:
Found errors in Test_edit_file_no_read_perm():
command line..script /home/pel/sb/vim/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_edit_file_no_read_perm line 8: Expected 1 but got 0
command line..script /home/pel/sb/vim/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_edit_file_no_read_perm line 9: Expected [''] but got ['one', 'two']
command line..script /home/pel/sb/vim/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_edit_file_no_read_perm line 10: Pattern '\\[Permission Denied\\]' does not match '\n"Xfile" \r\n"Xfile" 2L, 8B'
SKIPPED Test_edit_CTRL_V(): ebcdic feature missing
SKIPPED Test_edit_DROP(): dnd feature missing
Makefile:63: recipe for target 'test_edit' failed
make: *** [test_edit] Error 1

The test is:
func Test_edit_file_no_read_perm()
  CheckUnix
  call writefile(['one', 'two'], 'Xfile')
  call setfperm('Xfile', '-w-------')
  new
  redir => msg
  edit Xfile
  redir END
  call assert_equal(1, &readonly)
  call assert_equal([''], getline(1, '$'))
  call assert_match('\[Permission Denied\]', msg)
  close!
  call delete('Xfile')
endfunc

Indeed, when running as root, &readonly is 0.
Of course, root can read a file with --w------- permissions.
I suppose we should skip this test when running as root.
I did not dare running all other Vim tests as root as I don't want to accidentally mess up my system.

I wrote in my previous comment:

Hmmm, why do you run as root user? That's a bad idea.
You should almost never need to login as root.

I should have added.  If you want to build and install vim. You
should instead be logged as a regular user and do something like
this, where only the 'install' step needs privilege access (using sudo)
to be able to install in /usr/local/...
$ cd vim
$ ./configure --with-features=huge --enable-gui=gtk3 --enable-python3interp=yes
$ make -j8
$ make test
$ sudo make install

@dpelle I used a non-root user to test the vim as you said, but two test failures were still reported.
[weipan@centos8 vim]$ ./configure --with-features=huge --enable-gui=gtk3 --enable-python3interp=yes
[weipan@centos8 vim]$ make -j8
[weipan@centos8 vim]$ make test
-------------------------------
Executed:  3761 Tests
 Skipped:    71 Tests
  FAILED:     2 Tests

Failures:
        From test_matchfuzzy.vim:
        Found errors in Test_matchfuzzy():
        command line..script /tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_matchfuzzy line 54: Expected 1 but got 4
        From test_messages.vim:
        Found errors in Test_quit_long_message():
        Run 1:
        command line..script /tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_quit_long_message[9]..VerifyScreenDump line 58: See dump file difference: call term_dumpdiff("testdir/failed/Test_quit_long_message.dump", "testdir/dumps/Test_quit_long_message.dump"); difference in line 1: "|^+0#0000e05#ffffff0|A| +0#0000000&@72"; difference in line 2: "|E+0#ffffff16#e000002|r@1|o|r| |d|e|t|e|c|t|e|d| |w|h|i|l|e| |p|r|o|c|e|s@1|i|n|g| |c|o|m@1|a|n|d| |l|i|n|e|.@1|s|c|r|i|p|t| |/|t|m|p|/|w|e|i|p|a|n|/|s|p|a|c|k|-|s|t|a|g"; difference in line 3: "|e|/|s|p|a|c|k|-|s|t|a|g|e|-|v|i|m|-|8|.|2|.|2|5|6|9|-|k|m|s|x|c|f|r|k|3|n|r|x|o|d|z|l|h|r|4|b|g|c|3|6|n|v|u|c|u|x@1|c|/|s|p|a|c|k|-|s|r|c|/|s|r|c|/|t"; difference in line 4: "|e|s|t|d|i|r|/|X|t|e|s|t|_|q|u|i|t|_|m|e|s@1|a|g|e|:| +0#0000000#ffffff0@48"; difference in line 5: "|l+0#af5f00255&|i|n|e| @3|1|:| +0#0000000&@64"; difference in line 6: "|-+0#00e0003&@1| |M|o|r|e| |-@1> +0#0000000&@64"
        command line..script /tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_quit_long_message[12]..StopVimInTerminal[14]..WaitForAssert[2]..<SNR>6_WaitForCommon[11]..<lambda>58 line 1: Expected 'finished' but got 'running'
        Run 2:
        command line..script /tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[502]..function RunTheTest[39]..Test_quit_long_message[9]..VerifyScreenDump line 58: See dump file difference: call term_dumpdiff("testdir/failed/Test_quit_long_message.dump", "testdir/dumps/Test_quit_long_message.dump"); difference in line 1: "|^+0#0000e05#ffffff0|A| +0#0000000&@72"; difference in line 2: "|E+0#ffffff16#e000002|r@1|o|r| |d|e|t|e|c|t|e|d| |w|h|i|l|e| |p|r|o|c|e|s@1|i|n|g| |c|o|m@1|a|n|d| |l|i|n|e|.@1|s|c|r|i|p|t| |/|t|m|p|/|w|e|i|p|a|n|/|s|p|a|c|k|-|s|t|a|g"; difference in line 3: "|e|/|s|p|a|c|k|-|s|t|a|g|e|-|v|i|m|-|8|.|2|.|2|5|6|9|-|k|m|s|x|c|f|r|k|3|n|r|x|o|d|z|l|h|r|4|b|g|c|3|6|n|v|u|c|u|x@1|c|/|s|p|a|c|k|-|s|r|c|/|s|r|c|/|t"; difference in line 4: "|e|s|t|d|i|r|/|X|t|e|s|t|_|q|u|i|t|_|m|e|s@1|a|g|e|:| +0#0000000#ffffff0@48"; difference in line 5: "|l+0#af5f00255&|i|n|e| @3|1|:| +0#0000000&@64"; difference in line 6: "|-+0#00e0003&@1| |M|o|r|e| |-@1> +0#0000000&@64"
        command line..script /tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[502]..function RunTheTest[39]..Test_quit_long_message[12]..StopVimInTerminal[14]..WaitForAssert[2]..<SNR>6_WaitForCommon[11]..<lambda>60 line 1: Expected 'finished' but got 'running'
        Run 3:
        command line..script /tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[502]..function RunTheTest[39]..Test_quit_long_message[9]..VerifyScreenDump line 58: See dump file difference: call term_dumpdiff("testdir/failed/Test_quit_long_message.dump", "testdir/dumps/Test_quit_long_message.dump"); difference in line 1: "|^+0#0000e05#ffffff0|A| +0#0000000&@72"; difference in line 2: "|E+0#ffffff16#e000002|r@1|o|r| |d|e|t|e|c|t|e|d| |w|h|i|l|e| |p|r|o|c|e|s@1|i|n|g| |c|o|m@1|a|n|d| |l|i|n|e|.@1|s|c|r|i|p|t| |/|t|m|p|/|w|e|i|p|a|n|/|s|p|a|c|k|-|s|t|a|g"; difference in line 3: "|e|/|s|p|a|c|k|-|s|t|a|g|e|-|v|i|m|-|8|.|2|.|2|5|6|9|-|k|m|s|x|c|f|r|k|3|n|r|x|o|d|z|l|h|r|4|b|g|c|3|6|n|v|u|c|u|x@1|c|/|s|p|a|c|k|-|s|r|c|/|s|r|c|/|t"; difference in line 4: "|e|s|t|d|i|r|/|X|t|e|s|t|_|q|u|i|t|_|m|e|s@1|a|g|e|:| +0#0000000#ffffff0@48"; difference in line 5: "|l+0#af5f00255&|i|n|e| @3|1|:| +0#0000000&@64"; difference in line 6: "|-+0#00e0003&@1| |M|o|r|e| |-@1> +0#0000000&@64"
        command line..script /tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[502]..function RunTheTest[39]..Test_quit_long_message[12]..StopVimInTerminal[14]..WaitForAssert[2]..<SNR>6_WaitForCommon[11]..<lambda>62 line 1: Expected 'finished' but got 'running'
        Flaky test failed too often, giving up

TEST FAILURE
make[2]: *** [Makefile:49: report] Error 1
make[2]: Leaving directory '/tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir'
make[1]: *** [Makefile:2257: scripttests] Error 2
make[1]: Leaving directory '/tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src'
make: *** [Makefile:39: test] Error 2


Search by amenity/facility, list amenity facility

Show popup when clicking on feature list item
Refactor feature list into ParkFeatureListItem
Add feature list
Hook up amenity and facility drop downs
Add amenity/facility lookup

@fremn I've merged your changes into here.

:deciduous_tree:


fix(ingest/tableau): handle missing query in tableau views

Fixes https://github.com/datahub-project/datahub/issues/7182
Checklist

[ ] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[ ] Tests for the changes have been added/updated (if applicable)
[ ] Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
[ ] For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

Darn you beat me to it. I came here to submit the easy PR. You're amazing @hsheth2 !

Hey  -  can we get this merged 🙏
Either solutions works.


is it possible to get through your REST api info about databases

is it possible to get through your REST api info about databases I use on my Heroku account ? With some short info about it like size ?

@prytnar Your best bet at the moment is probably to just use the CLI and perhaps parse the output.  We'd like to expose some nicer public REST api around database information but we haven't quite gotten there yet.  Let me know if you have any other questions.  Thanks!


[DEP1] Implement SDLang support for package descriptions

There is a (slightly outdated) draft for an SDL based package format. This should be implemented by separating the parser functionality in dub.package_.PacakageInfo into a separate module, where both, JSON and SDL are supported.

Can we rediscuss using SDL please.
There is a simple YAML alternative called TOML and betting on SDL, a XML derived format that hardly anyone uses, seems like a bad decision.
Also see my comment here for why it makes more sense to use a JSON derived format.

I've added a motivation section to the DEP: https://github.com/D-Programming-Language/dub/wiki/DEP1#why-sdl
In particular TOML is a lot worse at reducing nesting (although it's definitely an improvement) and wouldn't work for procedural elements with a more or less natural syntax. Also, although this is a matter of personal taste, SDL seems to be much closer to D syntax wise, which is a nice trait.
While TOML somewhat reduces visual nesting by using the [table] syntax, that also makes it awkward to use for things like sub packages:
[root] # ?
name = "somepack"

[dependencies]
someLibrary = "~>1.0"

# redundant (and doesn't preserve order):
[subPackages.subpack]
name = "subpack

# uhg, fall back to JSON like syntax?
subPackages = [
   {
      name = "subpack";
   }
]

# using TOML syntax for sub sections also isn't very pretty
[subPackages.subpack.dependencies]
somelib = "~>1.0"

# the "arrays of tables" syntax looks better
[[subPackages]]
name = "subpack"
[[subPackages.dependencies]]
somelib = "~>1.0"

The latter syntax looks kind of alright, but I personally found it relatively hard to grok. It also doesn't scale to deeper nesting levels. I also have a considerable dislike for formats that provide so many multiple syntax alternatives. It's confusing for newcomers and paves the way for non-uniformity across different packages.
Finally, and I have no idea how much of a difference this makes in practice, TOML states:

Be warned, this spec is still changing a lot. Until it's marked as 1.0, you should assume that it is unstable and act accordingly.

To me the only upside of TOML is it's presumably higher popularity, but does that really matter in practice? My guess would be that 90% of the people would have to learn a new language no matter which format we choose. IMO, popularity should only be used to decide between two otherwise "equal" contestants.

@MartinNowak and @s-ludwig
It's been a while since we've talked about this. As I understand...JSON format will always be supported and SDL will become the "user-friendly" format.  My question is, was there any reason that we couldn't support SDL and also enhance the JSON format to be more lenient...allow comments, unquoted strings, trailing commas?  We could even fix the deep nesting problem by allowing duplicate keys.  Adding support for LenientJSON would be very easy to implement, and would likely make people happy until we finish SDL or decide what to do next.

The problem is that the JSON format is supposed to be machine readable, so it would require anyone who wants to read that format to adjust. In reality you could argue, though. Usually (lib)DUB would always be used to read the package description and would then either output a standard JSON description or just the runtime representation.
But really I think there should only be one format endorsed for users and trying to make JSON more comfortable would lead to a mess of formats.

But really I think there should only be one format endorsed for users and trying to make JSON more comfortable would lead to a mess of formats.

I have a feeling that just about everyone who uses dub would love if it supported these 4 extensions to standard JSON.  The disadvantage as you said, would be making it harder for other programs to parse/modify it, and would increase complexity by adding another format.  This would leave DUB with JSON, LenientJSON, and SDL.  If we only take these factors into consideration I would think supporting LenientJSON would be a win, but I guess that's a matter of opinion.
I do sympathize with wanting to be compatible with other programs. Adding another format makes everyone else's life more difficult.  However, there are ways to accommodate this.  Like you mentioned, Dub can convert whatever format we use to standard JSON.   Then when a program wants to modify the JSON, it can use dub to convert the JSON to whatever format the user is actually using.  Something like dub readpackage and dub writepackage.

Great, need help to finish it?
After all it wouldn't be too hard to add more supported formats, and endorsing SDL as default seems like a good choice to try.


fix(consensus): we should have the sidechain id in the genesis block for the shard,epoch

Done in https://github.com/tari-project/tari-dan/pull/1135


Support function to do range when creating the partitions

Feature request
Is your feature request related to a problem? Please describe.

CREATE TABLE `test_partitionFiledWithFunction` (
  `tenant_id` bigint(20) not null ,
  `create_date` date not null ,
  `id` bigint(20) not null ,
  `data` varchar(255)
) ENGINE=OLAP
PRIMARY KEY(`tenant_id`,`create_date`，`id`)
PARTITION BY RANGE(`tenant_id`, year(`create_date`)) # Syntax error in the line
(
    PARTITION p1_2020  VALUES [("1", "2020-01-01"), ("1", "2021-01-01")),
    PARTITION p1_2021  VALUES [("1", "2021-01-01"), ("1", "2022-01-01"))
)
DISTRIBUTED BY HASH(`id`) BUCKETS 1
PROPERTIES (
"replication_num" = "1"
);

Describe the solution you'd like

Describe alternatives you've considered

Additional context

@minchowang StarRocks does not support the expression in the partition. The following month we will do it to make the user creating table more convenient.


Add logging filter to not raise error when monitoring transient nodes. [JIRA: RIAK-2373]

https://github.com/basho/riak_core/blob/develop/src/riak_core_dist_mon.erl#L81
For example, when the dist mon attempts to monitor nodes created to perform riak-admin test operations, it often spit out spurious errors in the form.
@riak_core_dist_mon:handle_info:81 Could not get dist for 'riak_test@<node_name>'
Basho folks, related ZenDesk ticket number: 13033

also impacts riak_core_tcp_mon in riak_repl.


chore: remove v2beta2 API Version

ref: https://github.com/apache/apisix-ingress-controller/issues/707
Signed-off-by: Jintao Zhang<EMAIL_ADDRESS>
Type of change:

[ ] Bugfix
[ ] New feature provided
[ ] Improve performance
[ ] Backport patches

What this PR does / why we need it:

Pre-submission checklist:

[ ] Did you explain what problem does this PR solve? Or what new features have been added?
[ ] Have you added corresponding test cases?
[ ] Have you modified the corresponding document?
[ ] Is this PR backward compatible? If it is not backward compatible, please discuss on the mailing list first

Codecov Report

Merging #1431 (ecf1326) into master (6b38e80) will increase coverage by 1.10%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1431      +/-   ##
==========================================
+ Coverage   40.38%   41.49%   +1.10%
==========================================
  Files          82       82
  Lines        7445     7246     -199
==========================================
  Hits         3007     3007
+ Misses       4090     3891     -199
  Partials      348      348

Impacted Files
Coverage Δ

pkg/api/validation/apisix_consumer.go
0.00% <ø> (ø)

pkg/api/validation/apisix_route.go
24.59% <ø> (+2.85%)
:arrow_up:

pkg/api/validation/apisix_tls.go
0.00% <ø> (ø)

pkg/api/validation/apisix_upstream.go
0.00% <ø> (ø)

pkg/config/config.go
66.34% <ø> (ø)

pkg/providers/apisix/translation/apisix_route.go
31.51% <ø> (+6.48%)
:arrow_up:

pkg/providers/apisix/translation/translator.go
0.00% <ø> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


links in footer arent properly relative

Viewing the page via localhost:8080/ipns/ipfs.io and clicking the links at the bottom breaks. I think thats because these links are absolute.

This needs to become a Hugo pages and I think the things will look a bit better. But who knows, maybe Pelican has some $relativePathToRoot var too, which we can prepend links with.

Website has been migrated to Hugo \o/  https://github.com/ipfs/website/pull/200
Now just needs to be deployed -> https://github.com/ipfs/website/issues/202

Fixed \o/


Allow archiving an article immediately

Expected Behavior
Feature request: be able to send an article straight to the archive state when I save it, similar to adding tags
Actual Behavior
Sometimes when I read an article, I want to save it to Pocket for safekeeping even after I finished it. This creates a lot of clutter in the pocket app since so many things are already read (not “actionable”).
Specifications

Version: All
Browser: All
Operating System: All

@alexkrolick You can do this by hovering over the overflow menu.  Is there another method you would fine more effective to accomplish this?  Open to making this experience optimal.

Hmm, I am not seeing an options menu in Firefox.

In any case I think it should be a persistent setting ("Default to Archive") that could also be toggled on a one-off basis. Something like a checkbox inside the widget.

tags tags tags

[ ] Archive?

Ah! Gotcha.  Yeah this code is representative of chrome/safari based extensions. The Firefox version of the extension is a bit more integrated. I will pass on this feedback to the team that works on it.

It seems like the newest update to my Chrome extension (see below) has gotten rid of the previous "Archive immediately" action that was there before on Chrome/Firefox. Is this something we can add back? Happy to write up a PR to do so.


Auto importing dart:html

Flutter keeps auto importing dart:html when I try to use a Text widget. I am using VsCode.
Flutter Doctor:
[✓] Flutter (Channel stable, v1.12.13+hotfix.9, on Mac OS X 10.15.4 19E287, locale en-US)
    • Flutter version 1.12.13+hotfix.9 at /Users/rickeylee/Desktop/flutter
    • Framework revision f139b11009 (3 weeks ago), 2020-03-30 13:57:30 -0700
    • Engine revision af51afceb8
    • Dart version 2.7.2

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /Users/rickeylee/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-R, build-tools 29.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_212-release-1586-b4-5784211)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.4)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.4, Build version 11E146
    • CocoaPods version 1.9.0

[✓] Android Studio (version 3.6)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 43.0.2
    • Dart plugin version 192.7761
    • Java version OpenJDK Runtime Environment (build 1.8.0_212-release-1586-b4-5784211)

[✓] VS Code (version 1.44.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.9.1

[✓] Connected device (1 available)
    • iPhone • d0545eb2ff26e1c087d1b29c26f8e15da19284bb • ios • iOS 13.3.1

FYI @devoncarew

Thanks for the report!
I think we'll want to do one of either

manually reduce the suggestion order of items from dart:html when writing a Flutter app, or
ensure that the statistics of import usage naturally lead to a lower heuristic for dart:html types

/move dart-lang/sdk

@rlee1990 - it looks like our move bot may not be working; can you re-file this at dart-lang/sdk? Thanks!

Okay

Done


19041.789 not supported

I'm windows 10. The home system doesn't support remote desktop connection. Who has a good way?

oh，you can try rdpwarp project.
If you have some problems,and if you have encountered certain problems and have the energy and ability to solve them, you can refer to this article (this is a Chinese article because I am a Chinese)
https://blog.csdn.net/u010804317/article/details/104011926

I'm windows 10. The home system doesn't support remote desktop connection. Who has a good way?

windows version 19042.928 win10 20H2
RDPWARP Version 10.0.190401.789
now work！！！！！
try this link download rdpwarp.ini https://github.com/sebaxakerhtc/rdpwrap.ini/blob/master/rdpwrap.ini

I'm windows 10. The home system doesn't support remote desktop connection. Who has a good way?

windows version 19042.928 win10 20H2
RDPWARP Version 10.0.190401.789
now work！！！！！
try this link download rdpwarp.ini https://github.com/sebaxakerhtc/rdpwrap.ini/blob/master/rdpwrap.ini

Hi
the latest rdpwrap.ini (21332.1000-SLInit) do not worked on windows 10 20h2.
Please help me figure out how to fix this problem.
Thanks

same issue

Duplicate of https://github.com/stascorp/rdpwrap/issues/1317


Allow tabs to wrap to multi-line

This PR fixes https://github.com/microsoft/vscode/issues/70413

@SneakyFish5

I think a neat solution for both of these problems is provided by @fraigo in #70413 (comment), let me know what you think. Here's a visual representation of it included with all the other changes:

This looks very similar to tabSizing: shrink where tabs shrink to a fixed size when too many are opened. What I do not like about the presented solution is that tabs now consume the entire width even when available space is there to show them normally. Ideally only tabs at the far right end would align vertically by growing or shrinking, right? Not sure how to get that done in pure CSS though... maybe there is a flex property that can help?

@bpasero @SneakyFish5 One solution to make the last row use the space better is adding a 'hidden' flex space after the last tab (in this case, adding space at the end of the tab container. I think 33% is a good value, could be changed to any other for the try the best fit.
.monaco-workbench .part.editor > .content .editor-group-container > .title.tabs> .tabs-and-actions-container.multi-line-tabs-container > .monaco-scrollable-element > .tabs-container::after {
	content: "";
	flex: 1 0 33%;
}

After some digging as well I couldn't figure out how to make the tabs stay the same size and align properly at the very far end, aside from setting a max-width to an arbitrary percentage, which is a pretty hacky fix. I like the solution that @fraigo is presenting. When testing it out flex: 1 0 0; worked better for me and made a smoother transition to the next line when opening new tabs, would there be any problem with that?

yes @SneakyFish5, using flex:1 0 0 works fine (even using flex: 1 0 auto should work in this case because there is no content to shrink), using the minimum spanning space.

Awesome, recorded a little snippet here:

@bpasero is that better?

@SneakyFish5 can you add this solution to this PR for me to play with? Easier then to give some feedback. I will also comment on the tab border then, thanks 👍

Will do 👍

@SneakyFish5 this works great when many tabs are opened and it wraps but is there a way to not have excessively large tabs when you only have few opened:

?

I pushed a few polish changes to your branch and thought about the use of border: I think conceptually it makes a lot of sense to use tab.border for this because according to the docs: Border to separate tabs from each other so it fits.
However, I think the logic of drawing this border should merge with the existing border we already have for active tabs:
https://github.com/microsoft/vscode/blob/9dc00c63efa2b9c8529299cc55d5be9a85fa07a7/src/vs/workbench/browser/parts/editor/tabsTitleControl.ts#L1150-L1156
This ensures we are using the same logic for rendering a border and more importantly allows to still have a different border color for the active tab compared to others.

this works great when many tabs are opened and it wraps but is there a way to not have excessively large tabs when you only have few opened

That's the current issue I'm facing that I'm not sure how to solve. I've tried setting a max-width, but I've realized it doesn't work on smaller window sizes. If anyone has any better ideas, please chime in as I'm definitely not the best at CSS.

However, I think the logic of drawing this border should merge with the existing border we already have for active tabs which also draws a border below tabs

Done, it now only draws a bottom-border for inactive tabs when multi-line tabs are enabled. Is that what you meant?
The commits got a little messy there (sorry about that), but I've fixed merge conflicts and changed it to use classList.toggle instead.

@SneakyFish5 one thing we could maybe try is to do the flex trick conditionally depending on wether the tabs wrap or not? E.g. when you open only a few tabs they would appear normally and only when they wrap we start the trick?
Code wise we know exactly how much space we have and how much space tabs consume around here:
https://github.com/microsoft/vscode/blob/90a9985d51d3dc1afeb734316e09867558d3156c/src/vs/workbench/browser/parts/editor/tabsTitleControl.ts#L1317-L1317
So we could toggle a similar class depending on how much space tabs consume in the tab container?

That's definitely possible, I've made it so that the multi-line tabs class only added if the "all tabs width" is greater than the "visible tabs width", and is removed if they are equal and the container height is equal to EDITOR_TITLE_HEIGHT.

I agree this probably isn't the most optimal situation and that it would be preferable to have the tabs be somewhat the same size and also expand to fill the container at the end of the row, but I'm not sure how to accomplish that.

Another issue to look at is to somehow if possible prevent this overflow in wrapping that makes tab no longer accessible:

Could something like a vertical scroll bar be used for the overflowing tabs?

@SneakyFish5 Doing some checks, the scrollable container must limit vertical size. Not sure how much should be the limit (in this example, 30% of the viewport height). Also, it must handle the vertical scroll bar the same way horizontal scroll is managed in non-multi-line tabs (a nice-looking-thin scroll bar).
src/vs/workbench/browser/parts/editor/media/tabstitlecontrol.css:49
.monaco-workbench .part.editor > .content .editor-group-container > .title.tabs > .tabs-and-actions-container.multi-line > .monaco-scrollable-element {
	height: auto !important;
	max-height: 30vh;
	overflow-y: auto !important;
}

Thank you as always for your CSS work @fraigo, I'll to familiarize myself with the scrollbar and see if I can implement a vertical scrollbar. I'm assuming this would be done somewhere around here?:
https://github.com/microsoft/vscode/blob/3c6a1ad913d84802fa762f8849e17f35cdda7876/src/vs/workbench/browser/parts/editor/tabsTitleControl.ts#L160

@SneakyFish5 thanks for the changes. I feel that the discussion about the border for tabs is something that we should look at separately because I think this matter is a bit more complex and I can also offer to add this after we merged this PR. I would like to focus exclusively on the multi-line wrapping in this PR, so I went ahead and removed the related changes https://github.com/microsoft/vscode/pull/106448/commits/e6f128801cb23cbc3e15f87bcab8dfaf4d5abe62 if you don't mind.
Things I did:

remove border handling and leave it for later
cleanup use of editor group title (your change was exactly what I had in mind)
cleanup a little bit the doLayoutTabs method to access tabsContainer.offsetHeight only when really needed (I am sensitive to accessing DOM properties that may trigger a layout in the browser)

Let's focus on the doLayoutTabs method: this is now THE place to decide if tabs wrap or not, which I think is good because there we know exactly how much width the tabs consume, so we can enable this conditionally. However I do not understand the logic you encoded there with regards to the offsetHeight and I also think that we now always set the multi-line class, even when not needed. Can we discuss this algorithm there?
As for the issue of having tabs exceed the height of the editor container: I would NOT add a scrollbar her but simply disable multi-line tabs IF the offsetHeight if the tabs exceeds a certain height. For example we can simply use the DEFAULT_EDITOR_MIN_DIMENSIONS.height as a driver and disable multi-line tabs if the editor height gets below this value?

Of course, I have no problem with any additions/removals that are needed. Please continue to do as you see fit, I'm also very keen on getting this merged so any thing necessary to move towards that goal is no issue with me.

However I do not understand the logic you encoded there with regards to the offsetHeight and I also think that we now always set the multi-line class, even when not needed. Can we discuss this algorithm there?

Sure, my thinking was the following:

If allTabsWidth exceeds visibleTabsContainerWidth, then apply the multi-line class to wrap tabs if multi-line tabs have been enabled in settings
However, the flaw in the above is that once the tabs were wrapped,  allTabsWidth would once again be equal to visibleTabsContainerWidth, so the class would be immediately removed. So, if allTabsWidth and visibleTabsContainerWidth are equal, it also checks if allTabsHeight is equal to EDITOR_TITLE_HEIGHT (the default height). If it is, then the multi-line class is removed.

You mentioned that the class is set even when not needed, is there a specific example of this? If my logic is wrong somewhere I can attempt to revise it.

For example we can simply use the DEFAULT_EDITOR_MIN_DIMENSIONS.height as a driver and disable multi-line tabs if the editor height gets below this value?

Can do, if possible could you give me a pointer for where to get the current editor height from? I can try to look for it/create a method for it myself if it doesn't already exist.

@SneakyFish5 ok I understand now and pushed https://github.com/microsoft/vscode/pull/106448/commits/318f2983d93a3c4b966a57340817bf7192ad5bf9 to clarify this. I am not able to see a case where the multi-line class is wrongly there, it seems to work fine.
As for the editor height: I think we need a similar thing as you added with titleHeight for editorHeight. Within the layout we should then add another check for the editor height becoming too small and then remove the multi-line class. I think the height of the editor can easily be computed because it is basically the available height of the entire editor group minus the title height.

Just pushed https://github.com/microsoft/vscode/pull/106448/commits/e6974fdfec48de8ae798eb340088f5fb7c5fde41 to fix a bug I noticed where the editor-container height wasn't being updated based on the changes in titleHeight. Let me know if you spot any problems with that.
As for the overflowing problem, I've run into some issues with that. I'm able to remove the multi-line class and get the tabs back to a single row when the editorHeight is below the minimum, however in doing so, the editorHeight becomes greater than the minimum again and repeats the process. https://github.com/microsoft/vscode/pull/106448/commits/3a3d7f0bf8aedf0d849e71154c1b6c7f2d9c24f7 is what I've gotten so far, and I'll continue to work on it, but I wanted to open up my progress to see if there were any possible solutions.

Yes you are right, you found a problem I have not thought about: normally the size of the title area was fixed (35px + breadcrumbs if visible) and as such we were able to do a good layout down to the editor, which is very important (it needs to be correct all the time).
With tabs now potentially wrapping, the size is no longer static and as such, a layout into the title can result in the title size changing. This is getting worse due to the fact that the title area layout is actually async:
https://github.com/microsoft/vscode/blob/09a78db5ef427ab945a2773239ab9fd6a9ef5e1c/src/vs/workbench/browser/parts/editor/tabsTitleControl.ts#L1239-L1239
I tried to come up with a solution today but could not come up with something simple. While the CSS solution is very elegant at first, we have have hit a blocker given we cannot easily provide the exact height down to the editor.

I'm slightly confused, I thought with the modifications to getPreferredHeight that this problem had been fixed and the title now dynamically, and correctly, returns it's height if multi-line tabs are enabled. Could you possibly elaborate on the issues that need fixing (aside from the overflowing tabs as I'm still not able to figure that out), so that I might be able to work on fixing them?

@SneakyFish5 I think there is a weird cycle now between editorGroupView#layout and tabsTitleControl#layout:

first we ask the tabs title control for the height using offsetHeight which can trigger a full browser layout btw
then we ask to layout the tabs title control
this potentially results in the title control to change its height depending on the logic inside
but we still use the previous computed height for the editor
we may end up using the wrong height for the editor

I think conceptually it should be:

editorGroupView#layout which will trigger...
...title control layout which returns its height that it ended up using
then editor control layout with that height

With this algorithm I would also think that you do not need to know the editor height, you can simply pass the overall height into the title control layout and then decide from within if the title should wrap or not.
Does that make sense?
As for the additional challenge that a redraw of tabs can result in the title height changing: I think this should not trigger a relayout, rather I would think that the tabs title control should have an event that is fired whenever the height changes and the editor group can register on that to trigger redraw. I think that would also help for the current logic that triggers redraw when breadcrumbs are enabled or disabled.
PS: I think it would be good if the CSS changes in tabsTitleControl.css could get some comments, I am having a hard time understanding the need for the properties, as well as the important and it would help for future maintenance if the logic is explained via comments.

Correct me if I'm wrong, but would the change be made here?:
https://github.com/microsoft/vscode/blob/c1905a3d139ea803c8f46ffc6535e9abdfcb1b60/src/vs/workbench/browser/parts/editor/editorGroupView.ts#L1702
If I understood your concerns correctly, when the titleHeight is increased/decreased due to a new row of tabs being added/removed, the editorHeight doesn't properly update when editorGroupView#layout is called? When testing, I don't see that issue, am I missing something?:

...title control layout which returns its height that it ended up using
then editor control layout with that height

I can definitely try to cleanup the logic and have titleAreaControl#layout return it's height and recalculate the editorHeight based upon that.

With this algorithm I would also think that you do not need to know the editor height, you can simply pass the overall height into the title control layout and then decide from within if the title should wrap or not.

Again I probably misunderstand what's going on, but is this not already being done in the editorGroupView#layout that was linked above? The editorHeight property I created for the group view was an attempt at fixing the overflowing tabs issue, I can remove that for now since it's currently not working/unnecessary.

I would think that the tabs title control should have an event that is fired whenever the height changes and the editor group can register on that to trigger redraw.

Sure, I can create an event that fires when the height of the tabsContainer changes from what it previously was. However, I don't think the editor group can call redraw, would editorGroupView#relayout instead be called, thereby replacing this line?:
https://github.com/microsoft/vscode/blob/c1905a3d139ea803c8f46ffc6535e9abdfcb1b60/src/vs/workbench/browser/parts/editor/tabsTitleControl.ts#L1023-L1027

I think it would be good if the CSS changes in tabsTitleControl.css could get some comments

Done, sorry about that. Hopefully they're a bit more descriptive now, if it needs further improvements let me know. I removed the !important in both classes since I realized they're unnecessary, forgot why they were there in the first place. I also fixed editorDropTarget to make use of the new changes in master.
This got to be very big, did not mean for that to happen haha, I just want to run everything by you especially with the new changes to master that I needed to familiarize myself with.

Hi @SneakyFish5 @bpasero This looks great.
When can this pull request go into the master?

Sorry for the silence, did not have a lot of time on this, will try to get back here in October.

Sorry if this is the wrong place to ask, but this is the only thing stopping me from swtiching to VSCode.
I've cloned the Repo but can't see how to start VSCode on linux

Your feedback would be much appreciated @WillcoWD, instructions for building vscode can be found here: https://github.com/microsoft/vscode/wiki/How-to-Contribute

@SneakyFish5

Correct me if I'm wrong, but would the change be made here?:

Yes, the point where the layout for both editor and title widget starts is this:
https://github.com/SneakyFish5/vscode/blob/c1905a3d139ea803c8f46ffc6535e9abdfcb1b60/src/vs/workbench/browser/parts/editor/editorGroupView.ts#L1702-L1702
As I already said, wouldn't this layout algorithm make more sense:

editor group view layout gets called with the size it can consume
editor title layout is called with that dimension and returns the actual width/height it consumes based on some rules

if multi line tabs are disabled, it just returns with 35px (as today)
if multi-line tabs are enabled but the resulting editor size is below min width, it just returns with 35px (see note below)
otherwise it returns with the exact height it consumed based on offsetHeight

editor group uses the title height to pass on to the editor control
layout is done

Note: maybe instead of the title control having hardcoded knowledge about the minimum size of the editor, it could rather accept the actual dimensions + the max dimensions it can consume. That way, the editor group view layout call can pass both the dimension and the max dimension into the title control.
I suggest for now we ignore the other feedback I gave about redraw calling relayout, I think this needs additional thoughts how to get right. Let's first focus on the layout algorithm from editor group to editor title.

Ok so I've attempted to rework the layout algorithm based on your comments but I'm not sure if I've done it correctly.
I've made it so that tabsTitleControl#layout now returns the height using getDimensions().height, since it seems to already implement the rules you've outlined?
https://github.com/microsoft/vscode/blob/ac0a02482669a6b142d0d09f516f733fe2b906c5/src/vs/workbench/browser/parts/editor/tabsTitleControl.ts#L1276
Then, the new height returned by the title area layout call is then passed directly into editorControl#layout.
https://github.com/microsoft/vscode/blob/ac0a02482669a6b142d0d09f516f733fe2b906c5/src/vs/workbench/browser/parts/editor/editorGroupView.ts#L1706-L1710
I didn't quite understand what you meant by passing in 'max dimensions' into the title control, could you elaborate on that?
P.S. - I realized the !important on .monaco-scrollable-element was necessary otherwise multi-line tabs would mess up with breadcrumbs so I've readded it in.

Yeah I think we need to drop the async layout code altogether if multi-line tabs are enabled. If multi-line tabs are enabled we cannot do a correct layout unless we layout sync and return the actual dimensions after wrapping. This is unfortunate but I see no  other solution. As such, the layout method probably should split up into a layoutSync and layoutAsync based on the setting.
As a side note: I would never expect layout to return Dimension | undefined, if we return early from the method, I would suggest to return the default fixed size as if wrapping was disabled.
I looked at your changes and I think the direction is good. I think though the max dimensions is not 100% accurate. If you use editorGroupView#minimumHeight, I think this would not be the editor control minimum height, but rather the entire minimum height. What we want here is this.editorControl.minimumHeight.

Laying out multi-line tabs synchronously seems to have fixed a lot of issues.

As a side note: I would never expect layout to return Dimension | undefined, if we return early from the method, I would suggest to return the default fixed size as if wrapping was disabled.

Returning the default height is no issue but then what should be returned as the width in the Dimension, since the dimension parameter is possibly undefined as well?

What we want here is this.editorControl.minimumHeight.

Done

Returning the default height is no issue but then what should be returned as the width in the Dimension, since the dimension parameter is possibly undefined as well?

Yeah true, that case I forgot about.

Were there any other issues to be taken care of?

I might need some time before I can do another review, then I can tell.

@SneakyFish5 I pushed another refactoring in https://github.com/microsoft/vscode/pull/106448/commits/9147044deab259a90be70d6247e665c2eb8efc68, trying to explain here:

I removed editorHeight which was not used anymore
I added a ITitleControlDimensions to have one property for both the available width/height as well as the maximum
I make sure that this.dimension in tabsTitleControl is never undefined, even when created. this was causing a lot of weird checks that are now nicer
ITitleControlDimensions is now passed all the way down to doLayoutTabs and instead of having a field disableMultiLineTabs, it is now decided down there wether multiline can be enabled or not based on available height
I removed the code to group.relayout, this needs a different solution (see my last comment here)
I touched on the algorithm to decide wether to enable or disable multiline tabs, but I am not 100% sure it is still working as you designed it, so please review

Finally, I think the previous group.relayout needs a solution. Previously you would only call this from the redraw method but truth is that any call to doLayoutTabs has a chance of either enabling or disabling multi line tabs, so we really need to make sure that group.relayout is triggered whenever the height of the tabs change. I think it would make sense to store the last computed height of the tabs control whenever layout is triggered and then do a comparison of the new height to the old height. If we find out that the height changed, this needs to propagate to the editor control.
PS: I might have to throw the towel on this one for October, I cannot spend more time on this atm.

I intend to fully look into this group.relayout this coming weekend as well as the refactoring you’ve done, got a bit busy recently but I should have time to complete the requested changes.

PS: I might have to throw the towel on this one for October, I cannot spend more time on this atm.

Of course, no worries there. This PR has gone through a multitude of refactoring and changes and I’m sure there are other, more pressing issues. I’ll try to get my fixes out this week/weekend but feel free to review it when you are able to do so 👍.

Pushed

Just pushed https://github.com/microsoft/vscode/pull/106448/commits/2be28a88416498f160ddf8b44bea3b2863ce0a5a with a very simple change that I hope implements what you were looking for? As of now it just stores the current height in lastComputedHeight right from the start, and then on every call to layout it checks if the height has changed, and if it has then it calls group.relayout. This seems to correctly update the editor size, however there is one problem I noticed.
I'm not sure when this bug was introduced, but whenever you open a tab with breadcrumbs enabled, it permanently breaks multiline tabs and causes the title size to take up the whole container whenever the multi-line class is removed (when number of rows is back to 1). That explanation may not have been the best so if you need a recording, I could also provide that tomorrow. I couldn't quite narrow down the cause of this issue, so I was wondering if maybe you might know what it is?
Again, feel free to review whenever you are able to, thanks!

Somehow we are always adjusting the height of the tab scrollbar based on the height of the title control, but I think that is not needed:
https://github.com/microsoft/vscode/blob/962bedc4f47b26e4a6ddc917ee2a4d9445531fb9/src/vs/workbench/browser/parts/editor/tabsTitleControl.ts#L1288
I pushed a fix and will also try to push these changes to master to reduce the diff of this PR to the minimum.

Awesome, breadcrumbs now works for me. Since you are going to push these other changes you mentioned to master, is there anything else that needs to be accomplished/fixed? Either way I'll make sure to do some more testing.

@SneakyFish5 I pushed some changes but left the overall behaviour pretty much as you had it. Some changes worth mentioning:

I removed 2 CSS classes that I felt were not needed, specifically for the height: auto !important for the scrollbar (which I think is not needed but maybe you recall why it was added) and I feel that the :after element was also not needed and I rather want taps to simply fill the width (but this is something I was planning to get more UX feedback from the team)
I fixed an issue where wrapping would not properly turn off when the minimum editor height is reached
I renamed the setting to workbench.editor.experimentalWrapTabs because I want to give insider users a chance to test this and report feedback but I am considering to pull it out if there is bad regressions that need more time to fix

I would appreciate if you could give this a good test:

corner cases such as tabs stop to wrap when exceeding available height
editor height is always proper, either when changing window size or when size changes from tab modifications within (e.g. closing a tab)
breadcrumbs on/off
tab drag and drop
tab related settings:

tabCloseButton: left | right | off
tabSizing: fit | shrink
...

Next steps:

present to team and UX call (today)
polish based on feedback
push to insiders to get more feedback behind experimental setting

Here is the result of the UX meeting with some additional requirements before we can merge this:

the editor actions on the top right should move to bottom right in the last row and should not consume the entire vertical space so that the rows above can fill the entire width
when workbench.editor.tabSizing: shrink is configured, tabs should not fill the last row and all tabs should have an even size across all rows
we should have a limit as to how many rows we support (e.g. 3 or 4) and not just rely on the minimal editor height

I will comment in https://github.com/microsoft/vscode/issues/70413 about the status of this PR.

Sorry got a bit tied up but I can now dedicate some more time to this PR. I'm glad things are moving along nicely, and I'll get to work right away on testing those things you listed + more and report back. As for the results of the UX team, there was a couple things I wanted to go over.

the editor actions on the top right should move to bottom right in the last row and should not consume the entire vertical space so that the rows above can fill the entire width

Might need some help with this one, since I'm assuming it requires some CSS changes? I was experimenting with align-self: flex-end; on the editor-actions class, but it seems that the tabsContainer is separate from the tabsAndActionsContainer that the editor actions are in, so that still leaves space. Overall, I'll probably need help with this one 😅, so feel free to chime in CSS experts.

when workbench.editor.tabSizing: shrink is configured, tabs should not fill the last row and all tabs should have an even size across all rows

Unless I'm misunderstanding, I think this goes back to the issue I was having, how should we make the tabs NOT fill the whole row? I couldn't figure out the CSS to do it, maybe someone else can help me out here? I'll continue to look into though of course.

we should have a limit as to how many rows we support (e.g. 3 or 4) and not just rely on the minimal editor height

Just pushed a commit for this, it simply replaces the existing logic we had for limiting based on editor minimum height for a new TabsTitleControl.MAX_WRAPPED_HEIGHT variable. Currently it's set to 4 rows, can be easily changed, or can add a setting to configure as well? Any changes that need to be made here just let me know.

Sorry got a bit tied up but I can now dedicate some more time to this PR. I'm glad things are moving along nicely, and I'll get to work right away on testing those things you listed + more and report back. As for the results of the UX team, there was a couple things I wanted to go over.

Thanks 👍

Might need some help with this one, since I'm assuming it requires some CSS changes? I was experimenting with align-self: flex-end; on the editor-actions class, but it seems that the tabsContainer is separate from the tabsAndActionsContainer that the editor actions are in, so that still leaves space. Overall, I'll probably need help with this one 😅, so feel free to chime in CSS experts.

If it helps to move the tab actions container somewhere else, I am also fine with that provided it does not break anything else.

Unless I'm misunderstanding, I think this goes back to the issue I was having, how should we make the tabs NOT fill the whole row? I couldn't figure out the CSS to do it, maybe someone else can help me out here? I'll continue to look into though of course.

Isn't this as easy as not setting flex-grow: 1? That is the thing that causes tabs to grow when wrapped, no?

Just pushed a commit for this, it simply replaces the existing logic we had for limiting based on editor minimum height for a new TabsTitleControl.MAX_WRAPPED_HEIGHT variable. Currently it's set to 4 rows, can be easily changed, or can add a setting to configure as well? Any changes that need to be made here just let me know.

Thanks, I commented. I think hardcoding it for now is fine, maybe we should use 3 instead of 4.

If it helps to move the tab actions container somewhere else, I am also fine with that provided it does not break anything else.

Alright I'll give it a shot, still have to learn how the editor actions work but I'll try my best.

Isn't this as easy as not setting flex-grow: 1? That is the thing that causes tabs to grow when wrapped, no?

Well here's what setting tabSizing: shrink currently looks like:

Not familiar with how tabSizing: shrink works, but when I tested it with and without flex-grow, it seemed to act the exact same.  Does this fill the requirement of tabs having an even sizing across rows, or am I missing something?

Yes I think tabSizing: shrink looks good to me, but I wonder why we then still need the flex-grow: 1; CSS rule? Shouldn't it only apply when tabSizing: fit?

Yea I agree, I switched the wrap CSS class to only enable for when tabSizing: fit is selected.

There is a bug when wrapping is enabled and the editor group is small enough that we switch to non-wrapping mode that I cannot explain:

We always try to keep the currently active tab visible via some logic in the doLayout code:
https://github.com/microsoft/vscode/blob/3229991032ca6fb0aeeb9e3afeb98db98fdb9fb3/src/vs/workbench/browser/parts/editor/tabsTitleControl.ts#L1420-L1420
For some reason this logic breaks due to us first adding the wrap class and then removing it again when we figure out the width is not sufficient. I have not been able to fix this, would appreciate a second pair of eyes looking at it.

There is a bug when wrapping is enabled and the editor group is small enough that we switch to non-wrapping mode that I cannot explain

Just looked into this and I think I might know where the problem is coming from. The way I limited the rows was calculating the max height in pixels. So TabsTitleControl.MAX_WRAPPED_HEIGHT = 35 x 3 = 105px. So when the editor group is small, that space is quickly filled up causing wrapped lines to be removed. If you try removing some of the tabs in that small editor group, does it begin to work for you? Or were you talking about a different issue?

We always try to keep the currently active tab visible via some logic in the doLayout code

Yup I see what you're talking about, I'll try digging into it to see what I can find.

@SneakyFish5 figured it out: when wrapping is disabled, we need to give the scrollbar an update so that the logic for revealing can function properly: https://github.com/microsoft/vscode/pull/106448/commits/fe75f6cfd8a61ad68c2deb6e8a449551005d8f60

Oh, I was able to drop the sync layout altogether given the relayout logic (via https://github.com/microsoft/vscode/pull/106448/commits/e69e7c31c503a902fa6a0f85db6753687351c08a). This is cool because it means when tabs wrapping is enabled, there should not be a bad perf impact for clients.
I think we are down to just 1 remaining task here: move the editor actions to the bottom right 👍 . And then do extensive testing as I outlined in https://github.com/microsoft/vscode/pull/106448#issuecomment-741666411

I'm not a programmer but deal with css a lot. Maybe I have a solution for the placing of the editor actions.
Please have a look at the fiddle I created: https://jsfiddle.net/t1fpwnxk/
It works if you are able to identify the tabs of the last row and give them a "flex: 0"
I hope it's of use for you because I'm eager to get tabs wrapping in VSCode. :-)
Thanks for this great tool!

@bpasero that's awesome, glad the perf impact will be reduced.
I've gone ahead and implemented part of the CSS changes that you've brought forward @DynDux. Thank you so much for your help, here's a recording of what I've got so far.

Pretty much what I've done is add a new wrap class to the editor actions, and add/remove it with the same logic that we add/remove the wrap class from the tabs container. If there is a better way to accomplish this I'm all for it. As for the class itself, I added the properties that you have in your fiddle for the icons/editor actions, but as you can see in the gif, they're sort of on top of the tabs. Is there any other property/CSS changes that can fix that, or maybe something I missed adding from the fiddle that would fix this issue?

I'm happy to be able to assist!
According from what I see from your screen recording, two things are missing:

the last tab has to have a margin-right of the width of the editor actions - maybe with some more pixels padding so it doesn't stick to the actions (css: line 44 in fiddle - sorry, forgot to write what width it should be..):

.tabs div:last-child {     margin-right: 150px; /* width of editor actions + some padding */ }

the tabs only on the last row have to get a flex: 0 to not span the full width of the container. I gave some tabs the class "lastrow" in fiddle but of course it depends on what tabs are really in the last row. Don't know if/how that's possible to accomplish but this is essential to not possibly get very large tabs on the last row (css: line 63 in fiddle):

.fillwidth .tabs div.lastrow {   flex: 0; /* disable fill only on lastrow tabs */ }

That is completely my fault, missed that part of the fiddle. Here's an updated recording of what I've got so far (I also pushed the commit, any feedback is much appreciated).

Works with breadcrumbs as well. I tried to explain the logic with comments as best as I could, but I can definitely try to elaborate if need be.  There is however one issue that I can't seem to figure out how to fix. It happens whenever the wrap class is removed and then applied again (when the title height exceeds the 3 row limit). Here's a visual example, since I can't quite describe it:

@bpasero any chance you know a potential fix to this issue? It doesn't happen all the time, only when the window is certain sizes. Aside from that, does this look like what the UX team was looking for?
Again thank you @DynDux, you're a real lifesaver :smile:.

@SneakyFish5 I can see you implemented the margin-right on the last tab but from what I see from the screen recording, the style for the last row is missing (point 2 of my last commit). The difference is the following:
- with no extra style applied (flex: 0)

- with added extra styles (flex: 1):

But, again, I don't know if it's possible to know, what tabs are on the last row and it has to change with each window resizing or opening/closing files...
I also think it looks nicer, if you add a 1px margin to the bottom of the tabs so they have a visual spacing (look close!):

If I may add one more request or suggestion to the row count on which the tabs revert to single line: I sometimes deal with 5+ rows of tabs (with custom css in vscode) because of my workflow (I know... ;-)) and I feel switching from multiline to single line would be irritating when opening or closing just one file. It would be great to choose on how many rows this happens or disable it altogether.
The number of rows also greatly depends on the width of the window and the length of the filenames - so when coding on a notebook, you might only have a few files open.
Maybe the better solution for small screens would be to scroll the tabs vertically instead of reverting to single line?

Again, my fault should've mentioned that. I thought per https://github.com/microsoft/vscode/pull/106448#issuecomment-742371268, the tab sizing on the last row was only for tabSizing: shrink, which was apparently already solved? Either way, I think that was separate from the editor actions thing, unless I'm mistaken?

I also think it looks nicer, if you add a 1px margin to the bottom of the tabs so they have a visual spacing (look close!):

Yea this was part of the very first commit, however got taken out for some reason that I can't quite remember now (theming issues?). I think @bpasero was contemplating adding it back, and I would be happy to take that up.
As for the 3 row limit and scrollbar, I personally am fine either way so I'll leave that final decision up to what the community, @bpasero, and the VSCode team as a whole decide.

Thanks for your work and starting this PR! I'm sure the team and community will decide what is best. :-)

@SneakyFish5 this looks great and what I had in mind with regards to the actions aligning to the right of the last row 👍

There is however one issue that I can't seem to figure out how to fix.

Can you check if this was caused by any of the new changes to rule out a regression from these?

Again, my fault should've mentioned that. I thought per #106448 (comment), the tab sizing on the last row was only for tabSizing: shrink, which was apparently already solved? Either way, I think that was separate from the editor actions thing, unless I'm mistaken?

Now that we have the actions on the last row and the tabs above filling the entire row, I wonder if we should revisit the flex-grow: 1 for tabs when wrapping. Maybe we leave it up to the user how to configure the tabSizing to drive this and not interfere here. Happy to try this out though once this PR is in a state to play with it again.

I also think it looks nicer, if you add a 1px margin to the bottom of the tabs so they have a visual spacing (look close!):

I like the border and had thought about it. Would this simply be a "gap" to the background or themable? Ideally a user would be able to change it's color but it might be challenging to accomplish given all the other border colors you can set per tab.

As for the 3 row limit and scrollbar, I personally am fine either way so I'll leave that final decision up to what the community, @bpasero, and the VSCode team as a whole decide.

This sounds like a setting we need to introduce. But I am also fine to gather some feedback from actual users of this feature before making a decision. The reason I thought this was a good idea is that it could get very frustrating if the size of the editor is constantly limited by the fact that tabs above wrap and take valuable space away. This can happen quickly when you make one editor group very large and the other very small.

Can you check if this was caused by any of the new changes to rule out a regression from these?

Oh sorry should have been more clear. It is due to the new changes, and I believe specifically due to these two lines: https://github.com/microsoft/vscode/blob/4585b7042fbd87aa461c3de8201df537e54bbc09/src/vs/workbench/browser/parts/editor/tabsTitleControl.ts#L1449-L1450
Was wondering if maybe you knew a reason for why it has that jarring effect, or possibly a tip on solving it?

I wonder if we should revisit the flex-grow: 1 for tabs when wrapping

Sure, I can definitely start looking into that. To be clear, keep tabSizing: shrink how it currently is, but work on making tabSizing: fit not grow the tabs with flex-grow: 1. Rather they keep their default "fitting" width until the row doesn't have enough space for a new tab, then grow them (to fill the empty space at the end of the row)?

I like the border and had thought about it. Would this simply be a "gap" to the background or themable?

I was thinking themable, and just using the same TAB_BORDER that is used for the right border on the tabs. What do you think?

Fyi I will be out starting today and maybe slow to respond, I suggest to get this into a bug-free state and then we can think about additional features such as the border or how tabs should grow 👍

@SneakyFish5 fyi pushed https://github.com/microsoft/vscode/pull/106448/commits/b4c809de8090882e9f9ed2363420676b3d0beeec with the following impact:

removed the 3 row limit for wrapping because I think this probably needs a setting if enforced and can always come later if a majority of people ask for it (maybe you can check if that fixes your issue too)
moved the wrapping class to the parent tabs-and-actions-container so that we don't have to add this class to both tabs and actions
changed the tabs-and-actions-container to be position: relative so that the actions can be positioned fully through CSS and don't have to be updated depending on breadcrumbs to be visible or not

I am still not entirely happy with the margin-right code (tabsContainer.lastChild?.previousSibling....), though it works reasonably well. An alternate idea I had was to treat the actions container like a tab that would simply always be added as last tab and flow with the others at the end, but that might require even more changes....
PS: I played again with fit vs shrink for the tab sizing setting when wrapping is on and feel that we can leave the flex-grow: 1 for now when fit, I think this works reasonably well even if it means that tabs on the last row grow artificially.

Actually with https://github.com/microsoft/vscode/pull/106448/commits/a53fe3c3414f065a423a7607dcaa70b22d5b5861 found a nice solution via CSS variables that does not require to patch any tab element directly. This makes sure we only have a margin-right for the last tab when wrapping is enabled.
I think this PR is close to be done, I would appreciate some testing so that we are certain this works as intended.

This is the PR I have been waiting for for years. Is there any way I can help get this merged faster? :)

Hey, sorry again I've been very busy recently. Thank you so much @bpasero for pushing all those fixes.
@cullenjohnson maybe you can help with the testing outlined here, or just in general do any sort of testing that you can think of? If not no worries, I'll be able to get some testing done within the next day or so as well, but of course all help is appreciated.

Hi,
I am up for testing but where will I get a version to test. Donot have
development environment to build myself.
I need a Mac version btw.
Thanks,
Swinder
On Wed, Dec 30, 2020, 12:51 PM SneakyFish5<EMAIL_ADDRESS>wrote:

Hey, sorry again I've been very busy recently. Thank you so much @bpasero
https://github.com/bpasero for pushing all those fixes.
@cullenjohnson https://github.com/cullenjohnson maybe you can help with
the testing outlined here
https://github.com/microsoft/vscode/pull/106448#issuecomment-741666411,
or just in general do any sort of testing that you can think of? If not no
worries, I'll be able to get some testing done within the next day or so as
well, but of course all help is appreciated.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/pull/106448#issuecomment-752357262,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADBBZ3QINBMPYNUEI2DSZDSXLIIFANCNFSM4RGQAQ6A
.

Sorry for the delay again, had a lot of issues with node-gyp when building but was finally able to get it working and do the tests. I did a run through of all things outlined in https://github.com/microsoft/vscode/pull/106448#issuecomment-741666411 as well as:

Anything I could think of related to pinned tabs
tabCloseButton setting
titleScrollbarSizing setting
Scroll to switch tabs
Theming

I also tested a few more things that I can't quite remember now, however they all worked, and everything looked good in regards to the editor height and layout. If there are any more tests that need to be completed, please let me know.

Sorry for the delay again, had a lot of issues with node-gyp when building but was finally able to get it working and do the tests. I did a run through of all things outlined in https://github.com/microsoft/vscode/pull/106448#issuecomment-741666411 as well as:

Anything I could think of related to pinned tabs
tabCloseButton setting
titleScrollbarSizing setting
Scroll to switch tabs
Theming

I also tested a few more things that I can't quite remember now, however they all worked, and everything looked good in regards to the editor height and layout. If there are any more tests that need to be completed, please let me know.

Thanks a lot @SneakyFish5 I plan to merge this soon to get it into insiders during January for more coverage.

Thanks a lot @SneakyFish5 I plan to merge this soon to get it into insiders during January for more coverage.

Thanks @SneakyFish5 for pushing this forward 🥂

Thanks @SneakyFish5 for pushing this forward 🥂

This issue seems to be merged now - Am I right?
When is the next official release of VSCode?

This issue seems to be merged now - Am I right?
When is the next official release of VSCode?

@Tschebbe if you don't want to wait until your next stable release in early February, simply switch to VSCode insiders to get this as early as tomorrow: https://code.visualstudio.com/insiders/

@Tschebbe if you don't want to wait until your next stable release in early February, simply switch to VSCode insiders to get this as early as tomorrow: https://code.visualstudio.com/insiders/

Thank you as well @bpasero for your continuous effort and assistance in pushing this PR forward!

Thank you as well @bpasero for your continuous effort and assistance in pushing this PR forward!

I think I found a pure css solution for the problem with last tab spanning the whole width!
Just add the following style when tabSizing = fit:
.tabs-container::after{   content: '';   flex-grow: 20; }
This will create an additional tab pseudo-element, that grows 20 times larger than the other tabs. It could be an even higher number, but I think 20 should be sufficient.
The margin-right on the last-child ist still needed though.

I think I found a pure css solution for the problem with last tab spanning the whole width!
Just add the following style when tabSizing = fit:
.tabs-container::after{   content: '';   flex-grow: 20; }
This will create an additional tab pseudo-element, that grows 20 times larger than the other tabs. It could be an even higher number, but I think 20 should be sufficient.
The margin-right on the last-child ist still needed though.

@DynDux @SneakyFish5 great, I suggest we take this idea to a new PR and test it out there, what do you think?

@DynDux @SneakyFish5 great, I suggest we take this idea to a new PR and test it out there, what do you think?

Totally ok for me! Just thought it belongs to this PR because this is how it should have been resolved in first place. ;-)
Please do whatever the right workflow is. Thank you so much!

Totally ok for me! Just thought it belongs to this PR because this is how it should have been resolved in first place. ;-)
Please do whatever the right workflow is. Thank you so much!

I have added your suggested solution to https://github.com/microsoft/vscode/issues/113801.

I have added your suggested solution to https://github.com/microsoft/vscode/issues/113801.

Great work to those involved! Pumped to have this feature 👏 🎉 👏


[ompl] Add vcpkg_check_linkage

According to the upstream configuration:
# build the library
if(MSVC)
    add_library(ompl STATIC ${OMPL_SOURCE_CODE})
else(MSVC)
    add_library(ompl SHARED ${OMPL_SOURCE_CODE})
endif(MSVC)

ompl can only be built as a static library in Windows and be built as a dynamic library in non-Windows.
Fixes #21658.

ompl can only be built as a static library in Windows and be built as a dynamic library in non-Windows.

I wonder if this a true limitation or just convention.

Thanks :)


epr.py should give visual indication of chapter ending

If I go to the second chapter, then use <UP> (up  on keyboard) to get to the first chapter, epr.py shows <-- END --> as an indication that I've changed chapters.

when using <DOWN> to reach the last line of the chapter, <-- END --> should display before epr.py switches to next chapter.

It's very surprising to see a new chapter, when I use <DOWN> to read the next line.

when using <PAGEDOWN> to reach the last line of the chapter, I'm often surprised that I have lost my reading position, since an unknown number of lines has scrolled past.  I don't know if I've read half the page, or 2/3 of the page, or how many lines of the page.

this should be fixed by prefixing each line from the previous page  with a * to indicate that only a partial page has been displayed.
         * lines lines
         * lines lines
         * lines lines
         * lines lines
         * lines lines
         * lines lines
           lines lines
           lines lines
           lines lines
           lines lines
           lines lines
           lines lines
           lines lines

Hey there, thanks for feedbacks. Actually the 1st problem you stated above is limitation of this epr, since it process text chapter by chapter allowing epr to run on low memory, at the cost of that 1st problem... To get seamless reading between chapter, it needs to process all text inside epub and process them fast, which is out of my reach since I'm not an actual programmer, just love making script to help my daily life... I tried actually, using multiprocess python packages but, still cannot fully grasp its low level behaviours...
2nd problem, I fixed this in https://github.com/wustho/epy but probably forgot to add this patch to epr... So when you hit next page to reach last lines of chapter, you will get a new page containing only that last lines, so we won't lose our reading position, I will add this later to epr, meanwhile you could try https://github.com/wustho/epy

thank you for the reply.  The lack of indication when reaching the
end-of-chapter is a small issue.  I hoped you could attach a text at the
end of every chapter.
I don't use epr book reader every day, but I do like it to use it, when I'm
planning to read a book, but have it open in one of a lot of windows.   The
program is very well behaved when I want to open multiple chapters in the
same book!
Thank you.
On Sat, Feb 29, 2020 at 9:40 AM Benawi Adha<EMAIL_ADDRESS>wrote:

Hey there, thanks for feedbacks. Actually the 1st problem you stated above
is limitation of this epr, since it process text chapter by chapter
allowing epr to run on low memory, at the cost of that 1st problem... To
get seamless reading between chapter, it needs to process all text inside
epub and process them fast, which is out of my reach since I'm not an
actual programmer, just love making script to help my daily life... I tried
actually, using multiprocess python packages but, still cannot fully
grasp its low level behaviours...
2nd problem, I fixed this in https://github.com/wustho/epy but probably
forgot to add this patch to epr... So when you hit next page to reach last
lines of chapter, you will get a new page containing only that last lines,
so we won't lose our reading position, I will add this later to epr,
meanwhile you could try https://github.com/wustho/epy
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/wustho/epr/issues/26?email_source=notifications&email_token=AAGL6B4TQWCSM5X3PNKQI6DRFEO4ZA5CNFSM4K6WPQ42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENL3VJQ#issuecomment-592951974,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGL6B65HB6SO3EUSQBZ3MLRFEO4ZANCNFSM4K6WPQ4Q
.

@kanliot hey there, been long time. But I added seamless between chapters feature here: https://github.com/wustho/epy


Crashing when changing brightness level

Before opening the issue, have you...?

[X] Searched for existing issues
[X] Looked through the wiki
[X] Updated MonitorControl to the latest version (if applicable)

Describe the bug
The app crashes when I try to change the brightness of secondary monitor (Macbook retina display)
Steps to reproduce

Hold control + press brightness key

OR

Use the slider from menubar icon

Expected behavior
Brightness changed
Anything else?
It used to work before upgrading to macOS Sequoia 15.0
Environment Information (please complete the following information)
- macOS version: 15.0
- Mac model: macbook m3 pro
- MonitorControl version: 4.2.0
- Monitor(s): LG HDR WFHD
- Apple Silicon/M1 (yes or no): yes

Hi there, please download the Sequoia compatible version currently available here:
https://github.com/MonitorControl/MonitorControl/issues/1570


ScottPlot Shared Project (.shproj)

Currently some code from ScottPlot4 is used in ScottPlot5 by tactically adding certain ScottPlot4 .cs files to the ScottPlot5 solution.
This works, but it's not obvious when working with ScottPlot4 which source files are shared.
Previous efforts sought to create a csproj file to hold shared code (#1955, #1965) but this ultimately failed because of differences in things like nullability (a C# language feature not supported by ScottPlot4, #692). It's also not clear which project "owns" the shared code, and where its tests should live (maybe in its own test project?). Namespace conflicts are a concern, but can be quickly identified by the CI system.
However, I recently became aware of Shared Project files (.shproj) which may solve some of these previous issues. This issue will track efforts exploring pulling useful functionality out of ScottPlot4 for use of ScottPlot5 (e.g., ScottPlot.Statistics.Histogram), and also providing new ScottPlot5 features in ScottPlot4 (e.g., ScottPlot.Generate).
Referencing .shproj vs .csproj projects

Putting code in a shared project (.shproj) allows .cs files to be compiled into a referencing project at compile time

Putting code in a .NET Standard project (.csproj) and referencing it puts that shared code in a separate DLL

Considerations

Add #nullable enable to the top of .cs files to allow nullable support where it is available but not cause errors compiling to targets that don't support it

You must explicitly define all usings because implicit usings and global usings cannot be relied upon

Resources

https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/shared-projects
https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/code-sharing#Shared_Projects
https://alteridem.net/2014/06/19/universal-projects-in-visual-studio/
https://github.com/dotnet/project-system/issues/6010
https://dailydotnettips.com/difference-between-shared-project-and-class-library-project-in-visual-studio-2015/
https://www.c-sharpcorner.com/UploadFile/7ca517/shared-project-an-impressive-features-of-visual-studio-201/

Visual Studio is making it difficult to separate shared code from shared classes 🤔

Probably the best way to proceed is a .csproj test runner just for shared code.
This may be a good way to ensure that there are no dependency leaks from the shared code files.


APT whitelist request for libwxgtk3.0-dev

This replaces travis-ci/travis-ci#4271.
The original text by @timw4mail follows

My project Tyro depends on wxWidgets 3.0.

libwxgtk3.0-dev, libwxgtk3.0-0 does not appear to a package name on which our automation process can handle.
APT packag request should be made for exactly one package, according to the form specified in
https://github.com/travis-ci/apt-package-whitelist#package-approval-process.
If the source package of your requested package contains other related packages, you do not
have to open another one for those.
(When in doubt, do.)

Ran tests and found setuid bits by purely textual search. Further analysis is required.
If these are found to be benign, add:
libwxbase3.0-0 libwxbase3.0-dev libwxbase3.0-0-dbg libwxgtk3.0-0 libwxgtk3.0-dev libwxgtk3.0-0-dbg libwxgtk-media3.0-0 libwxgtk-media3.0-0-dbg libwxgtk-media3.0-dev libwxgtk-webview3.0-0 libwxgtk-webview3.0-0-dbg libwxgtk-webview3.0-dev wx-common wx3.0-headers wx3.0-i18n wx3.0-examples wx3.0-doc
See https://travis-ci.org/travis-ci/apt-whitelist-checker/builds/72553383.

@BanzaiMan As I said here https://github.com/travis-ci/apt-package-whitelist/issues/217
first half of setgid is part of autoconf and enabled only for specific OSes (Linux not included). But you can investigate it yourself. And everything else - is false positive (furthermore it's code from osx part). You can clearly see that setUIDelegate should be read as setUI Delegate and not as setUID elegate. Please give these packages a little more priority as they are widely used in gui apps.

I'd also need that for xoreos' Phaethon, which, granted, isn't really all that useable yet, let alone widely used. Thanks.

Audacity is transitioning to wxWidgets3 at the moment, so it would be helpful to have this available there, too.

@BanzaiMan wxwidgets3.0 packages whitelist is the only thing stopping us from moving to container-based build.

Another request for this for Audacity.  We've now made the transition to wxWidgets3 and are using Travis without Docker only because of it.

RPCS3 depends on wxWidgets3. One of the only things stopping from us moving to container-based builds.

@BanzaiMan are you even going to start adding these packages or you just abandoned this container idea altogether? It's been half the year now.

+1: I would also like to be able to use containerised builds with wxWidgets 3.

@BanzaiMan Is this ever going to get merged, or should we simply start looking into abandoning Travis?

+1


WIP [DEVOPS-922] Different ports for mainnet/staging/testnet

This change will be targeting release/0.11.0 or release/0.11.1.
The WALLET_PORT environment variable will be set at webpack build time based on the target network. It is available to use from the environment.WALLET_PORT global.
The cardano launcher will use the same port.
This will allow mainnet and testnet builds of Daedalus to run at the same time.

Thanks for the PR @rvl!
I think we won't be merging it into release/0.11.0 -> it should target release/0.11.1 (hotfix!).
I will create release/0.11.1 branch next week.
cc @darko-mijic @DominikGuzei @jmitchell

(closed by mistake!)

WALLET_PORT is working fine, however the Electron server will fail. By using a different port multiple instances work well. I have created an ELECTRON_PORT environment variable. Not sure if it's the best naming.

@rvl I have rebased this PR to target release/0.11.1
cc @darko-mijic @jmitchell


forbidden sysctl: "vm.max_map_count" not whitelisted

Hi,
i've tried to install opensearch via helm, but pods are pending with this message:
forbidden sysctl: "vm.max_map_count" not whitelisted
I've tried to override the security settings, but did not help:
helm upgrade --install opensearch opensearch/opensearch --set sysctl.enabled=true --set podSecurityContext.runAsUser=0 --set securityContext.runAsNonRoot=false >test.yml

Im try to migrate from ES, but theirs helm using a bit different method:
they are using a fully privileges initcontainer to set the vm.max_map_count:
   initContainers:
154       - name: configure-sysctl
155         securityContext:
156           runAsUser: 0
157           privileged: true
158         image: "docker.elastic.co/elasticsearch/elasticsearch:7.14.0"
159         imagePullPolicy: "IfNotPresent"
160         command: ["sysctl", "-w", "vm.max_map_count=262144"]
161         resources:

What would be the best practice? Others does not have this situation?
thanks

Maybe try this init container as a workaround
# # Enable on the first time
# sysctl:
#   enabled: false

extraInitContainers:
  ## Image that performs the sysctl operation to modify Kernel settings (needed sometimes to avoid boot errors)
  - name: sysctl
    image: docker.io/bitnami/bitnami-shell:10-debian-10-r199
    imagePullPolicy: "IfNotPresent"
    command:
      - /bin/bash
      - -ec
      - |
        CURRENT=`sysctl -n vm.max_map_count`;
        DESIRED="262144";
        echo "$CURRENT $DESIRED"
        if [ "$DESIRED" -gt "$CURRENT" ]; then
            sysctl -w vm.max_map_count=262144;
        fi;
        echo "$CURRENT $DESIRED"
        CURRENT=`sysctl -n fs.file-max`;
        DESIRED="65536";
        echo "$CURRENT $DESIRED"
        if [ "$DESIRED" -gt "$CURRENT" ]; then
            sysctl -w fs.file-max=65536;
        fi;
        echo "$CURRENT $DESIRED"
    securityContext:
      privileged: true

@dyipon @sdwerwed By default;
https://github.com/opensearch-project/helm-charts/blob/8aaa89e2ed43896910dd50a57a50e05380ddea71/charts/opensearch/values.yaml#L373
This enabled will result in this being enabled on the sts;
        {{- if .Values.sysctl.enabled }}
        sysctls:
        - name: vm.max_map_count
          value: {{ .Values.sysctlVmMaxMapCount | quote }}
        {{- end }}

As explained in those values, your kubelet / node needs to be allowed to access these things (Per the comments):
https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html)
https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/
It's not a bug, as the container points out, Kubernetes/CRI can't access the system option because it isn't whitelisted.
The recommendation of enabling privileged: true is not good and dangerous.

@DandyDeveloper  ES Helm chart using
https://github.com/elastic/helm-charts/blob/e077086c74d3b9e121cec1d93f04d8418599bae4/elasticsearch/templates/statefulset.yaml#L166
privileged: true

@dyipon That doesn't make it safe ;)

Sadly on GKE adding vm.max_map_count to the kublet --allowed-unsafe-sysctls arg is not a supported option as vm.max_map_count is an "unsupported" kernel parameter...
This is the error you'll get if you try to set it using gcloud beta container node-pools create
ERROR: (gcloud.beta.container.node-pools.create) ResponseError: code=400, message=Unsupported kernel parameter vm.max_map_count.

So it looks like the privileged sysctl init container is the only decent option currently for opensearch...

Unfortunately, regarding GKE, there's just not many other options. I don't like the idea of privileged: true on a initContainer, but it does seem to be the only option here.
Per the above comment though, there definitely needs to be some understanding that either;

Nodes have to be prepared beforehand with the vm.max_map_count specifically for OpenSearch
Kubelet needs to have explicitly access to the necessary sysctls (even if it is considered unsafe)

Otherwise, the best bet is privileged: true which isn't good advice but we don't really have many other options.

At least scoping it to an init container is a reasonable compromise for now - as long as we can enable the init container via a flag.

Close this for now as it seems to be resolved by community.
Please feel free to re-open if you still have questions.
Thanks.

It would be nice if the init container method in this issue could become an official part of this helm chart and could be toggled with a bool value.

It would be nice if the init container method in this issue could become an official part of this helm chart and could be toggled with a bool value.

Hi @acjohnson feel free to contribute the changes if you are available for that :)
We welcome community contributions to help improve helm charts every day.
Thanks.

I'm indifferent about adding it. If there is an overwhelming (somewhat) need for it. It should be done. Community driver after all

With k8s v1.25 PodSecurity "baseline:latest" or PodSecurity "restricted:latest",  initContainer solution provided above doesn't work as it needs securityContext.privileged: true which is dangerous as well.
Also helm-charts/charts/opensearch/values.yaml doesn't work as it does the same thing.
error:
would violate PodSecurity "baseline:latest": forbidden sysctls (vm.max_map_count)

Maybe try this init container as a workaround
# # Enable on the first time
# sysctl:
#   enabled: false

extraInitContainers:
  ## Image that performs the sysctl operation to modify Kernel settings (needed sometimes to avoid boot errors)
  - name: sysctl
    image: docker.io/bitnami/bitnami-shell:10-debian-10-r199
    imagePullPolicy: "IfNotPresent"
    command:
      - /bin/bash
      - -ec
      - |
        CURRENT=`sysctl -n vm.max_map_count`;
        DESIRED="262144";
        if [ "$DESIRED" -gt "$CURRENT" ]; then
            sysctl -w vm.max_map_count=262144;
        fi;
        CURRENT=`sysctl -n fs.file-max`;
        DESIRED="65536";
        if [ "$DESIRED" -gt "$CURRENT" ]; then
            sysctl -w fs.file-max=65536;
        fi;
    securityContext:
      #runAsUser: 0
      privileged: true

I would like to thank you, this works very well for deprecated kubernetes version 1.15 and official helm chart of opensearch version 2.11.0


Detect annotations during expand super types step

I believe it might be benecial to fill missing annotations when expanding supertypes. This step fills only SubTypes store leaving TypesAnnotated store untouched. In our project we have a huge classpath and want to limit scan phase as much as possible. We rely on getTypesAnnotatedWith though so we had our own fork just for this case.
Do you think it might become part of the library?

sounds good @hejcz
though it can be impl a bit more generically imho - so that signature can support something like
expandX(store, Scanners.SubTypes, ReflectionUtils.SuperTypes) and expandX(store, Scanners.TypesAnnotated, ReflectionUtils.AnnotationTypes) lmkyt

you're right, let me look it through.


Remove reference to Ember.Select

Ember.Select was deprecated and then removed as of
emberjs/ember.js#13144. This removes ember-engine's reference to
Ember.Select and should also fix the issue reported here: https://github.com/dgeb/ember-engines/issues/76#issuecomment-208985230

@rwjblue :heart: :heart: :heart:


Window location with XMonad.Layout.ThreeColumns seems erratic

Problem Description
When using  XMonad.Layout.ThreeColumns windows move around erratically when creating new windows or closing existing windows.
Here is a flow where at first I have one window (a) open then open a second (b) and a third (c), then close them one by one.
1 [   a   ]
2 [b][ a  ]
3 [a][c][b]

CLOSE
1 [a][c][b]
2 [b][ a  ]
3 [   a   ]

So, when going from 2 to 3 open windows, window "a" and "b" switch
location for some reason. in step #2 "b" is on the left and "a" is on
the right, but when a third window is added (or removed) they swap
locations.  This is very confusing.
Configuration File
Please include the smallest configuration file that reproduces the
problem you are experiencing:
module Main (main) where

import XMonad
import XMonad.Layout.ThreeColumns

main = xmonad defaultConfig { layoutHook = ThreeColMid 1 (3/100) (1/3) }

Suggestion
There was a suggestion in the mailing list made by Daniel Wagner<EMAIL_ADDRESS>In XMonad.Layout.ThreeColumns.split3HorizontallyBy, swap the second two elements of the triple in the True branch, so that it reads:
         , Rectangle sx sy r3w sh
         , Rectangle (sx + fromIntegral r3w + fromIntegral r1w) sy r2w sh )

Checklist

[ ] I've read CONTRIBUTING.md

[ ] I tested my configuration with xmonad-testing

I've confirmed that Daniel's suggested fix does indeed seem to work.

Amazing!  Thank you so much.


Phase statuses

[ ] set statuses on comp edit form save

Works beautifully editing phases and saving now, believe after conflict fix we can :shipit:


fix Remove unused code

Proposed changes
The agg expressions can not appears in child predicates.
Issue Number: close #38905

run buildall

run buildall

run buildall