Select2 filter fixes

This PR includes #3371 from @martijnb92. Fixing the dead loop when clearing filters.
This also fixes a behavior where select2_ajax filter leaves artifacts behind;
?select2_from_ajax=1&select2_from_ajax_text=Text.

When using the "Remove all filters" button, everything goes as expected. But when removing the entry directly on the filter it leaves behind select2_from_ajax_text=Text.

A new inspection was created.

A new inspection was created.

The inspection completed: No new issues

The inspection completed: No new issues

Looks good!

Haha - chased quite a few PRs to get to this final solution. Good work @martijnb92 & @promatik ! Felt like a mouse in a maze - happy to see you have a solution you're happy with. Looks clean too!
I'll wait for @pxpm 's test, review & green light to merge this.
Cheers!

@promatik
I think we should merge this AFTER #3348 as there are some conflicts between the files (at first look line 112 will conflict with other PR)
What do you think, #3348 first then update this PR base branch to have the fixed code in #3348 or should we merge this one first and update the code in the other ?
Or even merge this one in the other?
Let me know,
Pedro

@pxpm I think it's ok to wait for #3348 and fix the conflicts after that.
#3348 is "Ready to Merge" I'll solve the conflicts and request your review after it's being merged 👌

A new inspection was created.

A new inspection was created.

The inspection completed: No new issues

The inspection completed: No new issues

A new inspection was created.

The inspection completed: No new issues

Hello @promatik
I'v been working on this for the past days, we have also another issue open with filters #2772  that I think we should address in this PR too, because you know .. change files once, fix most possible stuff.
1 issue raised by @AbbyJanke there was about setModel don't changing when applying the filter.
From my tests:
$this->crud->addFilter([ // dropdown filter
            'name' => 'select_from_array',
            'type' => 'dropdown',
            'label'=> 'Dropdown',
        ], ['one' => 'One', 'two' => 'Two', 'three' => 'Three'], function ($value) {
            if($value == 'one') {
                $this->crud->setModel('App\Models\Product');
            } else {
                $this->crud->setModel('App\Models\Icon');
            }
        });

When the filter is applied (the error is expected, because we don't have a "checkbox" column in Products), we are applying a filter, so the same filter logic is applied, but we can see that the setModel worked, because we are in monsters, querying for Products 👍

The second issue was found while trying to debug the above mentioned. Backpack was doing more requests than it should when clearing the filters.
You can easily reproduce it in https://demo.backpackforlaravel.com
If you go to monsters, apply any filter and then click Remove Filters, you will endup with this:

Problem relies in the fact that when clicking the button, we are going to "clear" all the filter values, and that produce a change event in some filters, that change event will eventually make the ajax request. Plus one more ajax request that we trigger (well done us) after clearing the filters.
We found a quick and dirt solution we posted on #2772 that was checking if there is value and returning if not. But that lead to undesired consequences because we also trigger a change event when you remove a single filter, and that would stop work.
So the solution is to when "Removing all filters", we update the browser url, removing the filters etc, but don't update the table url. The table will be updated in the triggered request after clearing all filters.
Let me know @promatik @martijnb92 what you think, or any suggestions you have to improve this.
Best,
Pedro

A new inspection was created.

The inspection completed: No new issues

A new inspection was created.

Hi @pxpm I was reviewing your last changes, and it's great 👌 it clean up the code a lot.
I tested and found a bug with shouldUpdateUrl, it was not being reset so it worded only the first time.
Also I found a code to e.stopPropagation(); on select2_ajax, it was causing the default select2 to not clean the label when user click the clear button. I removed it and it caused no harm.
I fixed it, and along with that I refactored a little bit the function updateDatatablesOnFilterChange in a way that it makes it cleaner to call it.
So this;
if(value === '' || !value) {
    var new_url = updateDatatablesOnFilterChange(crud, parameter, null, null, null, '{{ $filter->key }}', dateFilterShouldUpdateUrl)
} else {
    var new_url = updateDatatablesOnFilterChange(crud, parameter, value, null, null, '{{ $filter->key }}', true)
}

becomes;
var new_url = updateDatatablesOnFilterChange(parameter, value, value || shouldUpdateUrl);

and in case of select2_ajax, call it twice;
updateDatatablesOnFilterChange(filterName, val);
var new_url = updateDatatablesOnFilterChange(extra_param, val_text, true);

It's not amazing in this case, but it causes no harm and since it's the only situation where it's used it makes everything much cleaner.
I tested, everything is working, please let me know what you think about the changes 🙌
https://user-images.githubusercontent.com/1838187/108691461-72648f80-74f3-11eb-8444-75fed182d55e.mp4

The inspection completed: No new issues

A new inspection was created.

A new inspection was created.

The inspection completed: No new issues

The inspection completed: No new issues

Great work here guys! I have only one concern... shouldn't we consider this a breaking change because updateDatatablesOnFilterChange() is provided in a separate file than a filter?
Imagine this scenario:

dev publishes and customizes crud/inc/filters_navbar.blade.php (for styling)
we push this update
from his point of view, all filters stop working

Don't get me wrong, I LIKE the fact that you've separated that repeating logic into updateDatatablesOnFilterChange(). But... I think we can only merge this in 4.2, due to that fact.
How big/common is this dead loop? Is it something that can wait until 4.2 to be merged? Or should we find a way to rewrite this in a non-breaking way?

Hello @tabacitu
You are right. Never came to my mind people overriding the filters_navbar.
I think the only breaking change here is the last fixes introduced in this PR that fix the multiple requests. The first issue fixed here was removing the select2_ajax filter parameters that got stuck in the URL.
I will split this back into 2 PR's, one that could be merged in 4.1, and the refactor to be merged in 4.2.
Thanks @tabacitu !

A new inspection was created.

Separated the non-breaking part of this PR into a new one. #3582
Move this to 4.2.

The inspection completed: No new issues

@pxpm , it's now or never. If we don't merge this now, we'll separate some of these filters to backpack/pro and we'll never be able to do a clean merge.
Can you please:

pull 4.2 on top of this, and fix merge conflicts;
thoroughly test this - if it works, give me the green light to merge; if it does NOT work at first try, please don't spend hours one this; reply here that it no longer works and we'll figure out a solution after the 4.2 launch;

Thank you!


Compatibility with opensearch 2.17.1

Description
Compatibility with opensearch 2.17.1
Issues Resolved

#346

Test
CR: ✅
Test: ✅
Installed osd 2.17.1


Add a nuget package for Microsoft.AspNet.Authentication.Cookies.Shareable?

I was read the doc http://docs.asp.net/en/latest/security/data-protection/compatibility/cookie-sharing.html and found a Microsoft.AspNet.Authentication.Cookies.Shareable package. But it is not available on nuget. It will be great if you guys support this package.

@danroth27 / @Eilon

I'd be inclined to keep that in their own packages, but it's a reasonable request. @danroth27 any comments?

This is to share auth cookies between the previous auth system and this system? That sounds neat to me...

@Eilon yup. Shall we have @HaoK pull it in officially then?

I'm cool with that.
@GrabYourPitchforks any concerns about that? We'll add tests, of course.

No real concerns, though there might be some edge cases that can trip you up. Consider the scenario where an application developer has customized the cookie name or the authentication type string. The sample package might assume these strings to be constant.

Ah true true. We could presumably start out simple and handle the most common/default cases, and enhance based on customer feedback to support more highly customized scenarios.

Dupe of https://github.com/aspnet/Security/issues/387


Build fails for release and forks, advice?

Hi!
I understand that the status of sphinxcontrib-versioning is a bit complicated, but I gather from reading from the issues and PRs and from looking at a few doc setups that people have this working. I was wondering if someone could help me with an issue I haven't found reported here on the repo.
Running sphinx-versioning build with the pypi version I get the error documented in issue #66 fixed in PR #69. However, running @z00sts' PR branch quits with a file not found error.
I've also tried @leokoppel's fork, but there it hangs after two runs of doc building and no files found in the reported path (/tmp/tmp*sphinxcontrib_versioning).
Anyone encountered something similar or could give some points towards getting this to work with compas-dev/compas?
General info
$ python --version
Python 3.6.9

$ pip freeze | grep -i sphinx
nbsphinx==0.4.3
Sphinx==2.2.0
sphinx-compas-theme==0.4.1
sphinxcontrib-applehelp==1.0.1
sphinxcontrib-devhelp==1.0.1
sphinxcontrib-htmlhelp==1.0.2
sphinxcontrib-jsmath==1.0.1
sphinxcontrib-qthelp==1.0.2
sphinxcontrib-serializinghtml==1.1.3
sphinxcontrib-versioning==2.2.1

$ git remote -v

origin          git@github.com:compas-dev/compas.git (fetch)
origin          git@github.com:compas-dev/compas.git (push)

Logs
$ pip install<EMAIL_ADDRESS>$ sphinx-versioning -L build -i -r master docs /dist/docs
=> Gathering info about the remote git repository...
=> Getting list of all remote branches/tags...
=> Found: docs-pull-req footnote-fix master patch-1 pathlib_support quick-fix-clr-pythonnet sphinx-versioning update_robot worbit-patch-1 0.1.0 0.1.0-drx_numpy_callback 0.1.0-facenetwork_import 0.1.0-subd_ck_example_imports 0.1.0-viewer_glut_title_str 0.1.1 0.1.1-import_error_smoothing_cpp 0.1.1-import_problems_cpp_versions 0.1.1-leaves_after_embedding 0.1.1-rhino_utility_aliases 0.1.1-xfunc_callback_args 0.1.1_ga_bugfix v0.3.0 v0.3.1 v0.3.2 v0.3.3 v0.3.4 v0.3.5 v0.3.6 v0.4.0 v0.4.1 v0.4.10 v0.4.11 v0.4.12 v0.4.13 v0.4.14 v0.4.15 v0.4.16 v0.4.17 v0.4.18 v0.4.19 v0.4.2 v0.4.20 v0.4.21 v0.4.22 v0.4.23 v0.4.3 v0.4.4 v0.4.5 v0.4.6 v0.4.7 v0.4.8 v0.4.9 v0.5.0 v0.5.1 v0.5.2 v0.6.0 v0.6.1 v0.6.2 v0.7.0 v0.7.1 v0.7.2
=> With docs: docs-pull-req footnote-fix master patch-1 pathlib_support quick-fix-clr-pythonnet sphinx-versioning update_robot worbit-patch-1 v0.3.0 v0.3.1 v0.3.2 v0.3.3 v0.3.4 v0.3.5 v0.3.6 v0.4.0 v0.4.1 v0.4.10 v0.4.11 v0.4.12 v0.4.13 v0.4.14 v0.4.15 v0.4.16 v0.4.17 v0.4.18 v0.4.19 v0.4.2 v0.4.20 v0.4.21 v0.4.22 v0.4.23 v0.4.3 v0.4.4 v0.4.5 v0.4.6 v0.4.7 v0.4.8 v0.4.9 v0.5.0 v0.5.1 v0.5.2 v0.6.0 v0.6.1 v0.6.2 v0.7.0 v0.7.1 v0.7.2
=> Root ref is: master
=> Pre-running Sphinx to collect versions' master_doc and other info.
usage: sphinx-versioning [OPTIONS] SOURCEDIR OUTPUTDIR [FILENAMES...]
sphinx-versioning: error: cannot find files ['/tmp/tmpm9pm2hi8sphinxcontrib_versioning']
=> sphinx-build failed for branch/tag: master
Failure.

$ pip install git+https://github.com/leokoppel/sphinxcontrib-versioning
$ sphinx-versioning -L build -i -r master docs /dist/docs
=> Gathering info about the remote git repository...
=> Getting list of all remote branches/tags...

[...]
# Runs twice with Sphinx-warnings that we see with normal runs
[...]

copying static files... ... done
copying extra files... done
dumping search index in English (code: en)... done
dumping object inventory... done
build succeeded, 27 warnings.

The HTML pages are in ../../../../tmp/tmplibvh55lsphinxcontrib_versioning.

# Freezes

Hi Anton !
I encountered the same problem with the sphinxcontrib-versioning 2.2.1 from pypi. Even if I solved my problem in #66 I'm still stuck like you mentioned above.

Hi there, after digging around for 1 hour, I found a simple hack should work for this case.
https://github.com/sphinx-contrib/sphinxcontrib-versioning/blob/86a28dc92ce3ff42ed36a8b3e4dc6bdcff90f2c4/sphinxcontrib/versioning/sphinx_.py#L202
Change the argv to argv[1].
Currently by default argv has three elements: sphinx-build, {SOURCE}, {TARGET}. But I suspect the new sphinx accepts only the last two, it will treat {TARGET} as filename option and check if it's really a file, which is a folder of course (Here's the logging line Not files).

