Scan speed in 0.12.4 terribly slow

Since upgrading, scans have become unbearably slow to the point that the app is unusable on my system when not much else is happening.
Debian sid on linux kernel 5.7.6 running polaris 0.12.4 in docker, scans have 4 threads capping out at about 20MB/s. Watching the logs shows no obvious errors or anything, but I can see very obvious hitching in the scan where all logging stops for a solid 20-30 seconds. The entire library is frozen up during a scan, and at these speeds, scans are taking longer than 30 minutes to finish.
Rolled back to 0.12.3, one thread is floating between 140-180MB/s with no issues using the app during the scan. I intended to look into this to see what I can do, but I really haven't had the time to put into this.
I'll try to investigate a bit in the next few days and report back.

CC https://github.com/agersant/polaris/pull/86.
As a workaround, you can set the RAYON_NUM_THREADS (spelling?). environment variable to 1, but I'm not sure what's up. Even mechanical drives work best around QD 8 or so. Is there anything strange about your hardware or software?

I gathered more data on my own machine, not seeing the performance regression.
Re-index times on a warm cache of ~3200 songs, using a Windows machine with high-end CPU and SSD:

Before #86 : 1,232,722,510 ns/iter (+/- 251,241,700)
After #86 : 711,286,870 ns/iter (+/- 336,083,405)
After #86, thread pool limited to one thread: 1,394,693,970 ns/iter (+/- 252,379,846)

The only odd thing I see in #86 that I missed in my original code review is this line using iter().par_bridge() instead of par_iter() and I'm not sure what implications this can have (I imagine not much).

On 0.12.4 with RAYON_NUM_THREADS set to 1, the scan speed did improve somewhat and the app would load a bit better during a scan.
Leaving 0.12.4 up and letting it scan a few times with a warm cache definitely has better performance. I had been switching back and forth between the versions and probably seeing high times when nothing was cached.
That said, I'm still seeing a significant drop, and no music plays until it finishes. Loading up the library/random pages or searching simply don't return anything.
Watching a scan on 0.12.3 and I do see the logs stopping while reading files, but nothing longer than a few seconds here and there reading larger flac files.
Load average is a tiny bit higher at 1.91, memory usage is the same, and there are no issues playing music/reading the library.
polaris      | 19:04:53 [INFO] [src/index/update.rs:28] Library index update took 398.872 seconds

Scanning on 0.12.4 with RAYON_NUM_THREADS unset and no other I/O going on:
polaris      | 19:15:07 [INFO] [src/index/update.rs:28] Library index update took 791.015 seconds

The scan taking a bit longer to go through 13.5k files is honestly fine, but losing playback for almost 15 minutes is rough if you're scanning frequently.
strace shows it still doing its thing when logs stop, so that might be a red herring, but I'm seeing several minute gaps at times: https://gist.github.com/vosscodes/99a53881fcb5f751e98743c045d4e78b
Not a high end CPU by any means, Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz, but even with video streaming and some other things going on in the background, load average is around 1.51 scanning on 0.12.4, and no issues show up in any other application. Memory has about 20GB free during all these scans. Assuming it's on my end, I was half expecting to see issues with the video or other read operations during a scan. Spinning disks, not SSDs, but no SMART warnings in logs or in skdump, drive status is good. Nothing special going on in the software, apart from being dockerized I guess.
Not sure what to make of this one 🤔

One night this week (or next weekend), I'll try playing with #86 to see if I can nail down exactly what's causing a drop for me.
398 might have been on the high end, even. Dropping back to 0.12.3 for now and the first scan was faster:
polaris      | 20:14:07 [INFO] [src/index/update.rs:27] Library index update took 337.637 seconds

Good news, I can also reproduce this with the Polaris install on my Raspberry Pi 4.
On master (Rocket), all requests that need to touch the filesystem stall during the index process. On the actix branch, every request everything does.