Thanks! Going to test it out later today!

@tetov sorry for post a wrong solution, it's for another bug. BTW I encountered the same freezing bug too.

There are several things to make it work in my setting up.

add sphinxcontrib.versioning.sphinx_ to the extension list in conf.py
check-out #46 to fix the version mis-match issue.

It should work now.

I've used  fresh install from the main by following the two points above (I manually patched the sphinx.py) and then also also the ImportError: cannot import name 'build_main' fix
The program hangs after display
The HTML pages are in  /tmp/tmpbuild directory
This error occurs with my real project and also with the tutorials simple example (https://sphinxcontrib-versioning.readthedocs.io/en/latest/tutorial.html#build-all-versions)

You can try add some log lines in these callbacks to see if this extension is registered correctly.
https://github.com/sphinx-contrib/sphinxcontrib-versioning/blob/86a28dc92ce3ff42ed36a8b3e4dc6bdcff90f2c4/sphinxcontrib/versioning/sphinx_.py#L47
https://github.com/sphinx-contrib/sphinxcontrib-versioning/blob/86a28dc92ce3ff42ed36a8b3e4dc6bdcff90f2c4/sphinxcontrib/versioning/sphinx_.py#L65

Any progress in this? I have this same problem.

You can try add some log lines in these callbacks to see if this extension is registered correctly.
https://github.com/sphinx-contrib/sphinxcontrib-versioning/blob/86a28dc92ce3ff42ed36a8b3e4dc6bdcff90f2c4/sphinxcontrib/versioning/sphinx_.py#L47
https://github.com/sphinx-contrib/sphinxcontrib-versioning/blob/86a28dc92ce3ff42ed36a8b3e4dc6bdcff90f2c4/sphinxcontrib/versioning/sphinx_.py#L65

I added simple print commands to see if the two functions were called and finished.
Both function weren't called before the programm freezed

@vancheese Then the extension itself is not registered properly. Can you post the conf.py and command that failed?

I've identified where the program freeze
In sphinx_.py in read_config, the program stops at
config = queue.get()

I've found that applying the patch from #46, then applying the argv[1:] fix and #66 makes the build system work and not stall anymore...
This may be because of sphinx version uncompatibility, because the fixes themselves end up stalling until #46 is applied

I've been hit by this as well and tried to figure out what broke in which sphinx versions.  I've used the Docker sphinx that I maintain for this and used the "quick-and-dirty" documentation from the tutorial for testing.

for 1.6.5 to work, I had to apply #46
for 1.7.0 to work, I had to apply #69 as well as the argv[1:] fix mentioned above in addition to #46
for 1.8.0 to work, I had to apply #57 in addition to the changes for 1.7.0 and 1.6.5
for 2.0.0 to work, I had to apply #57 in addition to the changes for 1.7.0 and 1.6.5

Version 2.0.1 is the first version where I observed the hang/freeze.  Apart from the sphinx version, there are no other differences between my Docker images for 2.0.0 and 2.0.1.  The changes between those two don't provide any clue, to me at least, what might have triggered this.

@paddy-hack The changes I spoke about in my last comment work on Sphinx 2.2.1

Hi,
i'm using the fork: https://github.com/Smile-SA/sphinx-versions installed from pip and all of the above patches are already applied but it still hangs from sphinx-2.0.1.
Have anyone tried this library?
@GlitchyPSIX does it work for you with patches you mentioned? #46 and #66

@dlopezlo Yes (sphinx 2.2.1), I have managed to get sphinxcontrib-versioning building properly by applying #46, #66, and the argv[1:] fix (I did them in this order)
Do remember to add the sphinxcontrib.versioning.sphinx_ extension in conf.py
I made a separate conf.py for when I want to build separately without versioning which doesn't have that extension using sphinx-build

With some real documentation, I also ran into #48, which is fixed in #51.

As for adding the sphinxcontrib.versioning.sphinx_ extension in conf.py, while that may be an obvious(?) thing to do, I didn't and it is not in the documentation, yet :cry:.
I'm off now giving that a try :crossed_fingers:

Adding sphinxcontrib.versioning.sphinx_ to the extensions array in conf.py fixes the hang with this caveat that you can only build documentation for versions that do.  If you try to build (older) versions of your documentation where the extension has not been added, the build will hang.
Fix confirmed to work on 2.0.1, 2.1.0, 2.1.2, 2.2.0 and 2.2.1 using the tutorial example with the extension added to conf.py.

After applying all those fixes I get the message:
miniconda3/envs/py35/lib/python3.5/site-packages/sphinxcontrib/versioning/sphinx_.py", line 101, in html_page_context
    cls.VERSIONS.context = context

Does anyone have the same issue? Or did I maybe do something wrong?

Adding sphinxcontrib.versioning.sphinx_ to the extensions array in conf.py fixes the hang with this caveat that you can only build documentation for versions that do. If you try to build (older) versions of your documentation where the extension has not been added, the build will hang.

My workaround for this is just a second conf.py in a separate directory made only for non-versioned building

I'm aware of your work around but that doesn't solve thing for documentation versions that have already been committed and pushed :cry:

@fmmix I got the same error when accidently running sphinx-build instead of sphinx-versioning.

@GlitchyPSIX I've resorted to conditionally added the extension based on an environment variable.  Since I normally only want to run sphinx-versionsing in CI (and sphinx-build during "development" of the documentation), I have added it like so
if 'CI' in os.environ and os.environ['CI'] == 'true':
    extensions.append('sphinxcontrib.versioning.sphinx_')

Works For Me :smile:

@paddy-hack Haha, yeah, figured this would be a solution
In the end that's kind of what I achieved with the second conf.py since I don't use CI but batch files to generate the respective documentation types
Maybe your solution can work for others facing this issue? Looks a bit more catch-all than my local-based case.

It took me a while but I finally figured it out for good.
I will not make a PR because I find the fix to be especially ugly but I leave it there as a git patch for those encountering the issue.
The bug happens starting from Sphinx 2.0.1 as some noticed and is due to the fact that the CONFIG_FILENAME attribute of the sphinx.application module was deprecated with a 3.0.0 deletion in mind. Now the Sphinx deprecation helper actually wrap the entire module in sys.modules into a _ModuleWrapper to wrap the module __getattribute__ to send a DeprecationWarning if the deprecated attribute is to be fetch. This is all good and all but it does breaks the attempt that sphinxcontrib.versioning makes to monkey patch the sphinx.application.Config object to auto-register sphinxcontrib.versioning.sphinx_ as an extension (which actually fixes the hang as previous comments found out) upon instantiation.
My UGLY hotfix bypasses the _ModuleWrapper explicitly and will not work for sphinx versions before the 2.0.1 and after at least the 3.0.0.
Index: sphinxcontrib/versioning/sphinx_.py
<+>UTF-8
===================================================================
--- sphinxcontrib/versioning/sphinx_.py	(revision f286d43595d75c08cb51a0153a9cdf3b8a1957b3)
+++ sphinxcontrib/versioning/sphinx_.py	(date<PHONE_NUMBER>030)
@@ -184,8 +184,13 @@
     :param str current_name: The ref name of the current version being built.
     :param bool is_root: Is this build in the web root?
     """
-    # Patch.
-    application.Config = ConfigInject
+    # Update monkey patch to work with Sphinx 2.0.1+ _ModuleWrapper addition around sphinx.application due to
+    # CONFIG_FILENAME deprecation.
+    # _ModuleWrapper does not redirect __setattr__ calls to the underlying module so we need to bypass it to inject
+    # the extension.
+    # This is ugly and will break starting from at least Sphinx 3.0+ but the idea of monkey patching the extension
+    # silently into sphinx was hackish at most to begin with.
+    application._module.Config = ConfigInject  # noqa
     if config.show_banner:
         EventHandlers.BANNER_GREATEST_TAG = config.banner_greatest_tag
         EventHandlers.BANNER_MAIN_VERSION = config.banner_main_ref

I needed a versioning tool for Sphinx but all existing projects that I found didn't work properly and their code was messy, so I decided to implement my own solution and published it here: https://holzhaus.github.io/sphinx-multiversion/master/index.html


Add FastAPI and Starlette as platform to "Create a new Project" screen in sentry.io

Problem Statement
FastAPI should be selectable as platform on the "Create a new Project" screen on sentry.io.
See this https://sentry.io/organizations/ignaz-software/projects/new/ (or similar, or just click on "Create Project" in the list of projects.
Solution Brainstorm

Find out if this does more then setting the name
Add the Logo to the list.

Here is the PR to make this work in Sentry: https://github.com/getsentry/sentry/pull/37048

Create new Project screens are live!


Revamp wallet view: display "accounts" as privacy levels

See the current design in Figma:

In short:

Hide derivation paths and addresses from the user
What is currently called "Account 0" is the lowest level, i.e. "one shield"

We can add the complexity that this will hide later on if we like, but the current view is all kinds of confusing, so this would be an improvement.
Note that this concept/design is by no means final, since we can't always map "privacy level" to "accounts" (mixdepths) in a truthful one-to-one manner. But again: it's a big improvement from the current UI and should be easier to understand than mixdepths.

Regarding the Overall Privacy Level indicator:

I'm using "privacy level" and "mixdepth" interchangeably here for simplicity.
I like the idea of an overall privacy level to motivate users. I'm wondering how should we compute this, though.
My first thought was simply computing a weighted average over all coins in all privacy levels. While implementing I started to doubt that this makes sense.
My thinking is this: Let's say you have one coin with privacy level 1⃣ and another coin with privacy level  5⃣ .
The overall average privacy level would then be 3⃣ .
But if you spend the coin with privacy level 1⃣ you don't get privacy as if it were a coin with privacy level level 3⃣ . All you get is privacy level 0⃣ . This might be confusing for the user who I could assume that the overall privacy level applies to all coins when in reality it is just the average but doesn't relate to the actual privacy of individual coins.


Add more metrics for sort command

Users can now sort client list by birthdays, income and risk appetite

Codecov Report
Base: 52.57% // Head: 52.10% // Decreases project coverage by -0.47% :warning:

Coverage data is based on head (4676f36) compared to base (a66763b).
Patch coverage: 12.00% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master      #59      +/-   ##
============================================
- Coverage     52.57%   52.10%   -0.48%
- Complexity      435      438       +3
============================================
  Files           101      101
  Lines          1997     2021      +24
  Branches        232      237       +5
============================================
+ Hits           1050     1053       +3
- Misses          877      898      +21
  Partials         70       70

Impacted Files
Coverage Δ

...java/longtimenosee/logic/commands/SortCommand.java
0.00% <0.00%> (ø)

...rc/main/java/longtimenosee/model/person/Email.java
42.85% <ø> (ø)

.../java/longtimenosee/model/person/RiskAppetite.java
56.75% <8.33%> (-23.25%)
:arrow_down:

...main/java/longtimenosee/model/person/Birthday.java
47.50% <50.00%> (+0.13%)
:arrow_up:

...c/main/java/longtimenosee/model/person/Income.java
48.97% <50.00%> (+0.04%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


move bin functionality to the main lib

At the moment there is too much functionality coded in https://github.com/Blahah/transrate/blob/master/bin/transrate. We should move everything that isn't only relevant to running that file into classes in the main library (probably all into Transrater). i.e., only the argument parsing and intialising and running a Transrater should be left in the bin

I actually think that we should reduce the binary to just a few lines, so everything is testable. For example see http://technicalpickles.com/posts/managing-binaries-with-jeweler/


enable CPU load

Without this change, I am still getting this error
(bgm2) seki@xubuntu-20:~/src/BackgroundMattingV2$ python inference_video.py --model-type mattingrefine --model-backbone resnet101 --model-checkpoint Model/PyTorch/pytorch_resnet101.pth --video-src ../zerobox-v2/resource/group15B_Short.avi --video-bgr ../zerobox-v2/resource/background_group15B.png --output-dir output_video_group15B --output-type com fgr pha err ref --device cpu
/home/seki/miniconda3/envs/bgm2/lib/python3.8/site-packages/torch/cuda/__init__.py:52: UserWarning: CUDA initialization: Found no NVIDIA driver on your system. Please check that you have an NVIDIA GPU and installed a driver from http://www.nvidia.com/Download/index.aspx (Triggered internally at  /pytorch/c10/cuda/CUDAFunctions.cpp:100.)
  return torch._C._cuda_getDeviceCount() > 0
Traceback (most recent call last):
  File "inference_video.py", line 128, in <module>
    model.load_state_dict(torch.load(args.model_checkpoint), strict=False)
  File "/home/seki/miniconda3/envs/bgm2/lib/python3.8/site-packages/torch/serialization.py", line 594, in load
    return _load(opened_zipfile, map_location, pickle_module, **pickle_load_args)
  File "/home/seki/miniconda3/envs/bgm2/lib/python3.8/site-packages/torch/serialization.py", line 853, in _load
    result = unpickler.load()
  File "/home/seki/miniconda3/envs/bgm2/lib/python3.8/site-packages/torch/serialization.py", line 845, in persistent_load
    load_tensor(data_type, size, key, _maybe_decode_ascii(location))
  File "/home/seki/miniconda3/envs/bgm2/lib/python3.8/site-packages/torch/serialization.py", line 834, in load_tensor
    loaded_storages[key] = restore_location(storage, location)
  File "/home/seki/miniconda3/envs/bgm2/lib/python3.8/site-packages/torch/serialization.py", line 175, in default_restore_location
    result = fn(storage, location)
  File "/home/seki/miniconda3/envs/bgm2/lib/python3.8/site-packages/torch/serialization.py", line 151, in _cuda_deserialize
    device = validate_cuda_device(location)
  File "/home/seki/miniconda3/envs/bgm2/lib/python3.8/site-packages/torch/serialization.py", line 135, in validate_cuda_device
    raise RuntimeError('Attempting to deserialize object on a CUDA '
RuntimeError: Attempting to deserialize object on a CUDA device but torch.cuda.is_available() is False. If you are running on a CPU-only machine, please use torch.load with map_location=torch.device('cpu') to map your storages to the CPU.

@jinzishuai Looks good to me. Thanks!


badge request

Username and Discrim: encezo#1223
User ID:<PHONE_NUMBER>44491550
Image Link: https://cdn.discordapp.com/attachments/815624770430566460/819632707591864370/romaniabecausewhynot.png

done!

Thank you!


merge from template-coveralls

package.json

chore(deps): add ^10.0.3 remove ^10.0.2 (devDependencies.@semantic-release/commit-analyzer)
chore(deps): add ^12.0.0 remove ^11.10.15 (devDependencies.npm-pkgbuild)

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

npm package (@latest dist-tag)
v6.4.5
GitHub release

Your semantic-release bot :package::rocket:


[FLINK-33698][datastream] Fix the backoff time calculation in ExponentialBackoffDelayRetryStrategy

What is the purpose of the change
Fix the backoff time calculation in ExponentialBackoffDelayRetryStrategy.
Brief change log
The backoff time calculation in ExponentialBackoffDelayRetryStrategy should consider currentAttempts. It should generate consistent backoff time for specific attempt count.
Verifying this change
This change added tests and can be verified as follows:

Added unit test in  AsyncRetryStrategiesTest

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no

@lincoln-lil hi, could help review when you have time?


Error when taking max of empty array

awkward-array gives an error if an array is completely empty and you try to take the maximum.
Minimum code to reproduce the problem:
test = awkward.fromiter([])
print test.max()
It breaks with the following error. The error can be avoided by first checking if test.size > 0.
ValueError                                Traceback (most recent call last)
 in ()
3 if test.size <= 0:
4     print "okay"
----> 5 print test.max()
/Users/ahall/.local/lib/python2.7/site-packages/numpy/core/_methods.pyc in _amax(a, axis, out, keepdims, initial)
26 def _amax(a, axis=None, out=None, keepdims=False,
27           initial=_NoValue):
---> 28     return umr_maximum(a, axis, None, out, keepdims, initial)
29
30 def _amin(a, axis=None, out=None, keepdims=False,
ValueError: zero-size array to reduction operation maximum which has no identity

I've looked into this, and while I found and fixed a few corner-case bugs by stressing different ways of having empty lists, I didn't find a place where numpy.maximum or numpy.minimum is mistakenly applied to an empty Numpy array (which is what I was worried about).
Your example above will still fail because awkward.fromiter([]) returns an empty Numpy array, which will always complain about emptyarray.max(). I wish it wouldn't, but I can't change Numpy.
Here's an illustration, using awkward.type.fromarray to show how it depends on the type of the array:
>>> flat = awkward.fromiter([])
>>> type(flat)
<class 'numpy.ndarray'>
>>> print(awkward.type.fromarray(flat))
[0, 0) -> float64
>>> # which is to say that it takes an integer in the interval [0, 0) and returns a float
>>>
>>> jagged = awkward.JaggedArray([], [], [])   # no starts, no stops, no content
>>> type(jagged)
<class 'awkward.array.jagged.JaggedArray'>
>>> print(awkward.type.fromarray(jagged))
[0, 0) -> [0, inf) -> float64
>>> # which is to say that it takes an integer in [0, 0) and returns something that takes any integer, which in turn returns a float
>>>
>>> flat.max()    # expect it to fail because "flat" is a numpy.ndarray
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/miniconda3/lib/python3.7/site-packages/numpy/core/_methods.py", line 28, in _amax
    return umr_maximum(a, axis, None, out, keepdims, initial)
ValueError: zero-size array to reduction operation maximum which has no identity
>>>
>>> jagged.max()    # we want it to pass because "jagged" is a JaggedArray
array([], dtype=float64)


plugin 'opus' not found

Hi
I build all plugins required to run webrtc-sendrec and although the opus in plugins-bad has been built and installed (to /usr/local/lib/gstreamer-1.0/libgstopusparse.so and libgstopusparse.la), I get the error message:
required gstreamer plugin 'opus' not found

What could be the problem?
Ubuntu 16.04, gstreamer (& plugins): 1.14.1
Best
Stefan

I believe you'll need:
./usr/lib/gstreamer-1.0/libgstopusparse.la
./usr/lib/gstreamer-1.0/libgstopusparse.so
./usr/lib/gstreamer-1.0/libgstopus.la
./usr/lib/gstreamer-1.0/libgstopus.so

How are you building?

@SUlbrichA make sure that you have opus-tools and gst-plugins-base installed
https://gstreamer.freedesktop.org/documentation/plugins.html

@SUlbrichA If you would like a reference this is a working debian build with necessary dependencies: https://github.com/maxmcd/gstreamer-docker/blob/master/1.14/buster/Dockerfile

@maxmcd Awesome thank you that definitively helps cleaning up my setup!


Runelite Crashing daily/hourly

Describe the bug
During CoX I tend to crash the most right before Olm room, other times its just random. I've reinstalled RL multiple times, made sure java/drivers are all up to date and nothing helps.
I have a decent PC. R7 1700x with an rtx 2060 so I assume it doesn't have anything to do with these, although I did see posts talking about the gpu plugin being the issue but nothing to back it up. I'll also post logs on the most recent crash, I have others if needed.
client_2020-06-03.0.log
jvm_crash_pid_17440.log
client_2020-06-02.0.log
jvm_crash_pid_15676.log

Your launcher log shows no signs of issues. You should upload your client log file and/or any hs_err_pid or jvm_crash_pid files from the day(s) you experienced crashes.

jvm_crash_pid_17440.log
jvm_crash_pid_15676.log
jvm_crash_pid_17764.log

Updated with client/jvmcrash for two days.

Does this happen on the latest release of RuneLite?
Join us at https://runelite.net/discord in the #support channel so we can fix this issue for you.

Does this happen on the latest release of RuneLite?
Join us at https://runelite.net/discord in the #support channel so we can fix this issue for you.

Closing as this was very likely a duplicate report of #10628


Ideas for getting the image preview associated with a Lora?

the python enumerations are a nice touch. Though, some of the names of the loras I have are not enough for me to remember what they are going to influence. Any ideas on how to have VSCode show an image preview when looking at the enumerations?

Interesting, I didn't think it's supported before. It's possible to generate previews for models and then display the preview files. If I'm lucky, I can find a custom node and use it.


Make storage and mmr trait async, attempt 2.

addresses #108, #75
obsoletes #120
This is a second pass at making the storage layer async in neptune-core.
note: I've added some background context here.
The first attempt in #120 is simpler and affects less code in neptune-core.  Also, all of the existing tests compile and pass.  But it had a serious inefficiency with ArchivalMmr, where sync and async worlds collided.   I encourage reviewer(s) to read #120, including comments, and perhaps ArchivalMmr code for background first.
If some way could be found to decouple ArchivalMmr from the Mmr trait, that might allow us to use the simpler code in #120.   However, I do not see any simple solution because a lot of code is generic over the Mmr trait.  Perhaps a reviewer might?
This second attempt builds on #120 (strict superset) and makes the Mmr trait async (in neptune-core only) which resolves the ArchivalMmr issue, though at the cost of requiring much more code to become async, and requiring some tests and test-related infrastructure to be commented out.  See notes below.
I believe this is the more correct, performant, and idiomatic implementation, and should be the one we move forward with, although it presents a few challenges.
This PR does still have one inefficiency in tasm::RemovalRecordsIntegrity::rust_shadow(), whereby it spawns an OS thread for each invocation.   I am unsure how frequently it is called.  Perhaps it can be modified not to call any async method, or refactored out.   Reviewers, please have a look.
To facilitate reviewing, I have compiled a summary of changes:
async_storage_pr_notes.txt
If this PR is merged, we will want to find a solution for async proptests, which I have commented out for now.   There is a new proptest_async crate, however it presently only works with async_std, not tokio.   Last night I sent the author an offer to help add a tokio feature-flag, and have not yet heard back.  Anyway, that seems a path forward.
The arbitrary crate does not provide an async trait, so I had to comment out impl Arbitrary in 4 cases.  (These seem like they should be inside test module anyway.)  I did a quick look for an async fork of arbitrary crate, but didn't find anything right away.   I imagine/hope that some alternative exists in the async ecosystem.
This PR depends on specific revisions of twenty-first and tasm-lib in git.  Those revisions now exist in master for each repo, so we need only make a new release for each, and also for triton-vm, which depends on twenty-first.
Testing

all tests and doctests are passing (for me, rust 1.75) except of course for the disabled proptests.
I need to update to latest rust, and fix some clippy errors that github is encountering.
I ran run-multiple-instances-from-genesis.sh and all 3 nodes start and init databases correctly, and are able to mine blocks.  Some warnings and errors are encountered related to POW difficulty.   I'm unsure if these are caused by the async changes (doubtful), or would happen on master also.  (todo: verify)

Runtime warnings/errors encountered:
WARN ThreadId(05) neptune_core::models::blockchain::block: Block digest exceeds target difficulty
ERROR ThreadId(05) neptune_core::mine_loop: Own mined block did not have valid PoW Discarding.
Running consensus program with input:<PHONE_NUMBER>8499205127,5472989617886819963,225249538409389332,14351683435638599318,7410669378538831243,9174421884590172073,10850780262550797792,11552744393070458998,2538672691563304706,8964411581216926690,13736493314391979227,1283618371588003095,6648510168461056029,8044674294685951522,2194367602604877769

2024-03-23T23:09:10.792606151Z  WARN ThreadId(05) neptune_core::models::blockchain::block: Block digest exceeds target difficulty
2024-03-23T23:09:10.792639065Z  WARN ThreadId(05) neptune_core::peer_loop: Received invalid proof-of-work for block of height 1 from peer with IP [::ffff:<IP_ADDRESS>]:38738
2024-03-23T23:09:10.792664099Z  WARN ThreadId(05) neptune_core::peer_loop: Difficulty is 2.
2024-03-23T23:09:10.794105804Z  WARN ThreadId(05) neptune_core::peer_loop: Proof of work should be<PHONE_NUMBER>4707292160,09223372034707292160,09223372034707292160,09223372034707292160,09223372034707292160 (or more) but was [18297266674924710731,<PHONE_NUMBER>1069217700,<PHONE_NUMBER>8005091088,<PHONE_NUMBER>5731355199,<PHONE_NUMBER>1540981647].
2024-03-23T23:09:10.795479734Z  WARN ThreadId(05) neptune_core::peer_loop: Sanctioning peer ::ffff:<IP_ADDRESS> for InvalidBlock((BlockHeight(BFieldElement(4294967295)), Digest([BFieldElement(539001808393609628), BFieldElement(6909788068636440929), BFieldElement(6493292427912708903), BFieldElement(18261214943504998237), BFieldElement(15830763525737866356)])))
2024-03-23T23:09:10.795678886Z  WARN ThreadId(05) neptune_core::peer_loop: Failed to validate block due to insufficient PoW. Closing connection.
...
2024-03-23T23:09:10.799150404Z ERROR ThreadId(04) neptune_core::main_loop: Got error: Failed to validate block due to insufficient PoW

Stack backtrace

2024-03-23T23:07:21.786028273Z  WARN ThreadId(02) neptune_core::mine_loop: Received block is timestamped in the future; mining on future-timestamped block.

I notice that checks are failing due to clippy errors.  I think this is because github is using latest rust toolchain, and I am still on 1.75.   I will update, and fix any errors it reports.

Some extra context may be helpful for reviewers, as a starting point.
The groundwork for this PR began with NeptuneLevelDb, which was made async a while back.   This was done by wrapping every levelDb method with tokio's spawn_blocking API.   Example:
    pub async fn put_u8(&mut self, key: Vec<u8>, value: Vec<u8>) {
        let mut inner = self.0.clone();
        task::spawn_blocking(move || inner.put_u8(&key, &value))
            .await
            .unwrap()
    }

The LevelDB API itself remains sync of course, however spawn_blocking() informs tokio that a blocking sync call is being made, so tokio can run that on a separate OS thread in its thread-pool, and other tasks in the current thread can continue being polled meanwhile.
So that's been working already for some DB accesses, but not for DbtVec, DbtSingleton, and RustyLevelDbVec, which are heavily used in neptune-core.  Those types still used the direct LevelDb API from twenty-first.
So the foundational work of this PR was to modify the storage layer to use the async NeptuneLevelDb APIs.  This required replacing iterators with async streams, and some other changes.    Once that was done, all the rest was largely a mechanical exercise of fixing everything that broke as a result.
The primary challenges were due to trait entanglement from crates twenty-first, tasm-lib, and even arbitrary.  I've documented that elsewhere, so won't go into detail here.

This PR does still have one inefficiency in tasm::RemovalRecordsIntegrity::rust_shadow(), whereby it spawns an OS thread for each invocation. I am unsure how frequently it is called. Perhaps it can be modified not to call any async method, or refactored out. Reviewers, please have a look.

It looks like this function needs to be async because the trait functions Mmr::bag_peaks and Mmr::count_leaves are async, and these are called on objects swbf_inactive and aocl, which are MMR accumulators and not archival MMRs.
Was it the intention to make member functions of accumulator objects async, or was this an unintended consequence of making the trait Mmr async? If the latter, then I suggest killing the trait.

Was it the intention to make member functions of accumulator objects async, or was this an unintended consequence of making the trait Mmr async?

That is the primary difference between PR #120 and this one.   We have both paths available to choose from.
In 120, the Mmr trait is sync, and ArchivalMmr implements the sync methods by spawning OS threads to call async methods for storage.    MmrAccumulator and a bunch of things that use it, eg MutatorSetKernel remain sync.
In this one, the Mmr trait is made async, which forces MmrAccumulator and everything that uses it to also become async.
One additional consideration:  I imagine that triton-vm execution of some scripts will be CPU intensive and comparitively long running.  tokio docs make it clear that CPU-heavy (long running) function calls harm concurrency, just as blocking I/O does, and should be wrapped with spawn_blocking() if they can't be made async directly.  I have not performed any analysis in this area yet, but it may turn out that there is benefit to having MmrAccumulator, MutatorSetKernel and related areas of neptune-core be async.   So anyway, that's been at the back of my mind while working on this stuff.

If the latter, then I suggest killing the trait.

Yeah, so that would be nice if we can make it work without duplicating a mountain of code.   In fact I suggested the possibility above:

If some way could be found to decouple ArchivalMmr from the Mmr trait, that might allow us to use the simpler code in #120. However, I do not see any simple solution because a lot of code is generic over the Mmr trait. Perhaps a reviewer might?

Indeed I already attempted this briefly, and quickly found it was complex.   I discussed it here.
Expanding on that explanation, I believe this is a complete list of places that require the Mmr trait:
$ find src -type f | xargs grep " Mmr<" | grep -v _mmr.rs | grep -v tor.rs | grep -v traits.rs
src/util_types/test_shared/mutator_set.rs:pub async fn insert_mock_item<M: Mmr<Hash>>(
src/util_types/test_shared/mutator_set.rs:pub async fn remove_mock_item<M: Mmr<Hash>>(
src/util_types/mutator_set/ms_membership_proof.rs:    pub async fn batch_update_from_addition<MMR: Mmr<Hash>>(
src/util_types/mutator_set/removal_record.rs:    pub async fn batch_update_from_addition<MMR: Mmr<Hash>>(
src/util_types/mutator_set/removal_record.rs:        M: Mmr<Hash>,
src/util_types/mutator_set/mutator_set_kernel.rs:pub struct MutatorSetKernel<MMR: Mmr<Hash>> {
src/util_types/mutator_set/mutator_set_kernel.rs:impl<M: Mmr<Hash>> MutatorSetKernel<M> {
src/util_types/mutator_set/mutator_set_kernel.rs:impl<MMR: Mmr<Hash> + BFieldCodec> BFieldCodec for MutatorSetKernel<MMR> {

Each of those would need to be re-written to work for both sync and async scenarios.  But then anything that calls them with an ArchivalMmr would need to be async anyway, which appears to be a lot of code.   So in the end, much of it needs to become async anyway.
at least that's how it appears to me, but.....
@aszepieniec you understand this area of the code much better than I do.  So if you can see a clear path to getting rid of the Mmr trait, then perhaps you could start a branch based off make_storage_async (from 120) for us to collaborate on.  If you could set the direction and perhaps get the thing to build without tests, I'd be happy to finish up whatever needs doing like getting tests working, etc.  So that might be an option.
or anyway, please let me know your thoughts.

Thanks for clarifying. There's a lot to think about and most of the time I'm silent it's because I don't have a qualified opinion.

So if you can see a clear path to getting rid of the Mmr trait, then perhaps you could start a branch based off make_storage_async (from 120) for us to collaborate on.

I will consider that, but you should know that there are also other things vying for my attention.
In regards to the Mmr trait, I think it came about by accident. It may have benefited the process of writing the code in the first place, but I doubt that there is a code-architecture reason to keep it. That said, maybe getting rid of it is more hassle than it's worth.
As for the complexity of operations: I did not run any benchmarks but raison d'être for the accumulator variants is their light footprint. Phrased differently, if making them async can be justified on the basis of their long-running CPU profile, then we are doing something very wrong and should reconsider the architecture.

Just a note that the author of proptest_async crate notified me that he has added tokio support.  We don't seem to need async proptests right now, as we are moving forward with #124 instead of this PR, however its good to know it exists for possible future tests.

If this PR is merged, we will want to find a solution for async proptests, which I have commented out for now. There is a new proptest_async crate, however it presently only works with async_std, not tokio. Last night I sent the author an offer to help add a tokio feature-flag, and have not yet heard back. Anyway, that seems a path forward.

closing in favor of #124.


Ports might be undefined

In this case, don't do anything. The reason for this is that Elm does dead code elimination, so if the port is not used yet, it will be undefined. Additionally, it might be the user doesn't need the wnfs stuff, so they could skip that port definition and just do the webnative one.

In this case, don't do anything

Do print a warning. If the user intended to use the port but made a typo it'd otherwise fail silently.

In this case, don't do anything

Do print a warning. If the user intended to use the port but made a typo it'd otherwise fail silently.

Fixed in v2

Fixed in v2


Added Support for Typescript

As explained on this Thread the approach of extending the behaviour of Phaser's core classes by adding methods and properties to them, makes the game incompatible with Typescript. That's because it's not possible in Typescript to merge class definitions.
This pull request solves this problem by adding references that are not extending Phaser's core classes. More specifically

Added a property to projector where it was before accessed by game.iso
Added a method addIsoSprite() where it was before accessed by game.add.isoSprite

The other important addition is the inclusion of phaser.plugin.isometric.d.ts file with Typescript Definitions. It's still not complete, but should be enough to run the examples on the website.

Hi,
I'm new to typescript/Phaser and I'm trying to convert the example from the website "Pointer interaction" to typescript but I'm blocking on how to replace game.iso by projector and game.add.isoSprite by addIsoSrpite.
My preload look like this :
preload() {
    this.game.plugins.add(Phaser.Plugin.Isometric);
    this.game.iso.anchor.setTo(0.5, 0.2);
}

and spawnTiles :
spawnTiles() {
    var tile;
    for (var xx = 0; xx < 256; xx += 38) {
        for (var yy = 0; yy < 256; yy += 38) {
            tile = this.game.add.isoSprite(xx, yy, 0, 'tile', 0, this.isoGroup);
            tile.anchor.set(0.5, 0);
         }
    }
}


chatbot error

Getting error on running the below code in pydev in eclipse:
from chatterbot import ChatBot
from chatterbot.trainers import ListTrainer
chatbot = ChatBot('Charlie')
trainer = ListTrainer(chatbot)
trainer.train([
"Hi, can I help you?",
"Sure, I'd like to book a flight to Iceland.",
"Your flight has been booked."
])
response = chatbot.get_response('I would like to book a flight.')
print(response)
Error:
Traceback (most recent call last):
File "D:\Users\ABiswa14\eclipse-workspace\PyDev\src\chatbot.py", line 4, in
chatbot = ChatBot('Charlie')
File "D:\Users\ABiswa14\AppData\Local\Programs\Python\Python38-32\lib\site-packages\chatterbot\chatterbot.py", line 34, in init
self.storage = utils.initialize_class(storage_adapter, **kwargs)
File "D:\Users\ABiswa14\AppData\Local\Programs\Python\Python38-32\lib\site-packages\chatterbot\utils.py", line 54, in initialize_class
return Class(*args, **kwargs)
File "D:\Users\ABiswa14\AppData\Local\Programs\Python\Python38-32\lib\site-packages\chatterbot\storage\sql_storage.py", line 22, in init
from sqlalchemy import create_engine
File "D:\Users\ABiswa14\AppData\Local\Programs\Python\Python38-32\lib\site-packages\sqlalchemy_init_.py", line 8, in
from . import util as util  # noqa
File "D:\Users\ABiswa14\AppData\Local\Programs\Python\Python38-32\lib\site-packages\sqlalchemy\util_init.py", line 14, in
from ._collections import coerce_generator_arg  # noqa
File "D:\Users\ABiswa14\AppData\Local\Programs\Python\Python38-32\lib\site-packages\sqlalchemy\util_collections.py", line 16, in
from .compat import binary_types
File "D:\Users\ABiswa14\AppData\Local\Programs\Python\Python38-32\lib\site-packages\sqlalchemy\util\compat.py", line 264, in
time_func = time.clock
AttributeError: module 'time' has no attribute 'clock'

A number of people have posted about this error. This is because of a comparability issue in sqlalchemy when running in Python 3.8.
https://github.com/sqlalchemy/sqlalchemy/issues/4731
I think this issue might already be fixed on the 1.0 branch, but I have to do a release to PyPi before it will be available.

Duplicate of #1941


Make Get-WillowInstalledProducts public

I'd like to use Get-WillowInstalledProducts from chocolatey-visualstudio.extension to check if VS2017 is installed as a dependency of a package for installing a VS2017 extension.
It would be great if Get-WillowInstalledProducts was exported publicly so I could use it more easily.

That function is really a short-term hack; it relies on undocumented VS internals, which may change with any VS update. I am currently working on making the official VSSetup PowerShell module usable by Chocolatey. Once that PR is accepted, I'll probably remove that function or reimplement it as a thin wrapper over Get-VSSetupInstance.
Until then, you could use the vswhere.exe tool (which is already available on chocolatey.org).
(Besides, if that function was to be made public, it would definitely need a better name...)

On second thought, I do see the value in having this function available from chocolatey-visualstudio.extension, regardless of its implementation (in fact, hiding the technical details is part of the value). Any ideas for a nice, official name (Get-VisualStudio...)?

Get-VisualStudio seams reasonable

I was thinking about a more descriptive/precise name, something that would convey the meaning of the current one ("gets all instances of Visual Studio products installed using the VS 2017 (or later) 'Willow' installer") but start with "VisualStudio" as other public functions of this extension do.
(Yes, naming is hard 😉)
Get-VisualStudioInstance? It could be enhanced to return basic info about VS 2015 and earlier, like vswhere.exe does.

That's good too :-)

Here's the proposed shape of objects returned by the new public function. It will return PSObjects with properties:
InstallationPath - the path of the instance, e.g. C:\Program Files (x86)\Microsoft Visual Studio\2017\Community
InstallationVersion - a System.Version object, e.g. 15.0.26228.9
ProductId - e.g. Microsoft.VisualStudio.Product.Community
ChannelId - e.g. VisualStudio.15.Release
(the two latter properties will be empty for instances of Visual Studio 2015 and earlier)
I chose a minimal set of properties easily obtainable either using the VSSetup PS module or from vswhere.exe (I don't know whether I will be able to use the PS module). Will this be enough for your use case?

That's more than enough for me. My case is just to test if 2017 is installed or not
Get Outlook for iOShttps://aka.ms/o0ukef

From: Jakub Berezanski<EMAIL_ADDRESS>Sent: Thursday, May 11, 2017 5:32:59 AM
To: jberezanski/ChocolateyPackages
Cc: David Gardiner; Author
Subject: Re: [jberezanski/ChocolateyPackages] Make Get-WillowInstalledProducts public (#12)
Here's the proposed shape of objects returned by the new public function. It will return PSObjects with properties:
InstallationPath - the path of the instance, e.g. C:\Program Files (x86)\Microsoft Visual Studio\2017\Community
InstallationVersion - a System.Version object, e.g. 15.0.26228.9
ProductId - e.g. Microsoft.VisualStudio.Product.Community
ChannelId - e.g. VisualStudio.15.Release
(the two latter properties will be empty for instances of Visual Studio 2015 and earlier)
I chose a minimal set of properties easily obtainable either using the VSSetup PS module or from vswhere.exe (I don't know whether I will be able to use the PS module). Will this be enough for your use case?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/jberezanski/ChocolateyPackages/issues/12#issuecomment-300596425, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAXe67cHwg_cbIW-HOixwX3qrVXUdXkQks5r4hfzgaJpZM4NQayZ.

@flcdrg here's something for you to test:
https://www.myget.org/feed/jberezanski-chocolateypackages-dev/package/nuget/chocolatey-visualstudio.extension/1.3.0
https://github.com/jberezanski/ChocolateyPackages/tree/visualstudio2017enterprise
PS C:\> cup -y chocolatey-visualstudio.extension --source https://www.myget.org/F/jberezanski-chocolateypackages-dev/api/v2
(...)
PS C:\> ipmo C:\ProgramData\Chocolatey\extensions\chocolatey-visualstudio\chocolatey-visualstudio.extension.psm1
PS C:\> Get-VisualStudioInstance | fl

ProductId           : Microsoft.VisualStudio.Product.Community
InstallationPath    : C:\Program Files (x86)\Microsoft Visual Studio\2017\Community
ChannelId           : VisualStudio.15.Release
InstallationVersion : 15.0.26403.0

ProductId           : Microsoft.VisualStudio.Product.Enterprise
InstallationPath    : C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise
ChannelId           : VisualStudio.15.Release
InstallationVersion : 15.0.26403.0

ProductId           : Microsoft.VisualStudio.Product.TeamExplorer
InstallationPath    : C:\Program Files (x86)\Microsoft Visual Studio\2017\TeamExplorer
ChannelId           : VisualStudio.15.Release
InstallationVersion : 15.0.26403.0

ProductId           :
InstallationPath    : C:\Program Files (x86)\Microsoft Visual Studio 14.0\
ChannelId           :
InstallationVersion : 14.0

yeah, that looks nice. Works on mine too.
On 17 May 2017 at 06:42, Jakub Berezanski<EMAIL_ADDRESS>wrote:

@flcdrg https://github.com/flcdrg here's something for you to test:
https://www.myget.org/feed/jberezanski-chocolateypackages-dev/
package/nuget/chocolatey-visualstudio.extension/1.3.0
https://github.com/jberezanski/ChocolateyPackages/tree/
visualstudio2017enterprise
PS C:> cup -y chocolatey-visualstudio.extension --source https://www.myget.org/F/jberezanski-chocolateypackages-dev/api/v2
(...)
PS C:> ipmo C:\ProgramData\Chocolatey\extensions\chocolatey-visualstudio\chocolatey-visualstudio.extension.psm1
PS C:> Get-VisualStudioInstance | fl
ProductId           : Microsoft.VisualStudio.Product.Community
InstallationPath    : C:\Program Files (x86)\Microsoft Visual Studio\2017\Community
ChannelId           : VisualStudio.15.Release
InstallationVersion : 15.0.26403.0
ProductId           : Microsoft.VisualStudio.Product.Enterprise
InstallationPath    : C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise
ChannelId           : VisualStudio.15.Release
InstallationVersion : 15.0.26403.0
ProductId           : Microsoft.VisualStudio.Product.TeamExplorer
InstallationPath    : C:\Program Files (x86)\Microsoft Visual Studio\2017\TeamExplorer
ChannelId           : VisualStudio.15.Release
InstallationVersion : 15.0.26403.0
ProductId           :
InstallationPath    : C:\Program Files (x86)\Microsoft Visual Studio 14.0
ChannelId           :
InstallationVersion : 14.0
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jberezanski/ChocolateyPackages/issues/12#issuecomment-301917105,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXe61n0RA4IrK42FJbMOJuqihn0tw9Lks5r6hFGgaJpZM4NQayZ
.

Great, I'll release it in a few hours.

https://chocolatey.org/packages/chocolatey-visualstudio.extension/1.3.0

@flcdrg I'm assuming the released version works for you - can we close this issue now?

Yes, thanks
Get Outlook for iOShttps://aka.ms/o0ukef

From: Jakub Berezanski<EMAIL_ADDRESS>Sent: Sunday, May 28, 2017 4:44:38 AM
To: jberezanski/ChocolateyPackages
Cc: David Gardiner; Mention
Subject: Re: [jberezanski/ChocolateyPackages] Make Get-WillowInstalledProducts public (#12)
@flcdrghttps://github.com/flcdrg I'm assuming the released version works for you - can we close this issue now?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/jberezanski/ChocolateyPackages/issues/12#issuecomment-304471053, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAXe6whUGwf6E_sUGeFuMDuWxhfhJmo7ks5r-HYegaJpZM4NQayZ.


speed up local build time by 97%

skip the exhaustive generateBucketValueDistribution when we're not testing on Travis Linux builds

@optimizely/fullstack-devs


Can you make basic guide?

I never use Docker before, I want to launch server for my friends via DigitalOcean, Can you make Quickstart Basic (Noob) Guide ?

Absolutely!

Absolutely! This repo technically has two tools inside of it, if you have a VPS or just a server you dont have to do docker if you want to install and run it the traditional way. (Thats what the Odin tool is about) But I can write up a docker guide in the discussions :)

Please write up docker guide 👯

Let me know if I need to add more details <3 see discussion #28


Investigate @Modulithic as alternative to @Modulith

Replacing @SpringBootApplication might alienate some users as it doesn't actually change anything about the actual execution at runtime. In general, Moduliths works just fine with a plain @SpringBootApplication annotated app. The additional attributes contained in @Modulith only contain additional metadata, advanced customization needs etc.
We could provide an @Modulithic to add to the existing annotation arrangement so that it can augment metadata if needed but would allow users to not touch their production code at all. On top of that the combination of the annotations reads nice:
@Modulithic
@SpringBootApplication
class Application { … }

Here is a Twitter poll to decide between the two options. We could easily support both models side by side, too.

A benefit of a standalone application is that we don't have to replicate and alias all of the attributes within @SpringBootApplication.


Make media files searchable/sortable by alpha/date

@milesleif I've added this functionality to all panels now, Media included (however, date sorting doesn't work there, since change dates are not available in list form for binary files yet).
Does it work the way you were expecting?

@silend is this issue OK to close?

@mrzapp Very okay, great solution!


Mongoid 2.3.0 undefined method `reload'

Just tried upgrading to Mongoid 2.3.0 and am getting the following error on startup:
undefined method `reload' for module `Mongoid::Document'

It looks like there were some changes to how documents are reloaded in the latest Mongoid, but I've been unable to figure out how they are affecting validates_timeliness
https://github.com/mongoid/mongoid/commit/16d6f2f34fa3347376bc883e8aea300a1537ddc2

I've also just hit this issue.

My temporary fix for this is to use Mongoid 2.3.1.  It appears that the change to the reload implementation was incorporated for 2.3.2.

I've fixed this on my own branch with the following modification.  I haven't yet had a chance to perform any testing or validation that this actually still works, but at least I'm able to boot my app:
https://github.com/benzittlau/validates_timeliness/commit/3fdd3aa20c1f610a20bb968942e4419f97d6d64c

Thanks for the work guys. Sorry I am slow on this as I am on limited internet at the moment. This fix for this should now be easier than using alias_method_chain. Since the method is not defined on Document any more we can just define it in the Mongoid shim and include that it the Ruby inheritance will look after it.
Only issue is backwards compatibility. I will have a look into it more shortly.

I have pushed a fixed for this. Please verify it.

Yep seems to be working now. Will you be pushing this to a 3.0.8 gem?

Yep. Just wanted confirmation.
On 22/12/2011, at 12:26 PM, Nick<EMAIL_ADDRESS>wrote:

Yep seems to be working now. Will you be pushing this to a 3.0.8 gem?

Reply to this email directly or view it on GitHub:
https://github.com/adzap/validates_timeliness/issues/56#issuecomment-3242309


Update index.html

/check-cla

@AGH0RI , I am closing this pull request.
After you resolve the issue with your CLA, feel free to reopen this PR.
/close


⚠ Bofrost.at has degraded performance

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

HTTP code: 200
Response time: 1850 ms

Resolved: Bofrost.at performance has improved in 8a4da96.


Bug: Program hangs / starts dropping audio and stuttering on BT headphones

Describe the bug
So the last few weeks EqMac is very unstable. When using BT headphones the Audio starts to dropout every few seconds. When i disconnect the Headphones it's possible that the Audio is not switching back. Then i happens that the Browser starts hanging when playing Audio.
So i love the App but in the last times i have to restart my computer much more or stop the app and restart. It's a bit annoying.
Steps to Reproduce
Steps to reproduce the behaviour (feel free to change the placeholder as you need):
1.) Connect Bose BT 700 headphones
2.) Put Macbook to sleep and wake up
3.) Or Connect and Disconnect BT headphones and then play a youtube video
Setup information:

Audio device used for playback: Direct Audio / Bose BT headphones 700
Audio transmission interface: Bluetooth or 3.5mm Jack
macOS Version: 14.7 and 15
eqMac Version: 1.8.7
eqMac UI Version: 5.1.4
Browser: Brave

After that you have to kill and restart the program to solve the problem thats very annoying.
Here is an example. When activating the program it starts to hand and is unusable. Same problem in this case with the BT headphones. But it seems that no one cares about problems when paying and i will now stop my subscription.
https://github.com/user-attachments/assets/f1b87573-0e32-4296-98aa-ee054bbeeb24

Actually Netflix is stuttering and eqMac has load of 3000. Thats all really annoying and not really usable.

I have the same problem with the newest Version 1.8.8 this was a question in another ticket. Actually when i try to play a Youtube video it's stuttering. Other Applications working well. It seems that the is a problem with the Chrome Browser. When i start a video it's stuttering and the load goes to 3000. Mainly after the standby. Now i have to restart.
Same with BT it's stuttering every few seconds.

We're still looking into this and similar issues. Rest assured it's not just ignored, but the biggest issue is that we can't replicate this at all on 3 mac devices with different macOS versions and with multiple headphones making it much more difficult to debug and fix.
Currently I can't say if it's issue with bitrates, dev may know more about this but currently he's occupied with the update and I'd like to not interrupt his focus, but I'll ask when he'll have time it (I usually accumulate list of questions before bothering him).
The update he's working on however does include a big change to the driver and we're hoping this may also resolve stuttering and stop/play issues some people are experiencing.
It's not the case of 'no one cares about problems', we're just doing what's possible with current resources which are very limited. In meantime, I definitely understand your decision to cancel the subscription, it is an annoying issue to deal with.

@ragauskl if you need some logs or something else then tell me. The problem is when no one reacts on the tickets here in a week then no one knows that you working on it.

Will do. Yeah - github does tend to fall back in priority. Roman is mostly busy with the update, so I'm helping for now but I'm also busy with my own project and customer support, Crisp comes as priority and has most users to reply to, so Github and Discord remain a last priority if there's time unless someone directly links from Crisp to an issue, as both are 'community' support channels. We had a hired customer support for short time, but that's gone for now/didn't work out long term.

I only had this stuttering since upgrading to macOS Sequoia. No problems before.

@kersten-lohmeyer Are you on eqMac 1.8.7? If yes try enabling Beta Program and update to 1.8.8 (or wait for it to be released in stable, should be any day now I think)

@kersten-lohmeyer Are you on eqMac 1.8.7? If yes try enabling Beta Program and update to 1.8.8 (or wait for it to be released in stable, should be any day now I think)

Yes I am. I wait for stable, because it doesn't happen too often. Thanks!

@kersten-lohmeyer i have installed the 1.8.8 it has the same problem for me. So actually the app is not really working. Something is broken in the App that causes a high load and hanging of the app.

Some changes to driver are pending to be released with 1.8.9 (first in beta), there's some hope it may help with similar issues as it's partial rewrite/change of how it works. I can't promise anything tho as we can't replicate the issue in first place making it harder to fix it

Some changes to driver are pending to be released with 1.8.9 (first in beta), there's some hope it may help with similar issues as it's partial rewrite/change of how it works. I can't promise anything tho as we can't replicate the issue in first place making it harder to fix it

What changed so much in Sequoia that a rewrite is needed?

It's not a full on rewrite, more of restructuring/moving things around. Previous version could have also benefited from this but only with Sequoia the issue became too consistent/obvious

Btw, with youtube and audio stuttering/dropping out - I also noticed this  just now when using BT headphones with Windows and watching youtube stream (already preloaded so not internet problem). I tried switching to different BT headphones and random stuttering was still happening, only when I used built in speakers the stuttering is gone.
Maybe on mac there's something to do with eqMac at least for some but I think there could be something else as well, as I definetly don't have eqMac on Windows, no EQ or other audio app either. Just browser and youtube open.

I have the stuttering with a USB-C audio interface (Motu M4). No BT-Headphones.

@ragauskl thats a BT problem. I have eqMac running with the normal Audio Jack and it's working. When i now enable BT it's stuttering and broken. When i disable eqMac and use BT it's working.

@rehoehle fair enough, just wanted to ask to disable eqMac and see if it still stutters but you checked that.
In my case I think it's still something to do with youtube/browser because I use the BT daily for music from other platforms and never noticed an issue, so it's not only BT problem. On other device however which I use more often for youtube - that's not an issue, a Windows device as well.

@ragauskl now i have checked with my new Airpods Pro 2. But same problem. So it seems that the app run into an issue and hang. When do you plan to bring the update?

@rehoehle I can't tell you for sure unfortunately. nodeful is currently working on the driver changes which hopefully should resolve this, but currently he's dealing with a major issue of macOS not behaving in the way it's promising in official documentation causing tiny, but very noticeable in audio, timing issues. He already tried many ways to fix this with no luck and is frustrated by the issue just as much if not more as users dealing with existing issues. He'll figure it out but as he's the sole person behind eqMac and only one working on this it can take some time and I can't say how much. I only help with customer support when I can so he can focus on the development

Looks like nodeful resolved the mentioned issue, there's are some more issues he wants to resolve before an update in beta channel is released. This does not guarantee fix for the issue as again we couldn't replicate it under same circumstances like other users, but we certainly hope this will help.

@ragauskl Thanks i can then check it when the version is available and tell you if it's working. If he needs more informations he can contact me.

@ragauskl and @nodeful i think something changed with the new MacOS 18.0.1 update. The change to BT seems to work now. So it takes a short time to change but the App is not going to get a load of 2000. If think with your new update this could be fixing the general problem.

@ragauskl ok interesting it's working after an restart but only until the standby on the next day it's not working and same problem.

Interesting problem this problem exists only after Standby. After restart to the next Standby it's working well.

Could be that because after restart the driver starts from fresh state, after standby however only the UI can be reloaded and reloading driver is not as seamless so it's not done automatically to reset the state. After standby the driver is doing additional stuff to reset state where possible without reload, during which time slightest mistakes like race conditions start to become much more apparent - this is also very device environment dependant, and on some devices may not occur at all or very rarely making it harder to debug.

I switched to beta and it was working fine for a very long time but now it happened again. I had a Youtube video open in Chrome and I switched from my Motu M4 audio interface to MacBook Pro speakers and the video stuttered. But now, after writing this post, I switched back to Chrome, resumed playback and everything was fine again.

I am also experiencing the stuttering audio issue on a USB audio interface (Focusrite Scarlett 4i4).  I encounter this on app v1.8.8 w/ driver v2.5.4 on Sequoia (15.0.1).  For what it's worth, I have not yet seen the issue with the same setup on a Sonoma (14.7) machine.

from my observation, the stuttering is easier to be reproduced by having some google chrome playing some youtube video in the background (listening to music), pausing it and then instantly lock the laptop, and wait for the laptop to go to sleep on its own.(i believe that causes the issues but i might be wrong)
the only viable solution so far for me without rebooting the laptop is

go to activity monitor, under CPU processes, look for coreaudio
then force quit coreaudiod
click on eqmac and on the bottom of the selected audio interface would be empty.
click on the "refresh" button on the bottom left, then your previously selected interface should appear automatically
your audio should be working again without stutter.

@ragauskl when do you think is here a new version available?

@devtcp That likely helps because it restarts the driver, you can also try the steps bellow (or just the commands) if it's easier/faster to do

Stop all audio playback
Quit eqmac
Run in terminal

For soft reset: "sudo launchctl kickstart -k system/com.apple.audio.coreaudiod"
Or for hard reset: "sudo killall coreaudiod"

@rehoehle The core work has been complete, dev is polishing off about 4 small bugs right now. While they are not as major as audio stuttering dev does not want to release update until everything is working at least for him. We had a more in-depth conversation regarding this and one of current problems why he doesn't want to release a beta right now until everything is polished out (which constantly keeps increasing the time needed, as he fixes one thing but then finds another issue - the main reason for this is also the fact the there has been a major change in driver which has made a list of previous issues that were occurring to few users much more obvious/consistent) is that there is already large amount of people in beta so he's afraid that while it will fix issue like stuttering it may break something for many other users. So the 'beta' is now more of 'release candidate', I suggested making a build for at least one person to try and confirm if this issue specifically has been resolved, but he disagreed, however we discussed that beta/stable release should be changed to allow users to also opt in to 'alpha' release and alpha may be closed/invite only. That would allow to release the update as is to check if changes fixed any one specific issue even if other things are still broken.
So alpha will be added after the update, but for now the update itself remains a priority to complete. As for when it will be completed, due to everything explained above I can't provide time estimate still, last 4 weeks it has been 'any week now' and a new issue pops up, these are also a lot of times issues that don't have a definitive answer or obvious solution and require a lot of debugging and sorting through a lot of information the app is outputting and can take less than a day or multiple days per each issue.
I wish I could provide a better estimate, but unfortunately that is not possible at the moment, I can only say that dev is working every day to resolve this as soon as possible.

@ragauskl i hope i can test it. At the moment it's unusable. So everything is better then this.

I understand, I tried to communicate this to the dev but last word is his

Experiencing the same issue on Sequoia 15.0.1 on every output device
eqMac Version: 1.8.8, Driver 2.5.4
Sometimes it fixes itself after I switch the output device while audio is playing and eqmac is on, other times it fixes itself after turning eqmac off and on again, another time after quitting eqmac and reopening the application, another time after using "Restart eqMac", and 2 times I had to log out and log back into macos to fix it. Sorry if this isn't very specific, but I can't seem to reproduce an exact way to make it work, it's all trial and error.
sudo killall coreaudiod seems to work consistently.

1.8.9 now available in beta, please do keep in mind that it's beta and it includes major underlaying changes to the driver, developer fixed any issues he could replicate (note that this issue could not be replicate under same circumstances, therefore it's 50/50 if the update will help you or not), but that does not mean that new issues will not occur to others or that all issues are definitely fixed. Any feedback is valuable so that we can know if it's working as expected to everyone and what issues are still present.

@ragauskl at the moment it seems good. Until now it's working and now problems.

@rehoehle Nice, fingers crossed it will stay that way

@rehoehle 1.8.10 is out now - see if that helps at all

@ragauskl thank i have installed it now and will check it now :)

Came here with same problem, bt headphones stuttering.
Reinstalling app/driver helped.
app 1.8.8
driver 2.5.4

@boriselec try 1.8.10 by enabling 'beta program' in settings and checking for updates

I've got the same stuttering issues, except in my case they appear every single time I change the output device, be it bluetooth, built-in speakers, audio jack, whatever - Any change does it. It's worth noting that I have automatic profile switching enabled, so each time I switch the output device a different equalizer profile is loaded. This has been happening for about the last half a year...

@4S1ght  what eqMac version are you using?

That's because it was only fixed in 1.8.10, we were not able to replicate (therefore fix) the problem before, what changed is that we bought a DAC with 3+ channels and could replicate the issue finally

I have the AirPods Max (not sure about the model number, but it's USB-C already) and it works flawlessly so far. I'm on App version 1.8.8 and driver 2.5.4 and no stuttering so far. I was a bit worried about it draining the battery more, but it seems to not be the case (at least for now).

Closing as complete as multiple users including creator of the issue have confirmed that it's working in 1.8.11. If issue reoccurs feel free to open new issue or reopen this one


"Auto-copy current subtitle" not working for all sites

Hello! I love asbplayer since it allows me to use Vocabsieve to very quickly and easily look up words, especially with the "auto-copy current subtitles" feature. But, it only seems to work on YouTube, but not on the other streaming site.
On YouTube, for auto-copy to work, I need to have the YouTube tab or the asbplayer tab active and "on top." While I wish it could auto-copy regardless of what was on top, this might not be possible.
But, the other streaming site I use, it only works if I have the asbplayer tab selected. Which kind of defeats the purpose of auto copy since I'd need to have a different tab highlighted and swapping between windows becomes difficult. I'm not sure if this is an actual bug or intended behavior, but it's something I noticed.

This will happen for video players inside of iframes that don't have permissions to write to the clipboard e.g. CrunchyRoll and zoro.to, which would explain why YouTube works. I would expect Netflix to work as well, but haven't tested it. Looking into a fix.

I have a fix for this. It will be released in a new version (probably in a couple weeks). But let me know if you'd like a dev build of the latest code to have the fix early.
b5dd9573035c11114b538789d91a743734d9dde2

That's awesome news! I'm happy to wait since I'm mostly mining from YouTube anyway. Thanks again for this awesome tool!


Clarification on how to observe Event value

Since https://github.com/mostjs/core/pull/8 I can see methods like observe, reduce, etc. have been removed from core.
I've been reading and trying out some new examples to see how to replace some of the patterns I'd use with those deprecated methods.
I'm not familiar with hyperHTML, but for what I gather a scan transformation is used to trigger side effects in the DOM with hyperHTML's bind function. The same transformation keeps the stream bound to event listeners in the node (a nice one-way cycle!), but it feels odd that the value can only come out as a side effect within a transformation. Is this summary correct?
If so, would it be possible to clarify:

is the intention to trigger side effects within a stream combinator like scan?
how does one get the value out of the stream from either the main or error channel?

Hi @cortopy.  Good questions.  I'll try to provide a bit of context, and then specifically address your questions.  I apologize if you already know some of this, but I like to err on the side of more information.
MostJS event streams are inert until run by calling runEffects.  So, side-effects are only performed when demanded by runEffects.  In the case of hyperhtml, it was convenient just to use scan.  It may be possible with hyperhtml's API to pull that side-effect out of the scan and do it in a tap at the very top level:
const effects = tap(performSideEffects, viewUpdates)
runEffects(effects, scheduler)

or just:
runEffects(tap(performSideEffects, viewUpdates), scheduler)

As you've probably guessed from the example above, runEffects + tap is very much like the original observe.  We've considered having a version of runEffects that accepts a side-effecting function, but there hasn't been much demand for it so far.  I'm certainly still open to the idea.

it feels odd that the value can only come out as a side effect within a transformation

Caveat: this was the first time I had used hyperhtml.  Based on its docs and some examples, it seemed like the idiomatic usage was to call bind inside view functions.  In hindsight, it would be nice to pull the usage of bind (the side-effecting call) out of the scan and do that in a final tap, by replacing the bind in view.ts with wire.  I may try that to see if it works.

is the intention to trigger side effects within a stream combinator like scan?

It was convenient to use a scan for hyperhtml.  runEffects + tap is a more pure/rigorous approach in this particular case.
In my experience, it's not possible or practical in a non-trivial JS app to hoist all side-effects out to "the end of the world" in a final tap.  As usual in JS, good judgement and reasonable tradeoffs are required!  In practice, the fact that side-effects only execute once demanded with runEffects coupled with good judgement about where to place side-effects has worked well in practice.

how does one get the value out of the stream from either the main or error channel?

I think the "value" part of this question is answered by info above.  If not, then it seems I probably misunderstood the question and need a bit more help in understanding it :)
Errors, specifically: the error channel represents stream failure (not application errors), and manifests from runEffects via the returned Promise being rejected.  You can use recoverWith to handle stream failures.  If you haven't already, it's worth reading the Stream Failure vs. Application Errors docs.
I hope that helps!

I just tried the quick and dirty experiment of pulling hyperhtml's dom update side-effect out to the top level.  It worked.  Here's the branch and the diff if you'd like to check it out.

Thanks so much @briancavalier. That's very informative and makes it all very clear. I prefer patterns that make side effects explicit and your example above nails it.
I'd just like to add that in regards to:

We've considered having a version of runEffects that accepts a side-effecting function, but there hasn't been much demand for it so far. I'm certainly still open to the idea.

To me runEffects didn't make a lot of sense (probably a matter of semantics), as I could not see what the effects were. After all, even though I can't imagine a use case for it, a stream may be initiated and be pure if no tap is used and no side effects run in the stream.
As an idea for newcomers to Most like me, what about a runEffectsWith that also takes the side effects function and makes it more declarative?
AS A SIDE NOTE:
Are you accepting PRs for the docs? I would like to put something about this there. The examples section points to the repo, but some text there would not hurt

Yes, absolutely, PRs to help improve docs are much appreciated.  As @Frikki mentioned, a bit of up front discussion, and/or putting together a small proposal of what you'd like to add can help a lot in heading down a path we all feel is the right one.  To that end, feel free to join us in gitter to discuss in more real time, or open an issue or PR to discuss.

Thanks a lot! I'll open a separate issue to discuss this


Apply flat modifier to all npcs when rolling initiative

There should be an option (configurable in the settings) to apply an untyped bonus on initiative rolls to all NPCs in order to offset the advantage given to PCs by the block initiative system. The bonus should default to +3. There should also be a tooltip explaining the bonus.

A much simpler implementation is to apply an equivalent penalty on PCs.


fix(types): defineCustomElement props inference with array emits

Fixes #11353
defineCustomElement using components with emits: ["array"] currently resolves to // overload 2: object format with no props instead of // overload 5: the returned value of defineComponent, so the resulting prop type is readonly.
This PR is the only successful result out of my many attempts to fix this. Frankly, I still don't understand why this works but the old code doesn't.

/ecosystem-ci run