@agersant can you confirm that not using rayon is faster (because that's pretty much what this issue is about)?

I wasn't precise enough in my previous message. I mean I can reproduce the issue of unusable app, I have not looked at indexing speeds. I'll get some with/without rayon comparison of stalls and indexing speed later this week.

Will edit this post as I go:

rayon indexing
cold boot index duration
usable during index

yes

no

no

@agersant you might want to run echo 3 | sudo tee /proc/sys/vm/drop_caches between tests (unless "cold boot" is really a reboot).

I'm using Balena OS reboots, which I think are close enough to an actual unplugging of the power cable:
https://www.balena.io/docs/learn/manage/actions/#reboot

Results are in in the table above. It matches the original observations by @vosscodes.
I'm not familiar with Linux perf tooling to profile what is actually happening under the hood. My guess is that in the rayon version:

Client is unusable because the indexing is making thousands IO requests at a high-rate, from many threads. IO calls for indexing outnumber calls for request handlers by a huge factor, and the scheduler ends up mostly scheduling work for the indexing job as a result. This is somewhat confirmed by the fact that it is sometimes possible to browse the collection a bit (small amount of IO required for completion) but thumbnails never show up (lots of IO required for completion).
Indexing is slower because of context switch overhead between the rayon threads, or because doing IO on multiple files at once is harming the disk cache mechanisms, or a little bit of both.

Can you do a quick run with RAYON_NUM_THREADS=1

The HDD supports USB3 and is plugged in to a USB3 port of the Pi. I have not verified what it is actually using.
Going to run one test with RAYON_NUM_THREADS=1 (and then go to bed).

Table above updated.

Thanks. So it looks like the indexing speed regression can be mitigated by setting that env variable, but the API is still starved.
Final question (for tomorrow): what file system are you using on the HDD?

So I thought I'd try again. It's still a Celeron J1900 with a 2-HDD ZFS mirror (SATA 2 + SATA 3). One difference is that I have a bit of L2ARC (SSD cache) which is now persistent.
# rayon, drop caches
Library index update took 40.458 seconds
Library index update took 39.421 seconds
Library index update took 40.492 seconds

# sequential, drop caches
Library index update took 77.108 seconds
Library index update took 75.11 seconds
Library index update took 72.321 seconds

# rayon, reboot
Library index update took 38.785 seconds
Library index update took 38.468 seconds
Library index update took 37.633 seconds

# sequential, reboot
Library index update took 94.948 seconds
Library index update took 264.439 seconds
Library index update took 125.87 seconds

sorry to say I didn't have much time to look at this further, but observed similar results to @agersant in his table above when testing. when RAYON_NUM_THREADS=1, audio and navigation are sometimes usable but thumbnails never are. scan speed is improved, but not by a large amount.
thanks for following up on this. I should have more time in the coming weeks to help poke at things.
btw, the disk in question is ext4 and using a sata connection.

Final question (for tomorrow): what file system are you using on the HDD?

ext4

Oof. I guess we can make this a run-time configuration.

I'm not too thrilled about that perspective. The option would be hard for users to understand and evaluate, with a possibility of the client becoming unusable when they try to test it. Also of note, I found that the rayon docs explicitly recommend not using it to parallelize IO-heavy work (oops).
I spent tonight re-writing the indexer with a fairly different approach to the existing one. I split the work in three threads, one doing exclusively disk traversal and metadata reading, one computing what needs to go in the database, and one making inserts in the DB. In my brief testing so far, I am getting numbers on-par with the better ones in the table above. The client is fully usable during indexing too.
@lnicola Could you do some testing on your setup using the rocket-no-rayon-index (1b407f9987bb04e6aa3b17b10eebfef7af3a18b6)? I am curious to see where the index timing lands for you.
(@vosscodes also welcome to do some testing but I assume our configurations are fairly similar, considering results so far)

It's still slower for me, but not as slow as the sequential version:
# new indexer, drop caches
Library index update took 77.053 seconds
Library index update took 64.889 seconds
Library index update took 64.199 seconds

# new indexer, reboot
Library index update took 80.036 seconds
Library index update took 64.589 seconds
Library index update took 66.054 seconds

This looks like excellent news! I am hoping to get it a little lower but I would already call this shippable.
I am trying to figure a good way to profile which of the three threads is the bottleneck (stay tuned). I suspect in your case it's the collector thread. If that is correct, it shouldn't be too hard to parallelize its work further.

The FLAC metadata contains the duration, but IIRC MP3s don't so they need to be read.
It depends on the MP3. They can have an optional XING header which has enough information to compute the duration even for VBR files. Most of the mp3 I am testing with should have this set up correctly.

A brief investigation into CPU profiling looks like cargo flamegraph may be the way to go. Unfortunately it seems broken on Windows (even though it is supported). Not sure how valuable the output will be considering this also doesn't plot work on a time axis.
Maybe I'll just write the changes parallelizing the collector work so you can simply run it and compare.

Here is my zfs iostat output over intervals of one second for two runs:
# new indexer, 68 s
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank         820G  1.01T      0      0      0      0
tank         820G  1.01T      0      0      0      0
tank         820G  1.01T     62      0  4.38M      0
tank         820G  1.01T    123      0  27.6M      0
tank         820G  1.01T    296      0  77.0M      0
tank         820G  1.01T     37      0  6.87M      0
tank         820G  1.01T     13      0  1.28M      0
tank         820G  1.01T     51      0  4.86M      0
tank         820G  1.01T     49      0  4.42M      0
tank         820G  1.01T     52      0  5.15M      0
tank         820G  1.01T     66      0  8.21M      0
tank         820G  1.01T    310      0  59.6M      0
tank         820G  1.01T    219      0  47.1M      0
tank         820G  1.01T    138      0  31.8M      0
tank         820G  1.01T     24      0  4.98M      0
tank         820G  1.01T    227      0  47.7M      0
tank         820G  1.01T     36      0  5.36M      0
tank         820G  1.01T    101      0  71.7M      0
tank         820G  1.01T     78      0  10.1M      0
tank         820G  1.01T      0      0      0      0
tank         820G  1.01T     25      0  4.11M      0
tank         820G  1.01T    315      0  62.0M      0
tank         820G  1.01T    318      0  55.9M      0
tank         820G  1.01T    354      0  74.0M      0
tank         820G  1.01T    219      0  46.5M      0
tank         820G  1.01T    271      0  85.5M      0
tank         820G  1.01T    333      0  94.5M      0
tank         820G  1.01T    250      0  65.2M      0
tank         820G  1.01T      9      0  4.73M      0
tank         820G  1.01T    133      0  25.9M      0
tank         820G  1.01T     83      0  16.3M      0
tank         820G  1.01T      0      0      0      0
tank         820G  1.01T    144      0  22.1M      0
tank         820G  1.01T    286      0  44.8M      0
tank         820G  1.01T    316      0  61.9M      0
tank         820G  1.01T    248      0  53.7M      0
tank         820G  1.01T    295      0  98.1M      0
tank         820G  1.01T    307      0  77.7M      0
tank         820G  1.01T    333      0  71.3M      0
tank         820G  1.01T    396      0  73.6M      0
tank         820G  1.01T    401      0  73.3M      0
tank         820G  1.01T    322      0  72.8M      0
tank         820G  1.01T    298      0  87.4M      0
tank         820G  1.01T    222      0  85.3M      0
tank         820G  1.01T    240      0  67.2M      0
tank         820G  1.01T     85      0  20.7M      0
tank         820G  1.01T    188      0  52.9M      0
tank         820G  1.01T    254      0  79.7M      0
tank         820G  1.01T    267      0  83.6M      0
tank         820G  1.01T    247      0  82.5M      0
tank         820G  1.01T    257      0  65.3M      0
tank         820G  1.01T    238      0  64.6M      0
tank         820G  1.01T    254      0  57.7M      0
tank         820G  1.01T    279      0  74.3M      0
tank         820G  1.01T    253      0  77.8M      0
tank         820G  1.01T    248      0  80.3M      0
tank         820G  1.01T    253      0  64.8M      0
tank         820G  1.01T    253      0  69.6M      0
tank         820G  1.01T    193      0  38.6M      0
tank         820G  1.01T    110      0  14.9M      0
tank         820G  1.01T    170      0  36.0M      0
tank         820G  1.01T    128      0  21.2M      0
tank         820G  1.01T     93      0  19.8M      0
tank         820G  1.01T    108      0  22.7M      0
tank         820G  1.01T    138      0  25.6M      0
tank         820G  1.01T    127      0  30.7M      0
tank         820G  1.01T    126      0  27.0M      0
tank         820G  1.01T    109      0  23.9M      0
tank         820G  1.01T     99      0  19.1M      0
tank         820G  1.01T     11      0  1.99M      0
tank         820G  1.01T      0      0      0      0
tank         820G  1.01T      0      0      0      0

# master, 38 s
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank         820G  1.01T      0      0   127K      0
tank         820G  1.01T      0      0      0      0
tank         820G  1.01T     75      0  11.2M      0
tank         820G  1.01T    319      0  83.8M      0
tank         820G  1.01T    284      0  95.4M      0
tank         820G  1.01T    255      0   112M      0
tank         820G  1.01T    252      0   101M      0
tank         820G  1.01T    278      0  93.7M      0
tank         820G  1.01T    214      0  90.4M      0
tank         820G  1.01T    222      0  74.8M      0
tank         820G  1.01T    278      0  70.0M      0
tank         820G  1.01T    232      0  49.2M      0
tank         820G  1.01T    283      0  76.9M      0
tank         820G  1.01T    251      0  92.3M      0
tank         820G  1.01T    241      0  81.6M      0
tank         820G  1.01T    183      0  59.9M      0
tank         820G  1.01T    234      0  79.8M      0
tank         820G  1.01T    227      0  77.8M      0
tank         820G  1.01T    239      0  90.4M      0
tank         820G  1.01T    197      0  79.0M      0
tank         820G  1.01T    257      0  87.9M      0
tank         820G  1.01T    260      0  93.6M      0
tank         820G  1.01T    265      0  83.1M      0
tank         820G  1.01T    255      0  79.8M      0
tank         820G  1.01T    275      0  74.0M      0
tank         820G  1.01T    223      0  67.8M      0
tank         820G  1.01T    240      0  71.1M      0
tank         820G  1.01T    256      0  71.7M      0
tank         820G  1.01T    237      0  71.6M      0
tank         820G  1.01T    243      0  79.7M      0
tank         820G  1.01T    210      0   111M      0
tank         820G  1.01T    230      0  72.3M      0
tank         820G  1.01T    226      0  74.0M      0
tank         820G  1.01T    239      0  83.5M      0
tank         820G  1.01T    224      0  69.9M      0
tank         820G  1.01T    190      0  68.7M      0
tank         820G  1.01T    196      0  68.8M      0
tank         820G  1.01T    216      0  87.0M      0
tank         820G  1.01T    223      0  69.9M      0
tank         820G  1.01T    169      0  49.9M      0
tank         820G  1.01T      0      0      0      0

So it looks like the new implementation sometimes can't feed enough read requests to the disk.

Here is some perf output for that thread (or process, I'm not really sure):
   6.78%  [kernel]                   [k] memcpy_erms
   5.16%  libc-2.32.so               [.] __memmove_sse2_unaligned_erms
   4.46%  [kernel]                   [k] clear_page_erms
   3.07%  [kernel]                   [k] copy_user_enhanced_fast_string
   2.75%  polaris                    [.] mp3_duration::from_file
   2.66%  polaris                    [.] <std::io::buffered::bufreader::BufReader<R> as std::io::Read>::read
   2.64%  [zfs]                      [k] lz4_decompress_zfs
   1.78%  [kernel]                   [k] preempt_count_add
   1.51%  [kernel]                   [k] mutex_lock
   1.49%  libc-2.32.so               [.] _int_malloc
   1.47%  polaris                    [.] std::io::Read::read_exact
   1.09%  libc-2.32.so               [.] _int_free
   1.00%  [kernel]                   [k] memset_erms
   0.99%  polaris                    [.] std::io::copy::generic_copy
   0.98%  polaris                    [.] mp3_duration::context::Context<T>::read_exact
   0.90%  libc-2.32.so               [.] malloc
   0.88%  [kernel]                   [k] _raw_spin_lock
   0.88%  [kernel]                   [k] mutex_unlock
   0.85%  [zfs]                      [k] zio_create
   0.79%  [zfs]                      [k] dbuf_rele_and_unlock
   0.77%  [kernel]                   [k] kmem_cache_alloc
   0.73%  [kernel]                   [k] __kmalloc_node
   0.67%  [kernel]                   [k] preempt_count_sub
   0.64%  [kernel]                   [k] kmem_cache_free
   0.63%  [kernel]                   [k] __fsnotify_parent
   0.61%  [zfs]                      [k] dmu_buf_hold_array_by_dnode
   0.61%  [kernel]                   [k] kfree
   0.59%  polaris                    [.] metaflac::block::VorbisComment::from_bytes
   0.56%  [zfs]                      [k] dbuf_hold_impl
   0.52%  [kernel]                   [k] in_lock_functions
   0.52%  [spl]                      [k] spl_kmem_cache_alloc
   0.51%  [zfs]                      [k] zio_wait
   0.48%  [zfs]                      [k] zio_done
   0.47%  libc-2.32.so               [.] realloc
   0.46%  libc-2.32.so               [.]<EMAIL_ADDRESS>

Thanks for the data, these are very interesting. My guess was wrong and looks like traverser is the bottleneck then, not collector.
What surprises me the most is that the bandwidth peaks around the same high of 95MBps but is much lower on average with the new indexer. There's even a few seconds with no data being read at all?? That thread does basically nothing except reading the disk so I don't understand what could be keeping it busy for an entire second at any point.

That's the IO that actually hits the storage. There might be some prefetching or caching involved.

The ignore crate has a parallel file system iterator that might be worth trying.

I tried using the ignore crate but its API does not fir our needs very well. It uses a visitor pattern for individual files, but Polaris needs to have eyes on all files within a directory at the same time (to determine metadata for the directory itself).
Instead, I multi-threaded the traverser work myself, by closely referencing the ignore implementation. The results have broken all speed records on the Raspeberry Pi setup and one my dev machine. I updated the table in the comment above with these new results. Client is still very responsive throughout so I except this is the version that will ship.
This variant defaults to using 4 threads for the traverser, unless the machine has less than 4 logical cores. This number can be manually set with the POLARIS_NUM_TRAVERSER_THREADS. I picked 4 as the default because that's the number after which I stopped getting significantly better times when testing on the Windows machine.

# new indexer (take 2), drop caches
Library index update took 92.975 seconds
Library index update took 85.283 seconds
Library index update took 79.178 seconds

# new indexer (take 2), reboot
Library index update took 104.042 seconds
Library index update took 55.745 seconds
Library index update took 96.143 seconds

So it got even slower for me.

Well, it did fix the issue of the disk not being used to read a consistently high amount of data (assuming the column measured in Megabytes in zpool iostat is the bandwidth column in your prior zfs stat).
Can you try some variations on the number of threads using POLARIS_NUM_TRAVERSER_THREADS?
I'm even more lost than before. It's especially weird how much the timings fluctuate in this last test. From 55s to 104s with the same code is very high variance. For the perf captures, can you use the -g option (possibly with  --max-stack 6) so it's a little clearer what the code is busy doing?
I'm not a fan of the mutex and sleep but that's what used in ripgrep/ignore so I figured it was good enough for me too. I originally used a crossbeam channel for this but I drove myself into a corner because I didn't have the num_pending atomic. I'll try again now that I have this extra wisdom - although I don't expect a big perf difference.

I'm having issues deploying it to my Raspberry Pi, but if you want to try the version without the mutex/sleep channel, it's in eb39835e2a9201ba429f3c85437c2776fb829895.

I guess I should just concede that my system is behaving in an unusual way, perhaps due to the particularities of ZFS.
# crossbeam_channel, drop caches
Library index update took 108.789 seconds
Library index update took 93.615 seconds
Library index update took 89.814 seconds

# crossbeam_channel, reboot
Library index update took 94.242 seconds
Library index update took 71.395 seconds
Library index update took 73.828 seconds

Well, at the very least we got a new indexer out of this - which looks better than the previous one and solves stalling issues.
Merged in https://github.com/agersant/polaris/pull/107

Fixed in release 0.13


v4.2.0 GA release

v4.2.0 GA Release

AppVeyor build and test fail.

AppVeyor build and test pass.


⚠ Bofrost.at has degraded performance

In f1d2848, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2267 ms

Resolved: Bofrost.at performance has improved in d2021d8.


Adding localization text in niveristand-instrument-addon-cd-LabVIEW- Support in control page

[x] This contribution adheres to CONTRIBUTING.md.

TODO: Check the above box with an 'x' indicating you've read and followed CONTRIBUTING.md.
TODO: Include high-level description of the changes in this pull request.
As part of User Story (https://ni.visualstudio.com/DevCentral/_workitems/edit/2665528/) We are trying to include localization description for Chinese, German, Japanese, French, Korean languages for different VeriStand third party products.
TODO: Justify why this contribution should be part of the project.
Taken reference from VeriStand control page (\argo\ni\nipkg\pool\ni-v\ni-veristand-2024\24.0.0\<IP_ADDRESS>451-0+f299\ni-veristand-2024_<IP_ADDRESS>451-0+f299_windows_x64.nipkg.control) and edited niveristand-instruments-addon-cd-LabVIEW-Support control page accordingly.
TODO: Detail what testing has been done to ensure this submission meets requirements.
Testing is in progress

/AzurePipelines run


Repository.show() returns wrong file contents to GHPRI extension

In the latest RemoteHub pre-release, https://insiders.vscode.dev/github/microsoft/vscode/pull/142606 turns up no diff on the first try, then an empty LHS on the second try.

That error message comes from: https://github.com/microsoft/vscode-pull-request-github/blob/dae6028f027a7500be09045b5f2b6294d7f0355a/src/view/gitContentProvider.ts#L54-L58 The message is a bit misleading since there is no 'local' repository when running in web.
There's two mysteries here:

Why is no Repository object returned sometimes? I see a reference in GHPRI to vscode.Uri.file, which is a bit suspect since that returns file:// URIs and RemoteHub has vscode-vfs:// URIs, but the getRepositoryForFile function seems to look at the uri.path so that should be fine...
Why is GHPRI asking RemoteHub to getObjectDetails for 8d9562?

Now I also see the LHS of the first diff coming back empty for other PRs like https://github.dev/dotnet/roslyn/pull/57667

Possibly race condition with initializing the IGit API?

Yes, I'm pretty sure that's what this is. I have an issue for it so I'll try to fix it today: https://github.com/microsoft/vscode-pull-request-github/issues/3242. This notification occurs when you refresh a tab with a PR in it and the diff editor tries to restore. Because there's a race, we don't have the required information yet to restore.
I don't think this message is related since the inputs I could see going into Repository.show when a PR in the tree is clicked on look correct.
I could repro the left hand being empty or wrong for many PRs.

Worth clarifying: when this happens it is not only the first diff, it is all diffs in the PR.
I've added the following log line:
[Info] GitContentFileSystemProvider> Getting repository (vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a22313432363036227d7d/microsoft/vscode) content for commit ec9df1d972f05f960a2f4660e6feca1ebf20d39a and path /microsoft/vscode/src/vs/workbench/api/browser/mainThreadAuthentication.ts

right before calling repository.show. This lets us confirm:

That we actually have a repository
The commit. This should be the commit from the base branch that the PR compares against, ie., the parent of the first commit in the PR.
The file in question.

All the arguments for this look correct to me.
I am kicking off a new pre-release build of GHPRI with this logging + the fix for https://github.com/microsoft/vscode-pull-request-github/issues/3242.

If I sign out of GitHub for all extensions and then reload the page, I'm still seeing the LHS open completely empty and the error about not being able to find an open repository locally, with GHPRI v0.37.2022021409. When that happens, this is what the GHPRI log says:
[Info] TemporaryState> Error in initialization: Unable to delete nonexistent file 'vscode-userdata:/User/globalStorage/github.vscode-pull-request-github/temp'
[Info] Looking for git repository
[Info] Found 0 repositories during activation
[Info] Git repository found, initializing review manager and pr tree view.
[Info] Registering git provider
[Info] GitContentFileSystemProvider> Waiting for repositories.
[Info] GitContentFileSystemProvider> Timed out while waiting for repositories.
[Info] Repository vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn has been opened
[Info] Review> Validate state in progress
[Info] Review> Validating state...
[Info] Found GitHub remote
[Info] Review> current branch metadataOnlyEmitXmlDocs is associated with pull request #57667
[Info] Review> Resolving pull request
[Info] Review> Queuing additional validate state
[Info] Review> Queuing additional validate state
[Info] Found GitHub remote
[Info] Found GitHub remote
[Info] Found GitHub remote
[Info] Found GitHub remote
[Info] Review> Fetching pull request data
[Info] Review> register comments provider
[Info] Review> display pull request status bar indicator and refresh pull request tree view.
[Info] Review> using focus mode = true.
[Info] Review> state validation silent = true.
[Info] Review> PR show should show = https://github.com/dotnet/roslyn/pull/57667.
[Info] Review> Validating state...
[Info] Found GitHub remote
[Info] Trying to use globalState for mentionable users.
[Info] Using globalState mentionable users for 1.
[Info] Review> Validating state...
[Info] Found GitHub remote
[Info] Trying to use globalState for mentionable users.
[Info] Using globalState mentionable users for 1.
[Info] Repo state for vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn changed.
[Info] Repo vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn has already been setup.

Then when I reload the page again, I am already signed in, now I see a diff view with no changes, but only for the first file that is opened in the diff editor. All subsequent changed files do have the right contents, and additionally closing and reopening the first diff results in the right contents being shown...
[Info] TemporaryState> Error in initialization: Unable to delete nonexistent file 'vscode-userdata:/User/globalStorage/github.vscode-pull-request-github/temp'
[Info] Looking for git repository
[Info] Found 0 repositories during activation
[Info] Git repository found, initializing review manager and pr tree view.
[Info] Registering git provider
[Info] Review> Validate state in progress
[Info] Review> Validating state...
[Info] Found GitHub remote
[Info] Review> current branch metadataOnlyEmitXmlDocs is associated with pull request #57667
[Info] Review> Resolving pull request
[Info] Review> Fetching pull request data
[Info] Review> register comments provider
[Info] Review> display pull request status bar indicator and refresh pull request tree view.
[Info] Review> using focus mode = true.
[Info] Review> state validation silent = true.
[Info] Review> PR show should show = https://github.com/dotnet/roslyn/pull/57667.
[Info] Repo state for vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn changed.
[Info] Repo vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn has already been setup.
[Info] GitContentFileSystemProvider> Getting repository (vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn) content for commit aad378eca3bdbf9dc369c015b0668a778b0dd2e4 and path /dotnet/roslyn/src/Compilers/CSharp/Portable/Compilation/CSharpCompilation.cs

and (truncated for length) RemoteHub logs are:
[2022-02-14 17:41:50:680] [  122] IGit.getObjectDetails(aad378eca3bdbf9dc369c015b0668a778b0dd2e4, src/Compilers/CSharp/Portable/Compilation/CSharpCompilation.cs)
[2022-02-14 17:41:50:681] [  124] GitHub.createFileTree(github://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn:aad378eca3bdbf9dc369c015b0668a778b0dd2e4)
[2022-02-14 17:41:50:681] [  125] FileTree.load(aad378eca3bdbf9dc369c015b0668a778b0dd2e4:undefined)
[2022-02-14 17:41:50:682] [  124] GitHub.createFileTree(github://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn:aad378eca3bdbf9dc369c015b0668a778b0dd2e4) took 0 ms
[2022-02-14 17:41:50:682] [  123] GitHub.getFileTree(github://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn:aad378eca3bdbf9dc369c015b0668a778b0dd2e4): vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn took 0 ms
[2022-02-14 17:41:50:740] [  126] [GITHUB] GET /repos/{owner}/{repo}/git/trees/{tree_sha} took 58 ms
[2022-02-14 17:41:50:741] [  125] FileTree.load(aad378eca3bdbf9dc369c015b0668a778b0dd2e4:undefined): Tree=aad378eca3bdbf9dc369c015b0668a778b0dd2e4; Tree query took 59 ms • Waiting for permissions...
[2022-02-14 17:41:50:741] [  125] FileTree.load(aad378eca3bdbf9dc369c015b0668a778b0dd2e4:undefined) Permissions query took 0 ms • Filling trie...
[2022-02-14 17:41:50:741] [  125] FileTree.load(aad378eca3bdbf9dc369c015b0668a778b0dd2e4:undefined) took 59 ms (Filling trie took 0 ms) • Tree=aad378eca3bdbf9dc369c015b0668a778b0dd2e4
[2022-02-14 17:41:50:741] [  127] FileTree.load(aad378eca3bdbf9dc369c015b0668a778b0dd2e4:src)
[2022-02-14 17:41:50:743] [  121] [GITHUB] POST /graphql query getRemoteBranchTips took 291 ms
[2022-02-14 17:41:50:743] [  120] GitHub.fetch(vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn, force=undefined, to=undefined) took 296 ms • Up to date
[2022-02-14 17:41:50:743] [  129] VirtualProviderService.updateMetadata(vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn) — c4591e910af9c444c8f8baa4bdf5523ae5625ab5
[2022-02-14 17:41:50:743] [  130] MementoStorage.store(metadata/vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn): scopedKey=5ec3b4c1/metadata/vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn
[2022-02-14 17:41:50:937] [  130] MementoStorage.store(metadata/vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn): scopedKey=5ec3b4c1/metadata/vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn took 193 ms
[2022-02-14 17:41:50:937] [  129] VirtualProviderService.updateMetadata(vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn) took 194 ms
[2022-02-14 17:41:50:957] VirtualProviderService.onMetadataChanged(vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn, reason=undefined): Firing onDidChangeRepository...
[2022-02-14 17:41:50:957] [  131] (A) Writer(3|WorkspaceRepositories) • WorkspaceRepositories.addOrUpdate
[2022-02-14 17:41:50:957] [  132] RichNavIndexProvider.createIndexMetadata(vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn)
[2022-02-14 17:41:50:959] [  131] (L) Writer(3|WorkspaceRepositories) waited for 2 ms • WorkspaceRepositories.addOrUpdate
[2022-02-14 17:41:50:959] [  133] MementoStorage.get(workspaceRepositories): scopedKey=workspaceRepositories
[2022-02-14 17:41:50:961] [  133] MementoStorage.get(workspaceRepositories): scopedKey=workspaceRepositories took 1 ms
[2022-02-14 17:41:50:965] [  132] RichNavIndexProvider.createIndexMetadata(vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn) Getting metadata took 7 ms • Getting snapshot...
[2022-02-14 17:41:50:965] [  134] GitHub.ensureAuthenticated
[2022-02-14 17:41:50:965] [  134] GitHub.ensureAuthenticated took 0 ms
[2022-02-14 17:41:50:971] [  132] RichNavIndexProvider.createIndexMetadata(vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn) Getting snapshot took 6 ms • Getting mode config...
[2022-02-14 17:41:50:972] [  132] RichNavIndexProvider.createIndexMetadata(vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn) took 14 ms (Getting mode config took 0 ms)
[2022-02-14 17:41:50:977] [  135] (A) Reader(5|vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn) • ChangeStore.getChangesByType(vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn)
[2022-02-14 17:41:51:004] [  135] (L) Reader(5|vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn) waited for 26 ms • ChangeStore.getChangesByType(vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn)
[2022-02-14 17:41:51:004] [  136] (A) Reader(6|vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn) • ChangeStore.getChanges(vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn)
[2022-02-14 17:41:51:005] [  135] (U) Reader(5|vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn) locked for 1 ms • ChangeStore.getChangesByType(vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn)
[2022-02-14 17:41:51:005] [  136] (L) Reader(6|vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn) waited for 0 ms • ChangeStore.getChanges(vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn)
[2022-02-14 17:41:51:007] [  136] (U) Reader(6|vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn) locked for 2 ms • ChangeStore.getChanges(vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a332c226964223a223537363637227d7d/dotnet/roslyn)
[2022-02-14 17:41:51:008] [  137] MementoStorage.store(workspaceRepositories): scopedKey=workspaceRepositories
[2022-02-14 17:41:51:092] [  128] [GITHUB] GET /repos/{owner}/{repo}/git/trees/{tree_sha} took 349 ms
[2022-02-14 17:41:51:092] [  127] FileTree.load(aad378eca3bdbf9dc369c015b0668a778b0dd2e4:src): Tree=d49d0920f5cf9c733677a9b678e60debf2e9719b; Tree query took 350 ms • Waiting for permissions...
[2022-02-14 17:41:51:092] [  127] FileTree.load(aad378eca3bdbf9dc369c015b0668a778b0dd2e4:src) Permissions query took 0 ms • Filling trie...
[2022-02-14 17:41:51:092] [  127] FileTree.load(aad378eca3bdbf9dc369c015b0668a778b0dd2e4:src) took 350 ms (Filling trie took 0 ms) • Tree=d49d0920f5cf9c733677a9b678e60debf2e9719b
[2022-02-14 17:41:51:092] [  138] FileTree.load(aad378eca3bdbf9dc369c015b0668a778b0dd2e4:src/Compilers)

I was able to repro in vscode.dev and insiders.vscode.dev earlier today, but the repro is flaky and I can't repro anymore in insiders.vscode.dev. I still cannot repro this at all in the extension development host. I have added some debug logging in RemoteHub to continue to gather information.

@alexdima has also run into this with pressing "." on https://github.com/microsoft/vscode/pull/145293/files. I was also able to repro with those steps. Interestingly, the first diff actually opens ok there, but subsequent diffs do not.

I very often see no diff when I click on a change in a PR in github.dev, but it seems quite random only for some files of the PR, not all.

Closing as duplicate of https://github.com/microsoft/vscode-remote-repositories-github/issues/177 which should be resolved in the latest pre-release of RemoteHub.


SCRD-5089 openstack-ardana template

Implements top-level Ardana Jenkins jobs as copies of the existing
openstack-ardana pipeline job instead of triggering openstack-ardana.
This approach has the following advantages over having a single
pipeline job triggered by all top-level Ardana Jenkins jobs:

fewer levels of indirection: the user doesn't need to navigate
the job hierarchy to get to the pipeline UI layout
dedicated history: every top-level job has an individual history
of pipeline job runs, execution times, results, trends, etc, which
is no longer polluted by gerrit triggered jobs or custom builds
triggered manually by users for testing purposes

With these changes in place, the openstack-ardana job will only be
triggered by gerrit changes and manually by users e.g. for testing
purposes. The component pipelines (e.g. openstack-ardana-tempest)
are not templated and will continue to be used in common by all top-level
pipeline jobs.
This PR  also improves the collection of Jenkins artifacts by passing this
responsibility to the master openstack-ardana job, if one is
present. The tempest JUnit test case results are also collected
by the master openstack-ardana job, which allows a tracking record
to be maintained independently by each main job.

Tested with https://ci.suse.de/job/cloud-ardana9-job-gerrit-x86_64-snica/ and https://ci.suse.de/job/cloud-ardana8-job-std-min-x86_64-snica/

Depends on #2827

rebased


New MOAB API

I did a bunch of global find and replace to accommodate the new MOAB API. Everything compiles and I was able to run an example problem.

@elliottbiondo I did the same thing last night. Using this version will be better though as it comes with a PR so we'll do that. I'm going to check it out to double check the compile and then I'll merge.

What a strange coincidence!

Indeed. There's a 2 line diff between my branch and yours :) Everything compiles. Merging...


Generalized PNG pane for any image-based mimetype and added jpg and gif

The only bits of the PNG pane that were specific to PNGs were the characters "png" and the code for determining the filesize, so I made those overridable at the class level and added implementations for JPG and GIF.
The code for JPG filesizes is a bit complex, so instead of these changes, we could consider adding a pillow-based filesize computation shared across all the Image classes; I have no strong preference.
The resulting images work well in a Column:
import panel as pp
pp.extension()

pp.Column("http://pyviz.org/_static/pyviz-logo.png",
          "http://homepages.inf.ed.ac.uk/jbednar/images/20051029_03cx083_[Calton_Hill]_crop.jpg",
          "http://homepages.inf.ed.ac.uk/jbednar/images/NeuralComputation12_7.gif",
          "http://homepages.inf.ed.ac.uk/jbednar/images/981109_or_map_2048MB.020000.spinanim_icon.gif")

(where the final image would be animated if this weren't a screenshot).
They don't always work well in a Row, sometimes overlapping and sometimes reserving too much space:
pp.Row("http://pyviz.org/_static/pyviz-logo.png",
       "http://homepages.inf.ed.ac.uk/jbednar/images/20051029_03cx083_[Calton_Hill]_crop.jpg",
       "http://homepages.inf.ed.ac.uk/jbednar/images/NeuralComputation12_7.gif"
       "http://homepages.inf.ed.ac.uk/jbednar/images/981109_or_map_2048MB.020000.spinanim_icon.gif")

However, I don't think that's anything to do with this PR, because for the previously supported (PNG) type I get the same overlapping behavior for master and for this branch's code:
import panel as pp
pp.extension()

pp.Row("http://pyviz.org/_static/pyviz-logo.png",
       "http://pyviz.org/_static/pyviz-logo.png",
       "http://pyviz.org/_static/pyviz-logo.png")

I would guess that's a Bokeh layout issue that's being addressed separately?

Codecov Report

Merging #27 into master will decrease coverage by 0.68%.
The diff coverage is 55.81%.

@@            Coverage Diff             @@
##           master      #27      +/-   ##
==========================================
- Coverage   92.87%   92.18%   -0.69%
==========================================
  Files          19       19
  Lines        2287     2316      +29
==========================================
+ Hits         2124     2135      +11
- Misses        163      181      +18

Impacted Files
Coverage Δ

panel/pane.py
79.03% <55.81%> (-4.55%)
:arrow_down:

Continue to review full report at Codecov.

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


Backport #534 to 1.18

@Insprill Please fix as many of those Code Smells as possible and then this is good to merge

Alright, I've also backported a small portion of #474 so that should hopefully make SonarCloud stop complaining.


Menu Item Icons

The 'icon' option of MenuItem doesn't seem to work with custom-electron-titlebar. Is it supported?

It is not supported at this time. But when I have time, I'll work on this and other issues.


Wrong back button behavior

The back button behaves wrong, at least on android 11 with latest chrome.
Steps to reproduce:

Visit Example Page and open Hello World Example
Click on To Detail
Click on Back
Click android back button or use back gesture

Expected Behaviour:
The last website you visited is loaded.
Actual Behaviour:
Nothing happens. You need to use the back button again to trigger the expected behaviour.
The same happens when you use the back button after clicking To Detail

Thank you for your feedback.

Remove onExit option(hotfix). replace with backAgainToExit option on v1.4.0, And fixed this BUG. Thanks again.


Custom Form Styles Not Being Applied

I am using Next.js v9.1.2.  I have Tailwind and the plugin installed and added to my tailwind.config.ts file however the styles are not being picked up.
package.json:
  "devDependencies": {
    "@tailwindcss/custom-forms": "^0.2.1",
    "autoprefixer": "^9.7.1",
    "postcss-easy-import": "^3.0.0",
    "postcss-preset-env": "^6.7.0",
    "tailwindcss": "^1.1.3",
    "tslint": "^5.20.1",
    "tslint-config-prettier": "^1.18.0",
    "tslint-react": "^4.1.0"
  },

tailwind.config.ts:
export default module.exports = {
  theme: {
    extend: {}
  },
  variants: {},
  plugins: [
    require('@tailwindcss/custom-forms')
  ]
}

Component:
return (

        {props.label}
        <select
          className="form-select block w-full mt-1"
          onChange={props.onChange}
          onBlur={props.onBlur}
        >
          {props.options.map((option, idx) => {
            return (
              <option key={idx} value={option.value} label={option.label}>
                {option.label}
              </option>
            );
          })}
        </select>

  );

In broswer:

css:

This is in Chrome Version 78.0.3904.70 (Official Build) (64-bit) on Mac 10.14.2

Are you passing tailwind.config.ts to Tailwind? It will look for tailwind.config.js by default.

Thank you @hacknug, that was the issue.


PR part 1

This PR makes the LICENSE and README look better! No wiki changes unfortunately since github doesn't let you do that but I can just copy the Markdown to the main wiki when I get contributor access!

I think there is some stuff that needs to be changed (didn't expect this to be merged but it looks fine for now, for instance Draylar should probably be added to the list too)

I merged it to the 1.17 branch since it seems it has more recent commits (5 months ago compared to 8)


[Unity] Relation Query Fails with error on iOS.

Error: Query a relation: Must specify a ParseObject class name when creating a ParseQuery.
Unity: We are using 4.6.7 but it also happens on 4.6.8.
Parse plugin 1.6.1 for Unity.
Xcode 6.4
When Querying a relation, we started getting this error after updating parse.

It only happens on iOS, and not in the Unity editor. Query also works in API console.
Did not happen in older version of Parse.

We are querying a relation in this manner:
var FBFriendsRelation = ParseUser.CurrentUser.GetRelation ("FBFriends");
if (FBFriendsRelation != null) {
ParseQuery q = FBFriendsRelation.Query;
In Xcode, the error happens on the final line. We tried this with a stub project that only does this query, and get the same result.

I think this is the same as #72.

Yep, I think you're correct. Currently my unity installation isn't fully working so I can't test ATM, but I'm going to close this for now. Feel free to re-open it if the problem persists.

@richardjrossiii still occurring on 1.7.0.

I'll take another look at this.

I'm getting this error as well when switching to IL2CPP. With Mono 2.0, relations work properly.


Explicitly use @bg_color when clearing background for scroll.

Sometimes @attrs.bg_color is set, which caused incorrect background coloring.
Fixes #21

Thanks!


How to document breaking changes in the changelogs (with changsets)

Our main branch currently reflects the design system version 9 (next).
If we add changesets with a major update there, will this lead us to end up having a v10 output, as soon as we exit the changeset pre mode?
On the other side, if the above made assumption is right, how should we document breaking changes from v8 to v9 then?

Not a problem.
After 9.x.x-next.x a version 9.0.0 should be produced.


Stacked NFT: Which NFT is mine?

I have two same NFTs from one collection of KodaChains. My profile. Im unable to open my NFT. I mean, if you open any other (non stacked NFT) it will redirect you to the specific NFT page. But if you click on the stacked NFTs in my profile it will open the collection. So now - which NFT is mine? How do I open it  If I want to burn one or just see my NFT - when they are stacked in my profile, I can logically open both of them at once. I have to search one by one in collection? And try to figure out which is mine? (https://github.com/kodadot/nft-gallery/issues/7340: this may help in this case?)
Video:
https://github.com/kodadot/nft-gallery/assets/104380776/f5deb8b7-ac9c-4a4d-a441-d5c213a24b90
Idk if you understand what I mean. Point of stacked NFTs was to have editions on one pile. When artists mint their NFTs in editions. Like objkt has:

Do it in a way that Im also able to do something with NFTs (burn them without searching for them). I think we need to rethink stacking experience somehow. Do stacking v2 or something like that. We use stacking in profiles, explorer but in in collections when you open them. Would be good if we had a better logic. We can get inspired by other marketplaces. Also stacked NFT preview is ugly

quick solution:

I will come up with better solution tho

so...
what needs to be done here @exezbcz ?


Fix broken src path for rtc-ipmessaging

new version of script file name take a dash.
the one in public/js folder does not.

This was caught in a newer version -- Thanks for the PR!


bench: use .pytest_cache as tmpdir for running benchmarks

This makes it possible to test Linux where tmpdir is using tmpfs rather than the filesystem that supports reflink.
Also we run test for 1000 links, but run 10 rounds (with 3 warmup rounds) for better results, as a single test may be noisy.

Codecov Report
Attention: 13 lines in your changes are missing coverage. Please review.

Comparison is base (da02e76) 64.26% compared to head (134653f) 62.35%.

Files
Patch %
Lines

tests/benchmarks/test_fs.py
50.00%
12 Missing :warning:

src/dvc_objects/fs/system.py
0.00%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #242      +/-   ##
==========================================
- Coverage   64.26%   62.35%   -1.92%
==========================================
  Files          27       27
  Lines        2040     2040
  Branches      323      324       +1
==========================================
- Hits         1311     1272      -39
- Misses        669      708      +39
  Partials       60       60

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


Removing the grey background from menu items

How would I remove the default grey background from the menu items? I just want to use icons.

remove the background tag in the main menu declaration!


Missing support for batch sending

Is your feature request related to a problem? Please describe.
https://resend.com/docs/api-reference/emails/send-batch-emails

Hi there,
Thank you for your feedback! I'm happy to inform you that support for batch sending has been added in version 1.0.1. You can now send multiple requests in one go, which should enhance your experience.
Please try it out and let me know if you have any further questions or suggestions!
Best regards,
Paul


Gekko GUI not working after launching docker containers

Note: for support questions, please join our Discord server

I'm submitting a ...
[* ] bug report
[ ] feature request
[ ] question about the decisions made in the repository

Action taken (what you did)

Expected result (what you hoped would happen)
Working UI
http://:3000 should be working

Actual result (unexpected outcome)
Not working

Disconnected
Something happened to either Gekko or the connection. Please check the terminal where Gekko is running or your network connection.

Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, etc)

root@babatundebusari:~/gekko# docker-compose ps
    Name                   Command               State           Ports
-------------------------------------------------------------------------------
gekko_gekko_1   /usr/src/app/docker-entryp ...   Up      <IP_ADDRESS>:3000->3000/tcp
gekko_redis_1   docker-entrypoint.sh redis ...   Up      6379/tcp
root@babatundebusari:~/gekko# docker-compose ps
    Name                   Command               State           Ports
-------------------------------------------------------------------------------
gekko_gekko_1   /usr/src/app/docker-entryp ...   Up      <IP_ADDRESS>:3000->3000/tcp
gekko_redis_1   docker-entrypoint.sh redis ...   Up      6379/tcp
root@babatundebusari:~/gekko# docker logs -f gekko_gekko_1
npm info it worked if it ends with ok
npm info using<EMAIL_ADDRESS>npm info using<EMAIL_ADDRESS>npm info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>npm info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>
><EMAIL_ADDRESS>start /usr/src/app
> node ./gekko --config config.js --ui

    ______   ________  __    __  __    __   ______
   /      \ /        |/  |  /  |/  |  /  | /      \
  /$$$$$$  |$$$$$$$$/ $$ | /$$/ $$ | /$$/ /$$$$$$  |
  $$ | _$$/ $$ |__    $$ |/$$/  $$ |/$$/  $$ |  $$ |
  $$ |/    |$$    |   $$  $$<   $$  $$<   $$ |  $$ |
  $$ |$$$$ |$$$$$/    $$$$$  \  $$$$$  \  $$ |  $$ |
  $$ \__$$ |$$ |_____ $$ |$$  \ $$ |$$  \ $$ \__$$ |
  $$    $$/ $$       |$$ | $$  |$$ | $$  |$$    $$/
   $$$$$$/  $$$$$$$$/ $$/   $$/ $$/   $$/  $$$$$$/

	Gekko v0.5.6
	I'm gonna make you rich, Bud Fox.

TAlib is enabled
Serving Gekko UI on http://localhost:3000/

  <-- GET /favicon.ico
  --> GET /favicon.ico 404 6ms -

here is what i get with curl
root@babatundebusari:~/gekko# curl -s http://<IP_ADDRESS>:3000
<!DOCTYPE html>

    <meta charset="utf-8">
    <title>Gekko</title>
    <link rel="stylesheet" href="/assets/furtive.min.css">

@askmike @jonrh @williamcoates @metachris @iceydee
anyone willing to help here?
urgently will like to check this out
and i am running latest code but with these errors
please help

Could you post the docker compose options you used to build?
On 1 Sep 2017 20:45, "babatundebusari"<EMAIL_ADDRESS>wrote:

@askmike https://github.com/askmike @jonrh https://github.com/jonrh
@williamcoates https://github.com/williamcoates @metachris
https://github.com/metachris @iceydee https://github.com/iceydee
anyone willing to help here?
urgently will like to check this out
and i am running latest code but with these errors
please help
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/askmike/gekko/issues/1065#issuecomment-326668512, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA7MD38EjVmevJ7jlRubB-fMnFwQsTdtks5seF7EgaJpZM4PKhVn
.

I could be wrong but shouldn't the UIconfig be updated to use http://<IP_ADDRESS>:3000 as the api if you run it on a external server

ok tried this passing the HOST and PORT options and now it works
root@babatundebusari:~/gekko# HOST=gekko.com PORT=8080 docker-compose up -d
Creating gekko_redis_1 ...
Creating gekko_redis_1 ... done
Creating gekko_gekko_1 ...
Creating gekko_gekko_1 ... done

Great!
@zeroX-tj when using Docker compose the UIConfig is generated using docker :)

I was have the same issue, receiving disconnected error.
I was able to get gekko running without issue by using docker-compose in the repo.
Dont give up

Hi @askmike - im getting exactly the same issue - ive been struggling for a few days trying to debug this on my own - but its time to ask for help as im getting nowhere!
1/ i did a git clone of your full repo (probably unnecessary as im running the docker instance of your app- but at least i get the docker-compse.yml!)
2/ followed the instructions here  https://gekko.wizb.it/docs/installation/installing_gekko_using_docker.html
3/ hit the GUI on port :3000  (from either localhost, or over my local network to the machine IP)
4/ straight away get bounced with the "Disconnected" popup.
my docker-compose is this:
`keiran@vm-ubuntu:/_LOCALDATA/CONTAINERS/gekko$ cat docker-compose.yml
version: '3'
services:
gekko:
restart: always
build: ./
volumes:
- ./volumes/gekko/history:/usr/src/app/history
- ./config.js:/usr/src/app/config.js
links:
- redis
- postgresql
environment:
 - HOST
 - PORT
ports: # you can comment this out when using the nginx frontend
  - "${PORT}:${PORT}"

optionally set nginx vars if you wish to frontend it with nginx
environment:
- VIRTUAL_HOST=gekko
- PORT=3000
- DOMAIN=gekko
redis:
image: redis:latest
volumes:
- ./volumes/redis:/data`
my docker ps and logs output is:
`keiran@vm-ubuntu:/_LOCALDATA/CONTAINERS/gekko$ docker ps
CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS              PORTS                    NAMES
5d6bcb3f1769        gekko_gekko           "/usr/src/app/docker…"   17 minutes ago      Up 17 minutes       <IP_ADDRESS>:3000->3000/tcp   gekko_gekko_1
afa3e9a3f696        redis:latest          "docker-entrypoint.s…"   17 minutes ago      Up 17 minutes       6379/tcp                 gekko_redis_1
fce76f9dc816        portainer/portainer   "/portainer"             About an hour ago   Up About an hour    <IP_ADDRESS>:9000->9000/tcp   cocky_feynman
keiran@vm-ubuntu:/_LOCALDATA/CONTAINERS/gekko$
keiran@vm-ubuntu:/_LOCALDATA/CONTAINERS/gekko$
keiran@vm-ubuntu:/_LOCALDATA/CONTAINERS/gekko$ docker logs -f 5d6bcb3f1769
______   ________  __    __  __    __   ______

/      \ /        |/  |  /  |/  |  /  | /
/$$$$$$  |$$$$$$$$/ $$ | /$$/ $$ | /$$/ /$$$$$$  |
$$ | $$/ $$ |_    $$ |/$$/  $$ |/$$/  $$ |  $$ |
$$ |/    |$$    |   $$  $$<   $$  $$<   $$ |  $$ |
$$ |$$$$ |$$$$$/    $$$$$  \  $$$$$  \  $$ |  $$ |
$$ _$$ |$$ |_____ $$ |$$  \ $$ |$$  \ $$ _$$ |
$$    $$/ $$       |$$ | $$  |$$ | $$  |$$    $$/
$$$$$$/  $$$$$$$$/ $$/   $$/ $$/   $$/  $$$$$$/
Gekko v0.6.8
I'm gonna make you rich, Bud Fox.

Serving Gekko UI on http://localhost:3000/
Something went wrong when trying to open your web browser. UI is running on http://localhost:3000/.`
not quite sure how to debug any further.
I did get it running in docker on my mac easily BTW - but this is the perm install on a more perm ubunto box i have running always.
grateful for your help!!
Keiran

^ ignore me, found thew solution (AND you did already have it documented! sorry). Running with the command line args of setting HOST and PORT did it for me - sorry i misread your docs though you only needed that if accessing over the cloud (where you would plug in a FQDN).... didnt think it would be needed when running over the same home LAN. Spelling the docker-compose below for anyone else that stumbles into this (so my internal server machine is <IP_ADDRESS>, and therefor i hit the gekko UI on http://<IP_ADDRESS>:3001/)
$ HOST=<IP_ADDRESS> PORT=3001 docker-compose up -d


[SUPPORT] Change of Hudi precombine field

Describe the problem you faced
Hi,
I have a use case where I want to change the hudi precombine field of an insert_overwrite (with combine-before-insert enabled) table due the existing precombine field being not sufficient to break the tie when records having the same primary keys show up.
Considering that the table has a lot of historical data, I wanted to directly update the precombine field without needing to re-onboard the entire table and re-ingest all historical data.
I've attempted to directly set hoodie.datasource.write.precombine.field to the new field with a spark job, but received hudi exception for config conflict. (The stack trace is attached at the end)
Also, in hoodie.properties file there is a property named hoodie.table.precombine.field, I wonder if this is the source of truth field hudi refers to for precombine field, and if it's safe to directly update that field in the file to force hudi to switch to the new field without risking the table being corrupted?
Could you please provide some guidance on this? Thank you!
Environment Description

Hudi version : 12.0.3

Spark version : 3.3.0

Hive version : 3.1.3

Hadoop version : 3.3.3

Storage (HDFS/S3/GCS..) : S3

Running on Docker? (yes/no) : no

Additional context
Add any other context about the problem here.
Stacktrace
ERROR Client: Application diagnostics message: User class threw exception: org.apache.hudi.exception.HoodieException: Config conflict(key	current value	existing value):
PreCombineKey:	sort_key_a	sort_key_b
	at org.apache.hudi.HoodieWriterUtils$.validateTableConfig(HoodieWriterUtils.scala:166)
	at org.apache.hudi.HoodieSparkSqlWriter$.write(HoodieSparkSqlWriter.scala:90)
	at org.apache.hudi.DefaultSource.createRelation(DefaultSource.scala:145)
	at org.apache.spark.sql.execution.datasources.SaveIntoDataSourceCommand.run(SaveIntoDataSourceCommand.scala:45)
	at org.apache.spark.sql.execution.command.ExecutedCommandExec.sideEffectResult$lzycompute(commands.scala:75)
	at org.apache.spark.sql.execution.command.ExecutedCommandExec.sideEffectResult(commands.scala:73)
	at org.apache.spark.sql.execution.command.ExecutedCommandExec.executeCollect(commands.scala:84)
	at org.apache.spark.sql.execution.QueryExecution$$anonfun$eagerlyExecuteCommands$1.$anonfun$applyOrElse$1(QueryExecution.scala:103)
	at org.apache.spark.sql.catalyst.QueryPlanningTracker$.withTracker(QueryPlanningTracker.scala:107)
	at org.apache.spark.sql.execution.SQLExecution$.withTracker(SQLExecution.scala:224)
	at org.apache.spark.sql.execution.SQLExecution$.executeQuery$1(SQLExecution.scala:114)
	at org.apache.spark.sql.execution.SQLExecution$.$anonfun$withNewExecutionId$7(SQLExecution.scala:139)
	at org.apache.spark.sql.catalyst.QueryPlanningTracker$.withTracker(QueryPlanningTracker.scala:107)
	at org.apache.spark.sql.execution.SQLExecution$.withTracker(SQLExecution.scala:224)
	at org.apache.spark.sql.execution.SQLExecution$.$anonfun$withNewExecutionId$6(SQLExecution.scala:139)
	at org.apache.spark.sql.execution.SQLExecution$.withSQLConfPropagated(SQLExecution.scala:245)
	at org.apache.spark.sql.execution.SQLExecution$.$anonfun$withNewExecutionId$1(SQLExecution.scala:138)
	at org.apache.spark.sql.SparkSession.withActive(SparkSession.scala:779)
	at org.apache.spark.sql.execution.SQLExecution$.withNewExecutionId(SQLExecution.scala:68)
	at org.apache.spark.sql.execution.QueryExecution$$anonfun$eagerlyExecuteCommands$1.applyOrElse(QueryExecution.scala:100)
	at org.apache.spark.sql.execution.QueryExecution$$anonfun$eagerlyExecuteCommands$1.applyOrElse(QueryExecution.scala:96)
	at org.apache.spark.sql.catalyst.trees.TreeNode.$anonfun$transformDownWithPruning$1(TreeNode.scala:615)
	at org.apache.spark.sql.catalyst.trees.CurrentOrigin$.withOrigin(TreeNode.scala:177)
	at org.apache.spark.sql.catalyst.trees.TreeNode.transformDownWithPruning(TreeNode.scala:615)
	at org.apache.spark.sql.catalyst.plans.logical.LogicalPlan.org$apache$spark$sql$catalyst$plans$logical$AnalysisHelper$$super$transformDownWithPruning(LogicalPlan.scala:30)
	at org.apache.spark.sql.catalyst.plans.logical.AnalysisHelper.transformDownWithPruning(AnalysisHelper.scala:267)
	at org.apache.spark.sql.catalyst.plans.logical.AnalysisHelper.transformDownWithPruning$(AnalysisHelper.scala:263)
	at org.apache.spark.sql.catalyst.plans.logical.LogicalPlan.transformDownWithPruning(LogicalPlan.scala:30)
	at org.apache.spark.sql.catalyst.plans.logical.LogicalPlan.transformDownWithPruning(LogicalPlan.scala:30)
	at org.apache.spark.sql.catalyst.trees.TreeNode.transformDown(TreeNode.scala:591)
	at org.apache.spark.sql.execution.QueryExecution.eagerlyExecuteCommands(QueryExecution.scala:96)
	at org.apache.spark.sql.execution.QueryExecution.commandExecuted$lzycompute(QueryExecution.scala:83)
	at org.apache.spark.sql.execution.QueryExecution.commandExecuted(QueryExecution.scala:81)
	at org.apache.spark.sql.execution.QueryExecution.assertCommandExecuted(QueryExecution.scala:124)
	at org.apache.spark.sql.DataFrameWriter.runCommand(DataFrameWriter.scala:860)
	at org.apache.spark.sql.DataFrameWriter.saveToV1Source(DataFrameWriter.scala:390)
	at org.apache.spark.sql.DataFrameWriter.saveInternal(DataFrameWriter.scala:363)
	at org.apache.spark.sql.DataFrameWriter.save(DataFrameWriter.scala:239)

@ChiehFu Hudi doesn't supports updating the precombine key .
Refer this link - https://github.com/apache/hudi/issues/5981#issuecomment-1174650807

@ad1happy2go I see. Thanks for the quick clarification.


Make TYPO3 work with mailhog

The Problem/Issue/Bug:
Wrong sendmail command to send mails in TYPO3 environment
How this PR Solves The Problem:
Add the missing parameter
Manual Testing Instructions:
See #924
Automated Testing Overview:
There are no tests for this, are they?
Related Issue Link(s):
#924
Release/Deployment notes:
Not afaik

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

If the tests pass, I say we pull this in.

This needs to be linked to mailhog documentation that confirms the usage before it can be pulled. The previous usage was correct for years and years, so I assume that something has shifted in mailhog.

I don't think we need to get this into v0.20.0, and there hasn't been any followup, but I'm pretty sure the appropriate fix is to set transport => 'mail'  in the AdditionalSettings.php. For TYPO3 users the immediate approach is just to set the transport in TYPO3 settings

I think the path forward is to open another PR that does:

transport => 'mail'
SYS/displayErrors => 1
`SYS/devIPmask => '*'

Especially if we want to make this compatible with as many systems (read: Windows) as possible, we should probably switch to the following configuration for TYPO3 (and not touch the php.ini files at all):
    'MAIL' => [
        'transport' => 'smtp',
        'transport_smtp_server' => 'localhost:32769',
    ],

with the host and port of the mailhog container. This should be the most reliable option.

Just to be clear: None of this is related to or even has anything to do with WIndows. This all happens inside the web container, which is Debian Linux. If we were going to use SMTP, the mailhog smtp port is port 1025, and if that seems better to you, we could probably do it. But then any change to the mailhog config would break TYPO3 projects. As it is, the configuration is encapsulated in sendmail_path so it should work for any CMS that is using mail()

Very thoughtful response from @jigal in slack:

I did some digging in mail handling in PHP and how we can use this in TYPO3.
TYPO3 uses SwiftMailer to send emails. SwiftMailer has deprecated the use of the PHP mail() function as mail transport and can remove support completely at any moment. Therefore we have to switch to either "sendmail" or "SMTP".
According to the PHP documentation mail() uses either sendmail (or something compatible) or SMTP (only on Windows and only if sendmail_path is empty). This is configured in the php.ini settings.
TYPO3 can use the php.ini settings (at least for new installations) to configure the mail settings as most installations have a working mail() function. If sendmail_path is empty (and SMTP is empty on Windows) we can only ask the user how installs TYPO3.
So, please don't rely on the 'mail' transport, but make sure the php.ini setting sendmail_path can be copied to the TYPO3 mail settings and SwiftMailer can use that command. If someone prefers to use SMTP they can configure this themselves IMO.

Thanks so much for bringing this to the fore and taking the initiative to do a PR @spoonerWeb - Per the discussion here, the php.ini technique is not what's needed, so I'm going to close this one out. I think the key info is in https://github.com/drud/ddev/issues/924, and I hope to get that into the next release. A followup PR from you is welcome if you want, probably best setting the transport to SMTP and port 25 in the AdditionalSettings.php


Usb data transfer unavailable on RG505 gamma OS

When I try to put the USB data transfer mode on, the option is disabled, so I can't transfer any files to the internal memory, or to the inserted memory card. What is the solution for this problem?

Have you tried a different cable?


Cannot reset form when destroyOnUnmount is false

Are you submitting a bug report or a feature request?
bug report

What is the current behavior?

I have a wizard type form when I have disabled destroyOnUnmount
const form = reduxForm({
  validate,
  form: ADD_RESOURCE_FORM,
  destroyOnUnmount: false,
  forceUnregisterOnUnmount: true,
})(PublishForm);

I have using submit action to submit the form and resetting after the api call using reset action. And then the dialog closes.
What is the expected behavior?
I was expecting form to reset but whenever I start the process again, all the fields are already populated.
One thing I noticed was that the form is reset if I close the dialog before submitting the form.
Sandbox Link

What's your environment?

Redux: ^7.0.4
Other information

Have you solved this problem? I'm stuck with this too.

Just found this issue left unanswered after a year. I also was stuck with this. Turns out that before dispatching reset, I have to dispatch initialize as written on documentation.

@ramjak Actually I don't understand why that is necessary, if you look at the code, it does the same as initialize but it uses the last initialized values https://github.com/erikras/redux-form/blob/e7ce5aec2bf0e24574e6f5f90bc04b9815c8e52e/src/createReducer.js#L522


setUrl causes tiles loaded with tileLayer to flicker

One behaviour of setUrl I find odd is that suppose you have tiles=tileLayer(url) loaded, when you run tiles.setUrl(url), the tiles would flicker, which suggests the tiles were removed and then reloaded, even if you use the same url.  But if you have image=imageOverlay(url) loaded, image.setUrl(url) does not cause the image to flicker at all.  Has anyone noticed this?  Why would setUrl behave differently when applied toward tileLayer?

Can you publish a fiddle/codepen/plunkr that displays this behaviour?

Okay, Ivan,
I have a couple of demos set up using
(1) imageOverlay: https://plnkr.co/edit/sa74aFv4u2jgsFBU93G6?p=preview
(2) tileLayer: https://plnkr.co/edit/nxnga7MqeC3bgUEM07Dz?p=preview

Looking at the code, I can see this:

Calling TileLayer.setUrl will always cause a redraw unless the second argument to setUrl is true: https://github.com/Leaflet/Leaflet/blob/master/src/layer/tile/TileLayer.js#L117
ImageOverlay.setUrl will update the img element's src attribute, which I assume the browser is smart enough to optimize into a no-op if src is the same

We could quite easily add the same optimization in TileLayer.setUrl, checking first if the new URL differs from the old. The only downside I can see is if someone relies on setUrl to always make a redraw.

A couple of questions:

When TileLayer.setUrl is called, does it redraw only the visible tiles or all the tiles, for all zoom levels?
Is it possible to update the src attribute in TileLayer similar to how it is done in ImageOverlay?

When TileLayer.setUrl is called, does it redraw only the visible tiles or all the tiles, for all zoom levels?

It redraws only visible tiles (but will use the new URL template for future tiles)
Keep in mind that (in the default CRS), for a zoom level z, there are 4^z tiles. That's like 17 thousand million for zoom level 17, and no browser is loading (nor reloading) that amount of tiles, ever.

Is it possible to update the src attribute in TileLayer similar to how it is done in ImageOverlay?

Yes, it is. But no one has written the code for it yet.

Hi, I took a shot at fixing this in #6313. Let me know if this change is still needed, and if my approach is appropriate!

Confirmed fixed since v1.4.0 (https://github.com/Leaflet/Leaflet/pull/6313).


Rails 8

Complete Rails 8 update process
https://trello.com/c/9ymFymOL/249-owned-app-rails-8-updates
⚠  This repo is Continuously Deployed: make sure you follow the guidance ⚠

All of the files in the public folder, I assume these got autogenerated? Do we need them?

Good question! We probably don't. I'll remove them.


Additional PHI to be removed from twix headers

Hi Ben,
The twix headers also contain PatientWeight, PatientAge and PatientTelephoneNumber fields that might also need to be anonymized.
Also, I was wondering if you know whether any PHI are held outside of the twix headers in the binary data?
Thanks,
Michael

Hi Michael,
I am going to move this issue to the OpenMRSLab repo which is where ongoing development is taking place, and will look into anonymising these fields.
I can confirm that the binary data only contains the scan parameters and the raw ADC data, according to the specification that I have seen.
Ben

Thanks Ben,
Sorry, I was wrong about the PatientTelephoneNumber field. I thought I saw it somewhere but I must have been working with another file type.
Nucgaek


Prevent multiple form submission

I've done some tests with forms and CSRF validation. Shouldn't CSRF prevent multiple form submission too?
It doesn't matter if enableCsrfCookie is true or false, F5 does the job and could flood some DBs.

No, CSRF has nothing to do with it.

So would it not make sense to support this with a token or something?

F5 should not trigger a new form submission, you should redirect after a POST request.


Automatic computation of is_park_centered ?

Requested by PNC. @camillemonchicourt, what do you think about it ?

We had this in mind for long, we didn't do it because we always wanted to avoid to rely on specific N-1 values (like restricted areas types) in the code of triggers.
If there is an elegant way to do it, it could be done :)
(Partial overlap? Start location? Override by user?)

If it is computed, there is no database field so there is no trigger. Unless we want to denormalize the field, for example to be able to override the automatic choice.

It would need to have a parameter to mention which is the RESTRICTED-AREAS-TYPE to use, right ?
And maybe there are some particular cases for Geotrek with several structures. Then it may would need to use 2 or more RESTRICTED-AREAS-TYPES ?


Italic?

(slanted)
Great project, thanks!

I don't have a plan for Italic yet, but I may can update the code can change the slope. But not sure when can I do that.

dapingtai3344.com  老哥换个友链吗？
联系QQ：1297532431


az/Move js_service_encointer

moved it outside the lib
"integration tests passed"
1,248 changes came from yarn install and yarn build run under js_service_encointer

Superseded by ##1064


Can I consider language to increase support for Chinese?

Can I consider language to increase support for Chinese?
Thank you

There were multiple pull-request adding Chinese support (check pull-requests) but there are all abandoned.
If you are interested you can try adding support for Chinese on your own by following our guide.


Add support to clone a repo that user provide and run mentat in collab something like this https://github.com/lllyasviel/Fooocus#colab

https://github.com/lllyasviel/Fooocus#colab

I'm not sure what a colab interface would look like, can you describe what you are imagining?

I like this idea a lot actually.
input works the same way in Jupyter:

We could send cells from the notebook instead of files, and have it add/remove/edit cells. It can be installed with pip, and then maybe you import a hook to activate it
!pip install mentat-ai

from mentat-ai import ask_mentat

def hello():
    print('Hello!')

ask_mentat('*')

>>> How can I help you?
>>> Add a name to the `hello` function.

Nice, that would be fun!
Not a priority yet but maybe in a couple months!


Add non-code linters

Markdown
YAML
GitHub Actions

Closes #11.
Closes #12.
Closes #20.

I'm merging. It should be easy to revert if this should errors in the default branch.


Allow to add other ini files

Allows users to add php.ini files to /usr/local/lib/php/ without rebuilding the image (could be done with a simple volume)

Thanks


Nested Collections

Hi,
please is there any documentation related to the "nested collections" feature?
Nested items from the initial ViewModel are correctly displayed and posted back, but newly added children are not.
Looking at the generated HTML it appears that the newly added inner children are not decorated with any reference to their parent.
Please, how shoud I solve this issue?
Thanks

I was able to reproduce the issue, but don't have time to fix it this week. Any PR with the fix is appreciated.

Fixed by 8d8f692996bd118f2b25bb136c24420f1e1e8045 in Version 1.0.7


k3s Pod unable to access internet.

Environmental Info:
K3s Version:
v1.28.4+k3s2 (6ba6c1b6)
Node(s) CPU architecture, OS, and Version:
Linux app-instance 5.15.0-1047-oracle #53-Ubuntu SMP Wed Oct 18 09:56:06 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
Cluster Configuration:
Single server cluster
Describe the bug:
One of our backend service hosted in one of the pod on k3s cluster needs to fetch some backend code data from Gitlab repo, but pod is unable to access Gitlab.
After troubleshooting we found our pod is unable to connect to internet whereas our k3s hosting server is able to connect to internet.
Steps To Reproduce:

Installed K3s:
curl -sfL https://get.k3s.io/ | INSTALL_K3S_EXEC="--tls-san=<IP_ADDRESS>" sh -s - --docker

we are using dockerd as container runtime as by default it is giving containerd by default so we are using --docker
Expected behavior:
Expected that our pods can access to the internet and gitlab.
Actual behavior:
Actually our pods is not able to access to the internet and when curl google.com it is not giving us any response.
Additional context / logs:
When we exec into pod it is giving following error.
root@configuration-deployment-6494598cd6-9xg8m:/# curl google.com
curl: (6) Could not resolve host: google.com

root@configuration-deployment-6494598cd6-9xg8m:/# curl google.com
curl: (6) Could not resolve host: google.com

This would indicate that the pod cannot reach the coredns service. Is your pod not able to reach the internet, or not able to reach its DNS server?
How many nodes do you have in this cluster? Can you confirm that CNI traffic (flannel vxlan, by default) is not being dropped? Have you tested other pod-to-pod or pod-to-service traffic between nodes, and confirmed that it is working properly?

Hi @brandond , This is a single node cluster. Can you please let me know how can I check that CNI traffic (flannel vxlan, by default) is not being dropped?
And also how can I check that pod-to-pod or pod-to-service traffic between nodes is working properly or not ?

If it's a single-node cluster then there would be no traffic between nodes.
Is the coredns pod working? Do you have firewalld or ufw enabled and blocking traffic?

Hi @brandond thankyou for your quick response, Our Coredns pod is running and ufw is inactive, we are using firewalld and it is in active state and we have allowed port 80/tcp 443/tcp 6443/tcp 53/udp.
Here is the output from server for all your questions for your reference.
ubuntu@app-instance:~$ kubectl get pods -n kube-system
NAME                                      READY   STATUS      RESTARTS     AGE
helm-install-traefik-crd-2kn55            0/1     Completed   0            62d
helm-install-traefik-dsd6k                0/1     Completed   1            62d
local-path-provisioner-84db5d44d9-m8bq6   1/1     Running     3 (9d ago)   62d
svclb-traefik-64565659-ddnbn              2/2     Running     6 (9d ago)   62d
metrics-server-67c658944b-wqmwr           0/1     Running     3 (9d ago)   62d
coredns-554795b5f9-jt5xr                  1/1     Running     2 (9d ago)   17d
traefik-f4564c4f4-c46h2                   1/1     Running     4 (9d ago)   62d
ubuntu@app-instance:~$ sudo ufw status
Status: inactive
ubuntu@app-instance:~$ sudo firewall-cmd --list-all
You're performing an operation over default zone ('public'),
but your connections/interfaces are in zone 'docker' (see --get-active-zones)
You most likely need to use --zone=docker option.
public
target: default
icmp-block-inversion: no
interfaces:
sources:
services: dhcpv6-client ssh
ports: 80/tcp 443/tcp 6443/tcp 53/udp
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:

we are using firewalld and it is in active state and we have allowed port 80/tcp 443/tcp 6443/tcp 53/udp.

We don't technically support use with firewalld. My first suggestion would be to disable and stop it. If you want to try keeping it enabled, see https://docs.k3s.io/installation/requirements#operating-systems

Hi @brandond , we are using firewalld in one of the project in k3s cluster and everything is working fine there. In our k3s cluster our server is giving response is we are using command ( ping google.com ) but our problem is our pod is not giving response when we are using ( ping google.com ).
Can you please provide any reference as you said when we are using docker zone in play we may need to make additional adjustments to the config, beyond what is suggested in the docs. This will be helpful for us.


Expanding Demographics to Include Inclusion

The Demographics section of the survey seems to focus on diversity by asking about how representative the open source community is with regards to the developer community and the world population. However, what about expanding this to also discuss inclusion?
I think that talking about how representation in open source correlates "with experiences, motivations, and other aspects of participation in open source" is hints at the topic of inclusion, but can this section also explicitly ask something like, "How inclusive is open source when it comes to contributions from underrepresented groups?" Or, maybe, "Why do certain demographic groups not contribute to open source software development?"
As it currently stands, the Demographics section is like a downtown restaurant asking, "Who are the people who come into our restaurant at lunch time?" That's an important question to answer, but I think a useful followup question would be, "Why are some people not coming into our restaurant at lunch time?" That's why I think this section should be expanded to explicitly inquire about inclusion.

Thanks for bringing this up, @anjuan; this is definitely in line with our goals and intentions, though I can see that it isn't necessarily clear from the topics document. We're getting at some of aspects of inclusion in the community safety section, where we will be asking about experiences with harassment and abuse. However, there are experiences and dynamics that can discourage participation without rising to the level of explicit harassment, and we do plan to explore those as well.

For post graduate research completed a few years back on Barriers to Participation in Communities which explored gender, language and other considerations, consider contacting Prof. Carlos Jenson at OSU.  The research may help inform your questions (or just be of general interest).
Deb

On Oct 10, 2016, at 3:04 PM, Frannie Zlotnick<EMAIL_ADDRESS>wrote:
Thanks for bringing this up, @anjuan https://github.com/anjuan; this is definitely in line with our goals and intentions, though I can see that it isn't necessarily clear from the topics document. We're getting at some of aspects of inclusion in the community safety https://github.com/github/open-source-survey/blob/master/survey-topics.md#community-safety section, where we will be asking about experiences with harassment and abuse. However, there are experiences and dynamics that can discourage participation without rising to the level of explicit harassment, and we do plan to explore those as well.

The survey instrument was released today (#36), and includes questions related to to inclusiveness. Let us know if you have any questions or concerns.


Add a MachineTopology class and HWLOC support

This PR adds a machine topology class to the executor. This is done using the HWLOC library. This enables us to have finer control of the cores and GPUs and helps us bind executors to cores and such.
Currently, HWLOC allows the system administrator to export the machine configuration into an XML file which we can export and get information about the system. In case, this XML file is not available, then we have to query and generate the topology with the HWLOC functions.
The core of the machine info class was written by @tcojean.
TODO

[x] Add documentation
[x] Evaluate possibility of a global struct.

check_format!

check-format!

format!

format!

@thoasm wouldn't a singleton anyway have the same implementation except that there would be no fast-path atomic-boolean once the class has been initialized, and therefore have sub-par performance?

@thoasm wouldn't a singleton anyway have the same implementation except that there would be no fast-path atomic-boolean once the class has been initialized, and therefore have sub-par performance?

@tcojean Yes, it can have pretty much the same implementation. The reason why I would prefer a Singleton is that the get_machine_topology() would be inside the class.
The static MachineTopology instance; line leaves it to the compiler to do a proper implementation, and at least in the Microbenchmark I did, it performed almost identical to @pratikvn's current implementation (I only tested single-threaded). It is only a suggestion from me (it is shorter an less error prone), but I am also totally fine if @pratikvn keeps his implementation.
Here is another take on it, including benchmarks: https://www.modernescpp.com/index.php/thread-safe-initialization-of-a-singleton
There, the compiler generated solution is always the fastest.

@tcojean Yes, it can have pretty much the same implementation. The reason why I would prefer a Singleton is that the get_machine_topology() would be inside the class.
The static MachineTopology instance; line leaves it to the compiler to do a proper implementation, and at least in the Microbenchmark I did, it performed almost identical to @pratikvn's current implementation (I only tested single-threaded). It is only a suggestion from me (it is shorter an less error prone), but I am also totally fine if @pratikvn keeps his implementation.
Here is another take on it, including benchmarks: https://www.modernescpp.com/index.php/thread-safe-initialization-of-a-singleton
There, the compiler generated solution is always the fastest.

@tcojean and @thoasm , thank you for your comments. This should be ready for review again.

@tcojean and @thoasm , thank you for your comments. This should be ready for review again.

Weird! The PR has not been updated even though I have pushed and the Ginkgo CI is running

Weird! The PR has not been updated even though I have pushed and the Ginkgo CI is running

I think this is ready to be merged, unless someone has any more comments.

I think this is ready to be merged, unless someone has any more comments.

Regarding the licensing, I think it is nice to have all the licenses that Ginkgo uses in one place for anyone to refer to. In the future, if we use some code from any library with that license again, then we can again just refer to ABOUT-LICENSING without adding any more lines.

Regarding the licensing, I think it is nice to have all the licenses that Ginkgo uses in one place for anyone to refer to. In the future, if we use some code from any library with that license again, then we can again just refer to ABOUT-LICENSING without adding any more lines.


Structure of download link for AGPLv3 and CC versions

Hi,
I'm having trouble fixing the package on FreeBSD wrt hte community and regular version. Can't seem to construct a tarball url fetching the rainloop-community version from the http://repostiory.rainloop.net/v2/core.stable.json output is there a different repo url to call or what is the structure of the download for the AGPLv3 tarball?
PORTNAME=       rainloop
PORTVERSION=    1.9.0
CATEGORIES?=    mail www
MASTER_SITES=   http://repository.rainloop.net/v2/webmail/${PORTVERSION}/
DISTNAME=       ${PORTNAME}-${PORTVERSION}.${RBUILD}-${RHASH}
Refresh using info from http://repository.rainloop.net/v2/core.stable.json
RHASH=          0e55c0364faafb6f550fd4b186acfe6e
RBUILD=         325

http://repository.rainloop.net/v2/core.open.json

Excellent, many thanks! That wasn't one of the many things I had tried (core.community.json etc)

curl http://repository.rainloop.net/v2/core.open.json | grep -i license
"license": "CC BY-NC-SA 3.0",
curl http://repository.rainloop.net/v2/core.stable.json | grep -i license
"license": "CC BY-NC-SA 3.0",
The tarballs seem to be OK though

Thanks! fixed.

Ever so welcome! My futile attempt at giving back to the project...


update readme to note rfs specific version

Addresses @dougwilson request in https://github.com/expressjs/morgan/pull/218#pullrequestreview-343393630.
As of November 2019 the rotating-file-stream package moved from 1.x.x to 2.x.x.
The main breaking change was what is described in #217 and fixed in the docs at #218

Closing this in favor of other PRs that would make this obsolete like https://github.com/expressjs/morgan/pull/218.


num-traits: testsuite failure on i386

Hello, looks like a test is failing on i386 since the begin (at least since version 2)
test wrapping_is_num ... ok
test check_num_ops ... ok
test ops::mul_add::tests::mul_add_float ... FAILED

failures:

---- ops::mul_add::tests::mul_add_float stdout ----
thread 'ops::mul_add::tests::mul_add_float' panicked at 'assertion failed: abs_difference <= f32::EPSILON', src/ops/mul_add.rs:149:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::continue_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::panicking::panic
   9: num_traits::ops::mul_add::tests::mul_add_float
             at src/ops/mul_add.rs:149
  10: num_traits::ops::mul_add::tests::mul_add_float::{{closure}}
             at src/ops/mul_add.rs:130
  11: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.34.2/src/libcore/ops/function.rs:231

failures:
    ops::mul_add::tests::mul_add_float

test result: FAILED. 25 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

error: test failed, to rerun pass '--lib'
dh_auto_test: /usr/share/cargo/bin/cargo test --all returned exit code 101
make[1]: *** [debian/rules:6: override_dh_auto_test] Error 25
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:3: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2
--------------------------------------------------------------------------------
Build finished at 2019-07-08T08:08:37Z

Do you have any idea?
Full build log: https://buildd.debian.org/status/fetch.php?pkg=rust-num-traits&arch=i386&ver=0.2.8-1&stamp=1562573322&raw=0

Hmm, I can reproduce this on i586-unknown-linux-gnu, but not on i686. The main difference is in the default target features, where Rust i686 assumes fxsr,sse,sse2, and this could certainly have an effect on the accuracy that this test is looking for.
But I can see in your log that it did build for i686 -- unless Debian patched out the SSE features? (Not all i686 CPUs really have SSE2, after all.) What does rustc --print cfg say?
I can reproduce on i686 with RUSTFLAGS='-Ctarget-feature=-sse', so I suspect this is it.
Anyway, the test is probably just too tight with comparing EPSILON, "the difference between 1.0 and the next largest representable number." The true decimal result is 46.4, so EPSILON is already out of the range of significant bits, and we're effectively comparing for equality.


Upgrade from 2.1 to 2.2 : loads more console output

Do you want to request a feature or report a bug?
A (potential) bug.
What is the current behavior?
Webpack 2.2. has changed the console output when running Webpack to include a huge list of every source file. Setting the stats option in the config doesn't seem to make any difference.
What is the expected behavior?
Less output by default, as is the case in 2.1.
Output in Webpack 2.1 latest beta
> NODE_ENV=production webpack --config webpack/webpack.prod.config.js

clean-webpack-plugin: /Users/jackfranklin/git/songkick/ng-store/dist has been removed.
clean-webpack-plugin: /Users/jackfranklin/git/songkick/ng-store/dist-dev has been removed.
Hash: 952d729dfe9e9458da9f
Version: webpack 2.1.0-beta.27
Time: 28325ms
                     Asset      Size  Chunks             Chunk Names
    critical.2d4643.min.js   30.7 kB       1  [emitted]  critical
 assets/icomoon.fc24f1.eot   2.38 kB          [emitted]
 assets/icomoon.80e91f.ttf   2.21 kB          [emitted]
assets/icomoon.25740c.woff   2.29 kB          [emitted]
 assets/cc-icon.c2c793.png   20.7 kB          [emitted]
         app.c93cba.min.js    928 kB       0  [emitted]  app
 assets/icomoon.ac1500.svg    4.1 kB          [emitted]
            app.c93cba.css   55.4 kB       0  [emitted]  app
       critical.2d4643.css      2 kB       1  [emitted]  critical
        app.c93cba.css.map  91 bytes       0  [emitted]  app
   critical.2d4643.css.map  96 bytes       1  [emitted]  critical
                index.html   35.8 kB          [emitted]
               iframe.html   2.25 kB          [emitted]
    + 991 hidden modules
Child html-webpack-plugin for "index.html":
        + 4 hidden modules
Child extract-text-webpack-plugin:
        + 2 hidden modules
Child extract-text-webpack-plugin:
        + 7 hidden modules

Output in Webpack 2.2-beta (no changes to config)
> NODE_ENV=production webpack --config webpack/webpack.prod.config.js

clean-webpack-plugin: /Users/jackfranklin/git/songkick/ng-store/dist has been removed.
clean-webpack-plugin: /Users/jackfranklin/git/songkick/ng-store/dist-dev has been removed.
Hash: 061ebca982564fde940e
Version: webpack 2.2.0-rc.0
Time: 27362ms
                     Asset      Size  Chunks           Chunk Names
    critical.5b3b96.min.js   30.8 kB  1[emitted]  critical
 assets/icomoon.fc24f1.eot   2.38 kB  [emitted]
 assets/icomoon.80e91f.ttf   2.21 kB  [emitted]
assets/icomoon.25740c.woff   2.29 kB  [emitted]
 assets/cc-icon.c2c793.png   20.7 kB  [emitted]
         app.6c7d87.min.js    929 kB  0[emitted]  [big]app
 assets/icomoon.ac1500.svg    4.1 kB  [emitted]
            app.6c7d87.css   55.4 kB  0[emitted]  app
       critical.5b3b96.css      2 kB  1[emitted]  critical
        app.6c7d87.css.map  91 bytes  0[emitted]  app
   critical.5b3b96.css.map  96 bytes  1[emitted]  critical
                index.html   35.8 kB  [emitted]
               iframe.html   2.25 kB  [emitted]
   [6] ./src/app/log.js 1.83 kB {0} {1} [built]
   [7] ./src/app/utils.js 6.86 kB {0} [built]
... LOADS OF THIS SNIPPED...
 [987] ./src/assets/fonts/icomoon.ttf 71 bytes [built]
 [988] ./src/assets/fonts/icomoon.woff 72 bytes [built]
 [989] ./src/assets/img/cc-icon.png 71 bytes [built]
    + 721 hidden modules
Child html-webpack-plugin for "index.html":
       [3] ./~/html-webpack-plugin/lib/loader.js!./webpack/index.ejs 5.01 kB {0} [built]
        + 3 hidden modules
Child extract-text-webpack-plugin:
       [1] ./~/css-loader!./~/csso-loader!./~/postcss-loader!./~/sass-loader!./src/styles/sass/critical.scss 2.12 kB {0} [built]
        + 1 hidden modules
Child extract-text-webpack-plugin:
       [0] ./src/assets/fonts/icomoon.eot 71 bytes {0} [built]
       [2] ./src/assets/fonts/icomoon.svg 71 bytes {0} [built]
       [3] ./src/assets/fonts/icomoon.ttf 71 bytes {0} [built]
       [4] ./src/assets/fonts/icomoon.woff 72 bytes {0} [built]
       [5] ./src/assets/img/cc-icon.png 71 bytes {0} [built]
       [6] ./~/css-loader!./~/csso-loader!./~/postcss-loader!./~/sass-loader!./src/styles/sass/app.scss 55.8 kB {0} [built]
        + 1 hidden modules

I'm sure I can fix this with config changes (pointers welcome!) but I wouldn't expect this behaviour to change by default out of the box.

That was actually a bug fix -- files processed by loaders that came from node_modules were being hidden, when only actual files from node_modules should have been.

That sounds logical - thanks Kovensky. If this is the case then the release logs should probably instruct on how to change the output back to what it was in 2.1, or at least turn off the logging of each file. I couldn't figure that out either.

@jackfranklin, you said that you tried out stats but it didn't work. What exactly did you try? The options in the stats documentation should work.

@SpaceK33z which one should I set to false to hide ? I tried a few but maybe I got the wrong one!

I don't know exactly. Depending on what you want, you can set modules: false or chunks: false.

That's what I thought - but they don't make a difference to the output! I'm not 100% but I'm wondering if there's a bug that means Webpack is just ignoring the stats option or something?

Hmm, I think you're right. I tested it by using stats: 'none' (which should, obviously, log nothing), but it still shows all chunks. That seems like a bug. The last couple of beta's also seem to have this bug.
On webpack-dev-server this does seem to work correctly.

fixed, it only shows the first 15 modules


Drupal Open Learning Course Objectives

[ ] Course Objectives (What do people hope to get out of this course? Skills? Certificate? Etc?)

@mmilutinovic1313 Is this a separate course from https://github.com/elmsln/openulmus.org/issues/7? We definitely want to have an "Intro to Drupal Open Learning" class with similar elements as the Open Ulmus course (how the program works, how to set up a new course, and how to become involved with the community, etc.) but specific to the Drupal Open Learning Program.
As we'd include the cost in the overall Drupal Open Learning MVP https://github.com/DrupalOpenLearning/drupalopenlearning/issues/1, possibly we should move related issues (or I guess you can't do that on github?) to https://github.com/DrupalOpenLearning/drupalopenlearning or another repo within that org?

Hi @gusaustin - each of these issues I made last night relates to conversations on objectives. This issue defines what objectives we want to cover in the course described in #7.

@mmilutinovic1313 Wouldn't this and the related issues be 'Open Ulmus' and not 'Drupal Open Learning'?
Possibly we need to follow up on https://github.com/elmsln/openulmus.org/issues/1#issuecomment-331521363 just make sure we're clear how those relate.

Speaking of objectives -- is there any talk on gamification? I personally don't like it, but I know many people like badges and proof that they completed xyz objective and are certified in 'whatever' :)

@gusaus I have changed the scope of this issue and it aligns to the current vision and objectives.

@mmilutinovic1313 With the updated Scope and focus on OpenUlmus Beta, this appears to be an extension of #6, correct?
Would it be simpler to close this issue and integrate the requirements into the overall issue for #6 as checklist?

Yeah this was intended to be a subtask of #6. But I think @kat-wehr  has a good handle on #6 so I will close this one out