UI improvement proposal: minimalize message interface

left align message and avatar pic for messages from myself
hidden redundant information in chat interface, i.e. user name
@gnprice
First PL from gsoc 2020 candidate Tina Chen, not so sure about my UI design and coding practice. looking forward to your comments!

Hi, @tinnieteal, welcome! 🙂
Since these are changes to the visual design, could you please post some screenshots here? That'll be helpful for an initial review.

The two things this commit is alleged to do are very different; at the very least they should be separated out into different Git commits. They should probably also be considered as separate UI design changes (perhaps with one contingent on the other).
There are several CI failures which will need to be addressed. These look like linting and typechecking errors; the former can be resolved by running prettier, but the latter will take some work.

There are also a number of nonfunctional spacing changes to the template strings. Are you using a different formatter than we are, by any chance?

As Chris notes, screenshots are a must for UI changes. (Preferably before/after comparisons.)

Hello @chrisbobbe and @ray-kraesig
Thanks for your comments and suggestions!

I have attached the UI change screenshot before and after
Since the two UI changes are interconnected, I wonder if you would still suggest me to separate the commit for each changes. I think the two changes have to make sense when sticking together.
I have fixed the linter test, but this is still test failing

flow test: that Outboxed does not property sender_id, and it seems that I cannot simply fix it by adding this field to flow type definition, since there are other part of the code depending on this original definition. I have not look into that part of code but I wonder if you know a simple fix to this.
mock test: I wonder what  practice I should follow to fix mock test. Should I change each of these test definition to reflect the UI change?

Regards,
Tina

I have attached the UI change screenshot before and after

:+1:
Looking at the changes makes me suspect that this isn't really a change we want, though. It'd be a significant departure from the webapp, and I think also from other team-collaboration software (Slack, Mattermost, etc.), on both mobile and desktop.
It might be best to post these screenshots on chat.zulip.org's #mobile stream for slightly more lively discussion.

Since the two UI changes are interconnected, I wonder if you would still suggest me to separate the commit for each changes.

Almost certainly!

In the first commit, you can reverse the presentation of self-sent messages.
In the second commit, you can remove usernames in one-on-one PMs.

These two things probably wouldn't go in separate pull requests, but you can include a series of related Git commits in a single PR.
If there's still some reason that this can't easily be done... well, I for one would find that very surprising, and worthy of some discussion and explanation here.

flow test: that Outboxed does not property sender_id, and it seems that I cannot simply fix it by adding this field to flow type definition, since there are other part of the code depending on this original definition. I have not look into that part of code but I wonder if you know a simple fix to this.

That's Flow pointing out (what I assume is) a real bug: Outbox objects really don't have sender_ids, so that comparison will always fail. The consequences of this are visible at the bottom of your last screenshot, where the unsent message has your avatar on the left.
You'll want to test message.isOutbox, which Flow understands as a discriminant between the two types, and (presumably) ensure that isMyself is true for it. (Flow should even understand something along the lines of const isMyself = message.isOutbox || message.sender_id === ...)

mock test: I wonder what  practice I should follow to fix mock test. Should I change each of these test definition to reflect the UI change?

Exactly so: if the expected behavior changes, the tests need to as well.


python312Packages.flickrapi: patch tests

Description of changes
Fix build (https://hydra.nixos.org/build/271773098)

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 344402 run on x86_64-linux 1

4 packages built:

python311Packages.flickrapi
python311Packages.flickrapi.dist
python312Packages.flickrapi
python312Packages.flickrapi.dist


Update Spanish translation to fix and unify treatment

It mixed tú and usted treatments. Now it's consistent throughout. The more formal treatment is recommended for software projects as it's universal to all Spanish dialects.

these variables are no longer used, you can delete them:
Download6, CacheOn, CacheOff, CacheSelect, CacheDays, CacheDays2

Done :)


Update variables-defender-for-cloud.tf

Added subplans for KeyVaults and Arm as terraform prompts for changes.
Fixes #1  .
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Changes proposed in this pull request

Add subplan to Arm
Add subplan to KeyVault

@claranet/fr-azure-reviewers

thanks for your contribution!
Do you know which version of the AzureRM provider introduced these new default subplans? is it 3.75.0 or a lower one?
Can you update the minimum version of the provider (in versions.tf) with this new behavior?
(And would be great if you can fix the CI / update README & Changelog files)

Hi there, I'll put the PR into draft for now and get it to meet the checks. I'll let you know if I discover which version this was added too.

@Shr3ps I believe it's after 3.69, but I'm unable to find a specific reference. If you could help me dig it out I'd be more than happy to update the remaining files with the correct fuzzy versions.

https://github.com/hashicorp/terraform-provider-azurerm/pull/22997/files
I think this is the suspect pull request so I think it's 3.75.0 as suggested, 3.74.0 uses a different method.

https://github.com/hashicorp/terraform-provider-azurerm/pull/22997/files
I think this is the suspect pull request so I think it's 3.75.0 as suggested, 3.74.0 uses a different method.

Ok, so let's put 3.75 as minimal version for this change

It should be ready for merge now, apologies for additional commits. I'm more familiar with Azure DevOps over Github!


Failed vm-win-release-x64-try build with crashpad_handler.exe permission denied

https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket/8727463111126319345/+/u/build_dart/stdout
[3319/3363] LINK ./crashpad_handler.exe
FAILED: crashpad_handler.exe crashpad_handler.lib crashpad_handler.exe.pdb
C:/b/s/w/ir/cipd_bin_packages/cpython3/bin/python3.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False ../../buildtools/win-x64/clang/bin/lld-link.exe /nologo /OUT:./crashpad_handler.exe /PDB:./crashpad_handler.exe.pdb @./crashpad_handler.exe.rsp
lld-link: error: failed to write output './crashpad_handler.exe': permission denied

happened again https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket/8727457511316612497/+/u/build_dart/stdout

the earliest so far seems to be from 12/20  https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket/8728004320607827601/+/u/build_dart/stdout


Use generated id (ObjectId or other) for _id field on groups and users

A few pain points this would alleviate:

Changing a user's email does not change the email they are allowed to log in with
Special logic for handling non-ObjectId _id fields in shared object access

Wish-list: strings :sunglasses:


YARN-11086. Add space in debug log of ParentQueue

Description of PR
How was this patch tested?
For code changes:

[ ] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

Minor fix. If u have time, could you help review it? @szilard-nemeth @9uapaw @virajjasani @jojochuang
Thanks

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 51s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
36m  5s

trunk passed

+1 :green_heart:
compile
1m  7s

trunk passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
compile
0m 59s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 46s

trunk passed

+1 :green_heart:
mvnsite
1m  1s

trunk passed

+1 :green_heart:
javadoc
0m 50s

trunk passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
0m 42s

trunk passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 58s

trunk passed

+1 :green_heart:
shadedclient
24m 25s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 53s

the patch passed

+1 :green_heart:
compile
1m  2s

the patch passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javac
1m  2s

the patch passed

+1 :green_heart:
compile
0m 49s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
0m 49s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 39s

the patch passed

+1 :green_heart:
mvnsite
0m 54s

the patch passed

+1 :green_heart:
javadoc
0m 40s

the patch passed with JDK Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04

+1 :green_heart:
javadoc
0m 36s

the patch passed with JDK Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
2m  1s

the patch passed

+1 :green_heart:
shadedclient
24m 27s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
100m 51s

hadoop-yarn-server-resourcemanager in the patch passed.

+1 :green_heart:
asflicense
0m 29s

The patch does not generate ASF License warnings.

201m 15s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4065/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4065

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux 21a518d7fd95 4.15.0-153-generic #160-Ubuntu SMP Thu Jul 29 06:54:29 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / ad1b0723940674c82e542db60101374b4301825c

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.13+8-Ubuntu-0ubuntu1.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_312-8u312-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4065/1/testReport/

Max. process+thread count
936 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4065/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

Thanks for the change @zuston, +1 from my side as well, LGTM.

Do i need to submit extra diff patch into JIRA ticket? Sorry I'm new one in Hadoop Community.
@9uapaw

Thanks @zuston for working on this.
Patch LGTM, committed to trunk.
Thanks @9uapaw for the review.


Update CI to ensure that all Jupyter notebooks can be executed without issue

We should be able to make sure that all Jupyter notebooks can be executed without problems.
This might be a recipe to follow:
https://github.com/ghego/travis_anaconda_jupyter

Added some code in pytest to execute Jupyter Notebooks to see if any fail.
Since some were failing, they are being skipped for now in test_notebooks.py, so we should prioritize fixing these so that we run all notebooks instead of skipping some.


Issue #1048: Take data version from request param if present.

Closes #1048

Ready for next review.


Python: Completed article Creating GUI's in Python 3

In this file I've completed the stub article which is about Creating GUI's in Python 3.

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Mostly LGTM, needs a spellcheck run.

Hello @RandellDawson,
Is it possible to make pull requests on this still if I have valuable content to add? I would like to add a few tutorials, code snippets, and some more information on python GUIs.
Cheers!

@jose-reyes-9 You can create a new PR with changes for the file if you want.


Bugfix: Make QuickMenu icons show again

Apparently we need NoWrap now.
The icons are still a bit misaligned, as are the file explorer icons, but I think it'd be better to try to get baseline alignment right in Revery before adjusting this.

/azp run

/azp run


It isn't auto injecting with megahack v7

Currently the tool doesn't work with megahack v7 and I do not know how to get it to work.

Me too, I cant find anything else about it.

NVD JUST PUT IN EXTENTIONS


SF 4.1 Update

Just did your modifications on TestCase and upgrade the composer requirements.

Pull Request Test Coverage Report for Build 58

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 94.861%

Totals

Change from base Build 49:
0.0%

Covered Lines:
443

Relevant Lines:
467

💛  - Coveralls


Memory card game

Is your feature request related to a problem? Please describe.
A memory card game in which you flip 2 cards (one at your turn) and if they don't match, they are flipped over, else they remain revealed.
Describe the solution you'd like
I'll be creating it using vanilla JS.

Please assign it to me under gssoc

Currently not accepting simple projects here. Add extensions only. Closing this


🐛 [bp-2.6] Restart immediately if the bootstrap kubeconfig changes

Summary
Related issue(s)
Fixes #

/approve

/lgtm

/cherrypick backplane-2.5


Account settings not accessible after going to team settings

I did the following:

Select team from the drop-down on the top left corner.

Now going to "Account Settings" I only see "Team Settings".

Wrong repository


Dataset.sum() returns 0 for nan values

What happened:
Noticed errors while doing stats over sparsely populated xarray.
What you expected to happen:
Expected nan values to remain nan when setting skipna=True.
Also same result for Int type.
Minimal Complete Verifiable Example:
# thx to https://www.theurbanist.com.au/2020/03/how-to-create-an-xarray-dataset-from-scratch/
import numpy as np
import xarray as xr
import pandas as pd

times = pd.date_range(start='2000-01-01',freq='1H',periods=6)
x = np.arange(6)
y = np.arange(6)
ds = xr.Dataset({
    'stuff': xr.DataArray(
                data   = np.zeros((6,6,6), dtype=float),
                dims   = ['time', 'x', 'y'],
                coords = {'time': times,
                'x': x,
                'y':y,
                }
            )
        }
    )

print(ds)
print(ds.stuff.values)
ds_nan = ds.where(ds.stuff.values > 0)

print(ds_nan.stuff.values)
print(ds_nan.sum(dim=["time"], skipna=True).stuff.values)

Environment:
Output of xr.show_versions()
INSTALLED VERSIONS
commit: None
python: 3.9.6 | packaged by conda-forge | (default, Jul 11 2021, 03:35:11)
[Clang 11.1.0 ]
python-bits: 64
OS: Darwin
OS-release: 20.5.0
machine: arm64
processor: arm
byteorder: little
LC_ALL: None
LANG: de_DE.UTF-8
LOCALE: ('de_DE', 'UTF-8')
libhdf5: 1.10.6
libnetcdf: 4.8.0
xarray: 0.19.0
pandas: 1.3.1
numpy: 1.21.1
scipy: 1.7.0
netCDF4: 1.5.7
pydap: None
h5netcdf: 0.11.0
h5py: 3.3.0
Nio: None
zarr: 2.8.3
cftime: 1.5.0
nc_time_axis: None
PseudoNetCDF: None
rasterio: 1.2.6
cfgrib: None
iris: None
bottleneck: None
dask: 2021.07.2
distributed: 2021.07.2
matplotlib: 3.4.2
cartopy: None
seaborn: None
numbagg: None
pint: None
setuptools: 49.6.0.post20210108
pip: 21.2.2
conda: None
pytest: 6.2.4
IPython: None
sphinx: None

Yes this is by design and matches numpy IIRC. See #2889. I think you have to manually mask the output using .count to get what you want.
Please reopen if you have more questions.

What exactly is the skipna parameter doing? From the documentation it sounds like it would solve exactly the above 'problem'. Or is it just setting nan=0 for summing up?


style: let the reader decide if something is simple or easy

We should refrain from using words like "easy!" or "simply" or "just" or "extremely easy" or "to show you how easy it really is", etc. Let the reader assess how hard a particular step is for them and not stress them out that it should have been easy.
This is something which bothered me quite a lot when reading through the academy for the first time, hence I decided that toning the whole academy down in this regard will be one of my first proposed changes.
This PR is rather large and I'm sorry for that. Most of the changes just remove one word from a sentence, as the sentence works completely the same without it. In some cases it was necessary to rewrite the sentence.

Getting huuuuge merge conflict with https://github.com/apify/apify-docs/pull/1067. Will re-create this PR after rebase.


Get-ChildItem -R is unbelievably slow

$f = gci -R -File .
Measure-Command { gci $f }
# VS
Measure-Command { gci -R $f } # 2000 times slower

Why would you use Get-ChildItem -Recurse on an array of files to begin with? Seems pointless to me.

@zett42  It is used in a utility function. So the input can be anything(same as gci).

You measure two commands together. What command is slow? What are you comparing with? Please update repro steps.

@iSazonov I'm comparing with the code in "Expected Behavior".

While the extent of the slowdown should be investigated, your second command should really be:
# -lp == -LiteralPath
gci -R -File -lp $f

Only that guarantees the expected results, given that your verbatim file paths would otherwise be interpreted as wildcard patterns, due to (positionally) binding to -Path rather than -LiteralPath.
As a (beneficial) side effect, the command executes much faster.

It is the use of -Recurse in combination with (implied) -Path that causes the excessive slowdown - even though in the case at hand - only file paths as input - there is no recursion to perform.
By contrast, with -LiteralPath the presence or absence of -Recurse makes virtually no difference.

@mklement0
The code here is only to show the issue.

That's not what I was doing. My comments contained:
(a) an acknowledgement of the problem - the excessive slowdown when combining -Path with -Recurse with an array of file paths.
(b) an explanation of how the problem can be avoided (-LiteralPath), which also happens to be the right thing to do.

@mklement0

your second command should really be
Only that guarantees the expected results,

By looking at the code you figured that -LiteralPath should be used. And that would defeat the whole purpose of the code.

@amfogor, I'm happy to respond to constructive engagement with the arguments that were made.

Please update the issue with
$f = Get-ChildItem -R -File -Path . ; Measure-Command { Get-ChildItem -Recurse -File -Path $f } vs $f = Get-ChildItem -Recurse -File -Path . ; Measure-Command { Get-ChildItem -File -Path $f }
I can even guess why it works so slowly (case normalization). If so, then the PR with the fix has been waiting for a long time.

@iSazonov, to demonstrate that not case normalization, but the specific combination of -Path and -Recurse is the pathological case:
Benchmark code, using only a 10-element array of file paths:
Write-Verbose -vb 'Setting up...'

# Download and define function `Time-Command` on demand (will prompt).
if (-not (Get-Command -ea Ignore Time-Command)) {
  $gistUrl = 'https://gist.github.com/mklement0/9e1f13978620b09ab2d15da5535d1b27/raw/Time-Command.ps1'
  if ((Read-Host "`n====`n  OK to download and define benchmark function ``Time-Command`` from Gist ${gistUrl}?`n=====`n(y/n)?").Trim() -notin 'y', 'yes') { Write-Warning 'Aborted.'; exit 2 }
  Invoke-RestMethod $gistUrl | Invoke-Expression 3>$null
  if (-not ${function:Time-Command}) { exit 2 }
}

# Create an array with all-lowercase file paths ($PROFILE)
$elementCount = 10
$filePathArray = , $PROFILE.ToLowerInvariant() * $elementCount

# Define the script blocks whose execution to time.
$benchmarks = @(
  {
    Get-ChildItem -Path $filePathArray -File
  }

  {
    Get-ChildItem -LiteralPath $filePathArray -File
  }

  {
    Get-ChildItem -Recurse -Path $filePathArray -File
  }

  {
    Get-ChildItem -Recurse -LiteralPath $filePathArray -File
  }
)

Write-Verbose -vb "Running benchmarks with $elementCount files..."

# Get the file once, out of competition, to warm up the cache.
$null = Get-ChildItem -File -LiteralPath $filePathArray[0]

# Run the benchmarks 10 times and report the averaged results.
Time-Command -Count 10 $benchmarks

Results:
On Windows, I get:
VERBOSE: Setting up...
VERBOSE: Running benchmarks with 10 files...

Factor   Secs (10-run avg.) Command                                                  TimeSpan
------   ------------------ -------                                                  --------
1.00     0.004              Get-ChildItem -LiteralPath $filePathArray -File          00:00:00.0043445
1.02     0.004              Get-ChildItem -Path $filePathArray -File                 00:00:00.0044139
1.03     0.004              Get-ChildItem -Recurse -LiteralPath $filePathArray -File 00:00:00.0044683
1,785.74 7.758              Get-ChildItem -Recurse -Path $filePathArray -File        00:00:07.7581985

That is, adding -Recurse to -Path -File caused a roughly 2000-fold slowdown.
On macOS it isn't quite that bad, but still pathological:
Factor Secs (10-run avg.) Command                                                  TimeSpan
------ ------------------ -------                                                  --------
1.00   0.002              Get-ChildItem -Path $filePathArray -File                 00:00:00.0023656
1.01   0.002              Get-ChildItem -Recurse -LiteralPath $filePathArray -File 00:00:00.0023979
1.02   0.002              Get-ChildItem -LiteralPath $filePathArray -File          00:00:00.0024215
22.71  0.054              Get-ChildItem -Recurse -Path $filePathArray -File        00:00:00.0537165

to demonstrate that not case normalization

You could compare results for very small folder tree (one-file-folder-tree) and for a folder tree with many nested objects.
(Case normalization does one pinvoke per subfolder name in folder path, and globbing multiply this up to 6 times!)

The benchmarks above clearly demonstrate a problem that is unrelated to case normalization, and I suggest we stay focused on that specific problem here.
To recap:

There is no justification for -Recurse to slow things down this dramatically when combined with -Path and file paths, given that there is nothing to recurse on.

The problem doesn't occur with -LiteralPath.

Clearly, the specific combination of parameters results in unrelated, unexpected extra activity - and that's what we need to fix.

As for case normalization: It is only ever needed for the recursion entry points, never during enumeration, as previously discussed in https://github.com/PowerShell/PowerShell/issues/13190#issuecomment-663870047. And if there's too much case normalization currently going on, that needs to be addressed separately.

Yes, it is extra globbing.
Proposed fix https://github.com/iSazonov/PowerShell/commit/1c52dc300629e5c79bc18136a2eeeb76b417c329
Feel free If somebody want to pull PR.
(The fix is only cosmetic fix for the specific scenario. To make Globbing fast is very difficult and unobvious work.)
PS; @mklement0 Please look output with Name parameter in second command. Do you see only empty string?

Looking at the title, that PR definitely sounds like a worthwhile optimization, but note that it isn't globbing per se that's the problem here, given that Get-ChildItem -Path $filePathArray -File in the test above performs virtually the same as the non-globbing Get-ChildItem -LiteralPath $filePathArray -File variant (with only a 10 paths).
Again, the addition of -Recurse to -Path is what triggers the problem, so I suspect that it's some kind of unnecessary traversal that is triggered.

look output with Name parameter in second command. Do you see only empty strings?

Among the commands in the benchmark code above, the ones with -Recurse  - both -Path and -LiteralPath - indeed produce empty-string output when -Name is added.

but note that it isn't globbing per se that's the problem here

You can look the very weird code here https://github.com/PowerShell/PowerShell/blob/4d702e010d656681e42164ad02344883836668c9/src/System.Management.Automation/engine/SessionStateContainer.cs#L1320-L1371
As you see PowerShell creates new filter with Include among other things. So it’s not surprising that it works the slowest way.
(Could you please open new issue for the bug with -Name if you have time or such issue already is?)

Well, that code does sound like the implementation of the treacherous behavior discussed in #5699. Of course, when given a full path referring to a file, no recursion should ever be performed, even with (positionally implied) -Path.

Could you please open new issue for the bug with -Name

Please see #15283.

Well, that code does sound like the implementation of the treacherous behavior discussed in #5699.

It seem the code executed only for Path parameter (SuppressWildcardExpansion is false).

I've been saying all along that the problem is the specific combination of -Recurse and -Path.


Add systemd services

I'd be happy to send a patch for this! Could you please give me some pointers?

Absolutely!
The service files should have strict hardening options. A good template to start with is AttestationServer's systemd service. You can most likely add MemoryDenyWriteExecute=true to those options since we're not using Java. Further hardening options can be found with systemd-analyze security.
WorkingDirectory can be set to /var/lib/devportal and /var/lib/reposerver respectively. Neither devportal or reposerver need external network access since they're meant to be placed behind an nginx reverse proxy communicating over localhost.
Let me know if I can help with anything else.

Thanks for the reply :)
I've already contributed a few hardened systemd units to different projects like 1 and 2, so I think I won't have issues with that (hopefully!). My question was more about what the unit should be used for, as I don't fully understand how the devportal service behaves (e.g. the service should be a Type=simple one, right?).
I've been watching Accrescent for a while, and I'd really like to start helping from somewhere. So, sorry for my basic questions!

Oh okay. That's great!
The devportal is a Go web server which runs in the foreground and handles authentication for developers, accepts uploaded apps, and publishes them via the reposerver's REST API. It keeps track of state in ./devportal.db and will create and delete temporary directories with pseudorandom names in / to hold apps which haven't yet been published (of course we don't want them to actually be created in / in production, so that should be changed. I'm not sure why I didn't set that up as a relative path in the first place).
reposerver is also a Go web server that runs in the foreground, and it accepts apps via a REST API from devportal and publishes them in a directory tree located at PUBLISH_DIR (would it be easier to harden the unit if this path was static?). A static web server then serves the files at PUBLISH_DIR to make them available to the client app.
Is any of that helpful?
I appreciate the willingness to contribute by the way! Hopefully this will all be easier to digest once documentation is added.

The devportal is a Go web server which runs in the foreground and handles authentication for developers, accepts uploaded apps, and publishes them via the reposerver's REST API. It keeps track of state in ./devportal.db and will create and delete temporary directories with pseudorandom names in / to hold apps which haven't yet been published (of course we don't want them to actually be created in / in production, so that should be changed. I'm not sure why I didn't set that up as a relative path in the first place).

Using relative paths doesn't generally work well with systemd units, as services are supposed to write to the various standard Unix directories (see file-hierarchy(7)), but if you'd prefer not to make edits to the code it should be enough to set WorkingDirectory= to a subdirectory of /var/local/ or /var/lib/.
As for the temporary files written to /, could you point me to the piece of code that manages them? I can change that to use /tmp/ or $TMPDIR.

reposerver is also a Go web server that runs in the foreground, and it accepts apps via a REST API from devportal and publishes them in a directory tree located at PUBLISH_DIR (would it be easier to harden the unit if this path was static?). A static web server then serves the files at PUBLISH_DIR to make them available to the client app.

Dynamic paths should be fine; we could set the env var in the systemd unit itself, so that it knows which directories should be available to the service. systemd.exec(5) describes pretty well how env vars are handled in systemd units.

Is any of that helpful?

Yep :)

I appreciate the willingness to contribute by the way! Hopefully this will all be easier to digest once documentation is added.

Yeah, documentation would definitely make this easier

Using relative paths doesn't generally work well with systemd units, as services are supposed to write to the various standard Unix directories (see file-hierarchy(7)), but if you'd prefer not to make edits to the code it should be enough to set WorkingDirectory= to a subdirectory of /var/local/ or /var/lib/.

I'd prefer to use a relative path in tandem with WorkingDirectory= unless there's a good reason to do otherwise. Although this software is intended to be run on a typical systemd-based Linux distribution, I think it would be good to avoid platform-specific code as much as possible.

As for the temporary files written to /, could you point me to the piece of code that manages them? I can change that to use /tmp/ or $TMPDIR.

new_app.go and update_app.go (and yes, this duplication and fragmentation of file management is... subpar. I'm currently refactoring the entire developer portal to handle this better among other many other things. It's not exactly at a production stage yet :) ). I'm not sure if /tmp is the best place to put the APK sets though - they may be saved for longer than the host's uptime if submitted to the review process.

Dynamic paths should be fine; we could set the env var in the systemd unit itself, so that it knows which directories should be available to the service. systemd.exec(5) describes pretty well how env vars are handled in systemd units.

Great.

As of https://github.com/accrescent/devportal/commit/1c839fadc55d7a919b86bcd91a071631011fab0c the file storage backend is generic and so can easily point to wherever we like.


labeling in GROMACS conversion

I was trying to use solvation toolkit to make a box with water, cyclohexane, DMSO, and acetonitrile.
Below is the script I used:
solvs = ['cyclohexane', 'water', 'DMSO', 'Acetonitrile']
smile_solv = ['C1CCCCC1', 'O', 'CS(=O)C', 'CC#N']
num_solv = [130, 780, 4, 2]

builder = MixtureSystem(solvs, smile_solv, num_solv, './allSolvents/', None)
builder.run(just_build = True)
builder.convert_to_gromacs()

For some reason in the GROMACS topology file, it labeled the DMSO 'water', the Acetonitrile 'water2', and the water 'water3', but then also had a molecules named 'DMSO' and 'Acetonitrile' which were more waters. I went back to look at the amber files. The prmtop file, while harder to read as a human, I think it looks fine.
So I could get this simulation running, I followed the script in convert_to_gromacs method, but by hand with my labels and used parmed to convert the prmtop and inpcrd files to .top and .gro files and that topology file looks fine. I used the following lines to do this parmed conversion:
import parmed
gromacs_topology = parmed.load_file('tleap/cyclohexane_water_DMSO_Acetonitrile_130_780_4_2.prmtop', 'tleap/cyclohexane_water_DMSO_Acetonitrile_130_780_4_2.inpcrd')

components = gromacs_topology.split()

resnames = ['cyclohexane'] * 130
resnames += ['DMSO']*4
resnames += ['Acetonitrile'] * 2
resnames += ['water'] * 780
for i in range(len(resnames)):
     gromacs_topology.residues[i].name = resnames[i]

gromacs_topology.save('mol.top', format = 'gromacs')
gromacs_topology.save('mol.gro')

I have all of the files here
Where the fromSolvationToolkit* are the ones created from the first script using a MixtureSystem
and the fromParmEd* are the two out put by my code above
I think part of the problem is that the prmtop files put the water at the end even though that wasn't the order they were input into the MixtureSystem, so the convert_to_gromacs tried to assign the label 'water' to the DMSO and Acetonitrile molecules since they showed up before the water and then assigned DMSO and Acetonitrile to the last few waters.

@davidlmobley

Thanks. I'll look at this, though it may take me a couple of days. I
probably made an assumption that molecules weren't being re-ordered by
tleap, which sounds like it's not true.
Thanks.
On Fri, Apr 1, 2016 at 1:48 PM, Caitlin Bannan<EMAIL_ADDRESS>wrote:

I was trying to use solvation toolkit to make a box with water,
cyclohexane, DMSO, and acetonitrile.
Below is the script I used:
solvs = ['cyclohexane', 'water', 'DMSO', 'Acetonitrile']
smile_solv = ['C1CCCCC1', 'O', 'CS(=O)C', 'CC#N']
num_solv = [130, 780, 4, 2]
builder = MixtureSystem(solvs, smile_solv, num_solv, './allSolvents/', None)
builder.run(just_build = True)
builder.convert_to_gromacs()
For some reason in the GROMACS topology file, it labeled the DMSO 'water',
the Acetonitrile 'water2', and the water 'water3', but then also had a
molecules named 'DMSO' and 'Acetonitrile' which were more waters. I went
back to look at the amber files. The prmtop file, while harder to read as a
human, I think it looks fine.
So I could get this simulation running, I followed the script in
convert_to_gromacs method, but by hand with my labels and used parmed to
convert the prmtop and inpcrd files to .top and .gro files and that
topology file looks fine. I used the following lines to do this parmed
conversion:
import parmed
gromacs_topology = parmed.load_file('tleap/cyclohexane_water_DMSO_Acetonitrile_130_780_4_2.prmtop', 'tleap/cyclohexane_water_DMSO_Acetonitrile_130_780_4_2.inpcrd')
components = gromacs_topology.split()
resnames = ['cyclohexane'] * 130
resnames += ['DMSO']*4
resnames += ['Acetonitrile'] * 2
resnames += ['water'] * 780
for i in range(len(resnames)):
gromacs_topology.residues[i].name = resnames[i]
gromacs_topology.save('mol.top', format = 'gromacs')
gromacs_topology.save('mol.gro')
I have all of the files here
https://www.dropbox.com/sh/4fkim2s558c2dz0/AADUb8aCX73Tz5vjjpP8nxhZa?dl=0
Where the fromSolvationToolkit* are the ones created from the first script
using a MixtureSystem
and the fromParmEd* are the two out put by my code above
I think part of the problem is that the prmtop files put the water at the
end even though that wasn't the order they were input into the
MixtureSystem, so the convert_to_gromacs tried to assign the label 'water'
to the DMSO and Acetonitrile molecules since they showed up before the
water and then assigned DMSO and Acetonitrile to the last few waters.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/MobleyLab/SolvationToolkit/issues/36

--
David Mobley
Associate Professor
Department of Pharmaceutical Sciences
Department of Chemistry
3134B Natural Sciences I
University of California, Irvine
Irvine, CA 92697
<EMAIL_ADDRESS>work<PHONE_NUMBER>
cell<PHONE_NUMBER>

I've verified that after ParmEd read of the AMBER files, the water appears at the end of the list of components. And I've verified that this happens due to tleap, which apparently recognizes water and moves it to the end (special treatment of water strikes again). The next step is for me to figure out a robust way to catch this and then handle components separately. I'm working on it.

OK, I think I know how to fix this now. tleap apparently reorders any residue with residue name WAT to move to the end of the file, which includes all water models it recognizes as such (i.e. TIP3P and SPC, etc.). So the converter can look for this residue name and recognize a re-ordering has taken place. Potentially this might also have to deal with flexible GAFF water or other water NOT receiving special treatment by tleap; i.e. if someone invoked openmoltools.amber.build_mixture_prmtop and asked for the water not to receive special treatment. But in that case, it will come through with some other residue name (i.e. "water", unless it is "WAT" in which case tleap will re-order it). So I think we should be able to recognize this way.
Next I'll try and fix it.

Resolved via #47 .


feat(tutorials): new migrations

@mnmkng Changed all the tutorial titles to contain "How to" for SEO


chore(ci): update periodic Scanner bump PR title

Description
We now need to adhere to a particular title format
Checklist

[x] Investigated and inspected CI test results
~[ ] Unit test and regression tests added~
~[ ] Evaluated and added CHANGELOG entry if required~
~[ ] Determined and documented upgrade steps~
~[ ] Documented user facing changes (create PR based on [openshift/openshift-docs]~(https://github.com/openshift/openshift-docs) and merge into rhacs-docs)~

Testing Performed
No

@RTann Thanks!


Problem with Specials

Hi I am currently using it for "Español Latinoamérica" under the folder "el", looks like the specials list is missing 3 items compared to other languages like English as an example.
Thanks in advance!

It's same as Pokémon TV official site


⚠ Bofrost.at has degraded performance

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

HTTP code: 200
Response time: 2672 ms

Resolved: Bofrost.at performance has improved in 281b86c after 6 minutes.


Flattening KubevirtMachineTemplate.spec and adding metadata for VirtualMachine

Hi team,
Thank you for all the work on this new provider. This is great to see it land.
Following on #11, the spec of the KubevirtMachineTemplate to specify KubeVirt resources seems quite deep and, with the understand that this would be a backward incompatible changes, I would like to propose a flatter structure.
Currently, the structure is as follow:
KubevirtMachineTemplate
├── ...
└── spec
    └── template
        └── spec
            ├── bootstrapped
            ├── providerID
            └── vmSpec  (= VirtualMachineInstance.spec)
                ├── accessCredentials
                ├── affinity
                └── ...

Assuming #11 is implemented and the VirtualMachine.spec is used instead of the VirtualMachineInstance.spec, can we update the structure to something like the following:
KubevirtMachineTemplate
├── ...
└── spec
    ├── bootstrapped
    ├── providerID
    └── template
        ├── metadata
        └── spec  (= VirtualMachine.spec)
            ├── dataVolumeTemplates
            ├── runStrategy
            ├── running
            └── template
                ├── metadata
                └── spec

Here are my thoughts on which I based this proposal:

Because the KubevirtMachineTemplate name already describes clearly that this is a template, the first spec.template path might be redundant, even more as there are no other fields specified at these levels.
bootstrapped and providerID are, as far as I understand, properties of the machine resource, so having them directly under the spec of the KubevirtMachineTemplate seems appropriate.
The machine is provided by a KubeVirt's VirtualMachine so we need its template, which feels appropriate as a spec.template field.
As one might want to specify labels and annotations for the VirtualMachine, spec.template should have a metadata field.
The virtualMachine spec can then be under spec.template.spec

Any thoughts, opinions or concerns on adapting this structure in such a way?

As for flatting the KubevirtMachineTemplate, I'm unsure. By moving providerID out of the current structure, we are abandoning a consistent API convention the other capi providers use.
For example, here's providerId across AWS and AZURe providers
awsTemplate.Spec.Template.Spec.ProviderId
azureTemplate.Spec.Template.Spec.ProviderId
Today the capk provider follows this convention with...
kvMachineTemplate.Spec.Template.Spec.ProviderId
I'm unsure what ramifications we'd encounter later on if we flatten this to  kvMachineTemplate.Spec.ProviderId. Maybe it's fine, or maybe it becomes a pain point because we do something slightly different than everyone else.
While this doesn't offer any flattening of the structure, I believe what I have below allows everything to be expressed accurately.
KubevirtMachineTemplate
├── ...
└── spec
    └── template
        ├── metadata (metadata used for KubevirtMachine)
        └── spec
            ├── bootstrapped (depreciated - this just got removed already)
            ├── providerID
            └── virtualMachineTemplate
                ├── metadata (metadata used when creating the KubeVirt VM)
                └── spec  (= VirtualMachine.spec)
                    ├── dataVolumeTemplates
                    └── template
                        ├── metadata (metadata assigned to the running VMI instance)
                        └── spec  (= VirtualMachineInstance.spec)

Thanks @davidvossel, make sense to keep this schema aligned with other provider and, as you added to your schema, this allow the addition of the metadata for the KubevirtMachine; which I didn't realize was also missing.
Renaming this issue from Flattening KubevirtMachineTemplate.spec and adding metadata for VirtualMachine to Add KubevirtMachine and VirtualMachine metadata to KubevirtMachineTemplate spec for clarity.

Thanks @davidvossel, make sense to keep this schema aligned with other provider and, as you added to your schema, this allow the addition of the metadata for the KubevirtMachine; which I didn't realize was also missing.

excellent!
I'm disappointed with how deeply nested the yaml is with what I proposed, but I think this might just be the nature of what we're building. @rmohr it would be good to have your eyes on this as well.

is anyone actively working on this one? I don't mind picking this up if no one else is

Hi @davidvossel, as far as I know, this issue is not being actively work on and it would be great if you could work on it. Thank you!

/assign @davidvossel


docs: Merge auth glossary with main glossary

Hey, I just made a Pull Request!
Fixes #4432 by adding a hyperlink to auth glossary in the main glossary.

:heavy_check_mark: Checklist

[x] Screenshots attached (for UI changes)

Tugboat has finished building the preview for this pull request!
Link:

https://pr4508-cozgqucgifzghyw98rzh4hd1iygthlow.tugboat.qa

Dashboard:

https://dashboard.tugboat.qa/60264e41fcb22dc68853f973


Run compile before publish

This PR fixes the issue where the currently published npm package is empty due the dist folder not being compiled.

Tests are failing because sync-message-port was also not published correctly: https://github.com/sass/sync-message-port/pull/9


Typo for text_encodings?

Hi, me again (lol)
Just curious why set inited text_encodings's length as 0
https://github.com/lucidrains/DALLE2-pytorch/blob/8b054686530c90ecd8e8db62eb9c648d189accf9/dalle2_pytorch/dalle2_pytorch.py#L747-L748
I tried the test code in the Readme, but throw an error

concated token's shape: (b 4 d), :[text_encoding(b,0,d), text_embed(b,1,d), time_embed(b,1,d), image_embed(b,1,d), learned_queries(b,1,d)]
mask's shape: (b 5)).

diffusion_prior = DiffusionPrior(
    net = prior_network,
    clip = clip,
    timesteps = 100,
    cond_drop_prob = 0.2,
    condition_on_text_encodings = False  # this probably should be true, but just to get Laion started
).cuda()

But, when I write as text_encodings = torch.empty((batch, 1, dim), device = device, dtype = dtype) , error gone.
Plz have a check. Enjoy!

@CiaoHe hey again :)
it seems to all work for me, could you paste the whole script you are running? (i think the text encoding conditioning should be present)

oh, I just copy this part:
import torch
from dalle2_pytorch import DiffusionPriorNetwork, DiffusionPrior, CLIP

# get trained CLIP from step one

clip = CLIP(
    dim_text = 512,
    dim_image = 512,
    dim_latent = 512,
    num_text_tokens = 49408,
    text_enc_depth = 6,
    text_seq_len = 256,
    text_heads = 8,
    visual_enc_depth = 6,
    visual_image_size = 256,
    visual_patch_size = 32,
    visual_heads = 8,
).cuda()

# setup prior network, which contains an autoregressive transformer

prior_network = DiffusionPriorNetwork(
    dim = 512,
    depth = 6,
    dim_head = 64,
    heads = 8
).cuda()

# diffusion prior network, which contains the CLIP and network (with transformer) above

diffusion_prior = DiffusionPrior(
    net = prior_network,
    clip = clip,
    timesteps = 100,
    cond_drop_prob = 0.2,
    condition_on_text_encodings = False  # this probably should be true, but just to get Laion started
).cuda()

# mock data

text = torch.randint(0, 49408, (4, 256)).cuda()
images = torch.randn(4, 3, 256, 256).cuda()

# precompute the text and image embeddings
# here using the diffusion prior class, but could be done with CLIP alone

clip_image_embeds = diffusion_prior.clip.embed_image(images).image_embed
clip_text_embeds = diffusion_prior.clip.embed_text(text).text_embed

# feed text and images into diffusion prior network

loss = diffusion_prior(
    text_embed = clip_text_embeds,
    image_embed = clip_image_embeds
)

loss.backward()

# do the above for many many many steps
# now the diffusion prior can generate image embeddings from the text embeddings

@CiaoHe oh weird, it runs without error for me

@CiaoHe are you up to the latest version? git stash && git pull

@CiaoHe are you up to the latest version? git stash && git pull

Aha, I just read each line of your code and type it down (so let me check your latest version first

@CiaoHe wow, you retyped all ~2k lines of code?

@CiaoHe wow, you retyped all ~2k lines of code? 🤯

Sounds really funny haha. But I think it better to check than just fork the whole down

Yeah, weird, the latest version is cool. My wrong haha (let me check it)


Added topic modelling

Added topic modelling

@prateek-1803 mention the issue

@UppuluriKalyani I have added the issue but the project is for college reviews instead of news headlines


Training on custom model

Error when training on a custom model with huggingface. If you train on the standard 1.5 without choosing a custom model, then the training goes well.
Training the UNet...
0% 0/2100 [00:00<?, ?it/s] elinckus  elinckus Traceback (most recent call last):
File "/content/diffusers/examples/dreambooth/train_dreambooth.py", line 852, in
main()
File "/content/diffusers/examples/dreambooth/train_dreambooth.py", line 726, in main
accelerator.clip_grad_norm_(params_to_clip, args.max_grad_norm)
File "/usr/local/lib/python3.8/dist-packages/accelerate/accelerator.py", line 920, in clip_grad_norm_
self.unscale_gradients()
File "/usr/local/lib/python3.8/dist-packages/accelerate/accelerator.py", line 904, in unscale_gradients
self.scaler.unscale_(opt)
File "/usr/local/lib/python3.8/dist-packages/torch/cuda/amp/grad_scaler.py", line 282, in unscale_
optimizer_state["found_inf_per_device"] = self.unscale_grads(optimizer, inv_scale, found_inf, False)
File "/usr/local/lib/python3.8/dist-packages/torch/cuda/amp/grad_scaler.py", line 210, in unscale_grads
raise ValueError("Attempting to unscale FP16 gradients.")
ValueError: Attempting to unscale FP16 gradients.
0% 0/2100 [00:02<?, ?it/s]
Traceback (most recent call last):
File "/usr/local/bin/accelerate", line 8, in
sys.exit(main())
File "/usr/local/lib/python3.8/dist-packages/accelerate/commands/accelerate_cli.py", line 43, in main
args.func(args)
File "/usr/local/lib/python3.8/dist-packages/accelerate/commands/launch.py", line 837, in launch_command
simple_launcher(args)
File "/usr/local/lib/python3.8/dist-packages/accelerate/commands/launch.py", line 354, in simple_launcher
raise subprocess.CalledProcessError(returncode=process.returncode, cmd=cmd)
subprocess.CalledProcessError: Command '['/usr/bin/python3', '/content/diffusers/examples/dreambooth/train_dreambooth.py', '--stop_text_encoder_training=350', '--image_captions_filename', '--train_only_unet', '--save_starting_step=500', '--save_n_steps=0', '--Session_dir=/content/gdrive/MyDrive/Fast-Dreambooth/Sessions/Elinckus-dreamlike-2100', '--pretrained_model_name_or_path=/content/stable-diffusion-custom', '--instance_data_dir=/content/gdrive/MyDrive/Fast-Dreambooth/Sessions/Elinckus-dreamlike-2100/instance_images', '--output_dir=/content/models/Elinckus-dreamlike-2100', '--captions_dir=/content/gdrive/MyDrive/Fast-Dreambooth/Sessions/Elinckus-dreamlike-2100/captions', '--instance_prompt=', '--seed=186068', '--resolution=512', '--mixed_precision=fp16', '--train_batch_size=1', '--gradient_accumulation_steps=1', '--gradient_checkpointing', '--use_8bit_adam', '--learning_rate=5e-06', '--lr_scheduler=polynomial', '--lr_warmup_steps=0', '--max_train_steps=2100']' returned non-zero exit status 1.
Something went wrong

The dreamlike diffusers model is in FP16, for that specific model, use the CKPT link instead of the huggingface link
https://huggingface.co/dreamlike-art/dreamlike-photoreal-2.0/blob/main/dreamlike-photoreal-2.0.ckpt

The dreamlike diffusers model is in FP16, for that specific model, use the CKPT link instead of the huggingface link https://huggingface.co/dreamlike-art/dreamlike-photoreal-2.0/blob/main/dreamlike-photoreal-2.0.ckpt

I tried this way, I get an error

this is the link : https://huggingface.co/dreamlike-art/dreamlike-photoreal-2.0/resolve/main/dreamlike-photoreal-2.0.ckpt

thx, it works!
Ur the Best)


upd(nala-deb): 0.7.2-0volian1 -> 0.8.0

CI fails

Hmm. Looks like it passed Debian Testing. Ubuntu 20.04, 21.04 and Debian Stable will fail with this build no matter what. The Ubuntu devel and such looks like it's failing to install pacstall.


How can we reduce the Single Point of Failure in a weave cluster ?

In our weave deployments, we see that when we bring down one of the weave nodes, the rest of the nodes go into re-discovery mode and were going to sleeve mode ( and never going back to fastdp mode) and high cpu in the older weave version.
But in the latest 2.8.1 version "falling to sleeve and staying in sleeve" is reduced very much and weave goes back to fastdp mode quickly.
But still we see rediscovery messages in rest of the weave nodes.
How can we reduce the Single Point of Failure in a weave cluster ?
Currently we are not explicitly specifying the connlimit and hence I believe it will be set to 100 by default.
Assuming we have 25 weave nodes in our current setup , Will increasing the connlimit to more than 100 will help ?

Changes in topology (like a node coming down) have to be communicated to all peers in the cluster. This can take some time. The process is described here.
As that article says here, a fully connected mesh of N peers should take N^2 connections. For 25 nodes, increasing the connection limit should help.
Could you post some logs, to help understand the problem better?

hi attaching logs
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.380666 ->[<IP_ADDRESS>:54183|c6:2f:d0:e1:0e:1c(drc02)]: connection shutting down due to error: read tcp <IP_ADDRESS>:6783-><IP_ADDRESS>:54183: read: connection timed out
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.380763 ->[<IP_ADDRESS>:54183|c6:2f:d0:e1:0e:1c(drc02)]: connection deleted
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.380996 ->[<IP_ADDRESS>:6783] attempting connection
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.388082 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.392320 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.394436 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.402847 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.406750 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.412904 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.413114 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.413584 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.413644 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.413737 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.418345 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.418465 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.419718 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.419781 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.420632 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.421645 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.422677 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.425769 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:51.425938 Unable to find connection to relay peer c6:2f:d0:e1:0e:1c
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:51.925177 Vetoed installation of hairpin flow FlowSpec{keys: [InPortFlowKey{vport: 2} TunnelFlowKey{id:<PHONE_NUMBER>fbe292, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>}], actions: [SetTunnelAction{id:<PHONE_NUMBER>fbe292, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:51 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:51.926238 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>fbe292, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>fbe292, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:52 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:52.001231 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>fbe292, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>fbe292, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:52 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:52.052348 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>fbe292, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>fbe292, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:52 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:52.265163 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>fbe173, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>fbe173, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:52 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:52.304670 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>fbe1dd, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>fbe1dd, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:53 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:53.392106 Received own packet to peer c6:2f:d0:e1:0e:1c(drc02) from MAC (52:da:a3:d3:80:ea) to (26:69:0a:04:51:1e)
Jul 12 05:51:53 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:53.397312 Received own packet to peer c6:2f:d0:e1:0e:1c(drc02) from MAC (ae:11:e2:68:07:3c) to (e2:e3:90:4f:e2:0c)
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.728659 ->[<IP_ADDRESS>:6783|4a:4d:82:27:1a:19(drd06)]: connection shutting down due to error: read tcp <IP_ADDRESS>:46397-><IP_ADDRESS>:6783: read: connection timed out
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.728818 ->[<IP_ADDRESS>:6783|4a:4d:82:27:1a:19(drd06)]: connection deleted
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.729404 ->[<IP_ADDRESS>:6783] attempting connection
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.730923 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.743521 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.744391 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.748694 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.762459 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.762626 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.762691 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.770928 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.771438 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.771888 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.772303 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.772569 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.772780 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.773136 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.789760 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.801208 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.801413 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.802917 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.815967 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.820119 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.823763 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:55 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:55.824092 Unable to find connection to relay peer 4a:4d:82:27:1a:19
Jul 12 05:51:56 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:56.577767 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>fbe47c, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>fbe47c, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:56 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:56.597436 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>4f447c, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>4f447c, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:56 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:56.765662 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>fbe47c, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>fbe47c, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:56 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:56.859984 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>4f439d, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>4f439d, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:56 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:56.920665 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>fbebb1, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>fbebb1, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:56 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:56.921096 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>4f4173, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>4f4173, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:56 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:56.921420 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>fbe229, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>fbe229, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:56 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:56.921628 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>4f439d, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>4f439d, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:56 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:56.939962 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>4f4bd1, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>4f4bd1, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:56 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:56.940048 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>fbebb1, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>fbebb1, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:56 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:56.989095 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>4f439d, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>4f439d, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:56 drd03 98f12d3f9bd9[21292]: WARN: 2024/07/12 05:51:56.989492 Vetoed installation of hairpin flow FlowSpec{keys: [TunnelFlowKey{id:<PHONE_NUMBER>4f4bb1, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>} InPortFlowKey{vport: 2}], actions: [SetTunnelAction{id:<PHONE_NUMBER>4f4bb1, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, tos: 0, ttl: 64, df: true, csum: false} OutputAction{vport: 2}]}
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:57.050112 Discovered remote MAC 8a:1c:77:29:be:42 at 0a:7a:a8:17:ac:4c(artlva1drm01v)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:57.613057 Received packet for unknown destination: c6:2f:d0:e1:0e:1c(drc02)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:57.614050 Received packet for unknown destination: c6:2f:d0:e1:0e:1c(drc02)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:57.614324 Received packet for unknown destination: 4a:4d:82:27:1a:19(drd06)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:57.619962 Received packet for unknown destination: c6:2f:d0:e1:0e:1c(drc02)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:57.641702 Received packet for unknown destination: c6:2f:d0:e1:0e:1c(drc02)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:57.659426 Received packet for unknown destination: 4a:4d:82:27:1a:19(drd06)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.667120 Captured frame from MAC (0a:00:97:c4:5a:99) to (46:4f:8f:00:32:c9) associated with another peer ba:60:6d:17:86:cc(drd07)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.696427 Captured frame from MAC (12:cc:22:5e:74:56) to (72:6e:1d:43:85:d7) associated with another peer a2:08:24:39:97:51(drw06)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.696525 Captured frame from MAC (8e:64:30:b3:b5:da) to (1a:9a:c7:05:3f:73) associated with another peer a2:08:24:39:97:51(drw06)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.696580 Captured frame from MAC (2e:f1:ba:01:0b:0c) to (46:4f:8f:00:32:c9) associated with another peer a2:08:24:39:97:51(drw06)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:57.704779 Received packet for unknown destination: c6:2f:d0:e1:0e:1c(drc02)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.729013 Captured frame from MAC (4a:7a:bb:95:96:31) to (ae:42:3d:6c:eb:6b) associated with another peer 36:23:d0:53:85:5e(drw01v)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.731317 Captured frame from MAC (f6:db:39:c1:ae:9b) to (86:94:d9:aa:0f:58) associated with another peer a2:08:24:39:97:51(drw06)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.735991 Captured frame from MAC (96:37:e3:51:ce:27) to (a2:47:a2:a0:09:28) associated with another peer b6:8c:12:9f:d3:cf(artlva1drw02v)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.740934 Captured frame from MAC (f6:db:39:c1:ae:9b) to (e2:5f:75:3d:ba:82) associated with another peer a2:08:24:39:97:51(drw06)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.758158 Captured frame from MAC (5a:fe:0f:49:cd:3a) to (ba:a6:c4:64:fb:8d) associated with another peer b6:8c:12:9f:d3:cf(artlva1drw02v)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.759996 Captured frame from MAC (0a:0e:13:a2:81:87) to (46:4f:8f:00:32:c9) associated with another peer ba:60:6d:17:86:cc(drd07)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.760969 Captured frame from MAC (2e:9e:0d:47:d6:70) to (0a:71:e9:81:60:2a) associated with another peer ba:60:6d:17:86:cc(drd07)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.762235 Captured frame from MAC (8e:64:30:b3:b5:da) to (a2:47:a2:a0:09:28) associated with another peer a2:08:24:39:97:51(drw06)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.772611 Captured frame from MAC (82:d5:71:39:e4:35) to (0a:30:22:75:25:16) associated with another peer 72:b3:cf:99:6a:4f(drw09)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:57.777031 Received packet for unknown destination: 4a:4d:82:27:1a:19(drd06)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.779902 Captured frame from MAC (a2:9f:27:4a:ac:59) to (ba:a6:c4:64:fb:8d) associated with another peer 36:23:d0:53:85:5e(drw01v)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:57.782302 Received packet for unknown destination: 4a:4d:82:27:1a:19(drd06)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:57.782503 Removed unreachable peer 4a:4d:82:27:1a:19(drd06)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:57.782531 Removed unreachable peer c6:2f:d0:e1:0e:1c(drc02)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:57.782610 [nameserver 16:fa:31:50:ca:ee] peer 4a:4d:82:27:1a:19 gone
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: INFO: 2024/07/12 05:51:57.782788 [nameserver 16:fa:31:50:ca:ee] peer c6:2f:d0:e1:0e:1c gone
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.801039 Captured frame from MAC (1a:31:26:1e:5f:3c) to (a2:56:60:b7:0a:7d) associated with another peer ba:60:6d:17:86:cc(drd07)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.875942 Captured frame from MAC (7e:a6:db:69:5e:55) to (a2:47:a2:a0:09:28) associated with another peer b2:b3:36:b4:26:17(drd02)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.878600 Captured frame from MAC (76:8c:85:5c:07:3a) to (0a:30:22:75:25:16) associated with another peer 62:00:4b:57:18:78(drw04)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.882100 Captured frame from MAC (6e:bc:7c:5f:3e:71) to (26:92:b3:13:cb:e3) associated with another peer a2:08:24:39:97:51(drw06)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.894657 Captured frame from MAC (ee:10:fd:91:00:d0) to (1a:9a:c7:05:3f:73) associated with another peer ba:60:6d:17:86:cc(drd07)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.902000 Captured frame from MAC (76:06:63:1c:82:95) to (e2:5f:75:3d:ba:82) associated with another peer 72:b3:cf:99:6a:4f(drw09)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.906528 Captured frame from MAC (36:3f:90:d9:74:d1) to (ba:a6:c4:64:fb:8d) associated with another peer a6:31:78:8d:d1:02(drd08)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.941386 Captured frame from MAC (72:1d:8b:3c:4a:91) to (76:e7:a5:4e:17:2a) associated with another peer ba:60:6d:17:86:cc(drd07)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.942742 Captured frame from MAC (72:1d:8b:3c:4a:91) to (e2:5f:75:3d:ba:82) associated with another peer ba:60:6d:17:86:cc(drd07)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.950593 Captured frame from MAC (6a:fe:60:6f:57:50) to (fe:d6:79:a1:41:f7) associated with another peer ba:60:6d:17:86:cc(drd07)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.953845 Captured frame from MAC (f6:db:39:c1:ae:9b) to (16:1a:c1:2e:1c:44) associated with another peer a2:08:24:39:97:51(drw06)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.959457 Captured frame from MAC (12:cc:22:5e:74:56) to (6a:64:0c:0e:53:77) associated with another peer a2:08:24:39:97:51(drw06)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.992000 Captured frame from MAC (1a:d6:43:2d:21:74) to (0a:30:22:75:25:16) associated with another peer 42:54:8b:e3:d1:c0(drw05)
Jul 12 05:51:57 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:57.994428 Captured frame from MAC (72:14:bc:9a:8f:c7) to (a2:56:60:b7:0a:7d) associated with another peer 42:54:8b:e3:d1:c0(drw05)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.002077 Captured frame from MAC (1a:d6:43:2d:21:74) to (96:5c:71:48:5b:9a) associated with another peer 42:54:8b:e3:d1:c0(drw05)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.018549 Captured frame from MAC (de:da:00:62:58:18) to (72:6e:1d:43:85:d7) associated with another peer ee:d7:04:9f:09:90(drw03)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.021145 Captured frame from MAC (ee:cc:b9:36:f6:43) to (a2:47:a2:a0:09:28) associated with another peer 72:b3:cf:99:6a:4f(drw09)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.021795 Captured frame from MAC (e6:21:56:94:23:2c) to (aa:bc:e3:5b:4d:a9) associated with another peer 62:00:4b:57:18:78(drw04)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.030644 Captured frame from MAC (5a:fe:0f:4MAC (72:63:27:1e:5a:0b) to (16:1a:c1:2e:1c:44) associated with another peer a6:31:78:8d:d1:02(drd08)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.090458 Captured frame from MAC (1a:31:26:1e:5f:3c) to (3a:be:15:b6:f9:f7) associated with another peer ba:60:6d:17:86:cc(drd07)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.113999 Captured frame from MAC (d2:b5:99:98:9b:99) to (96:5c:71:48:5b:9a) associated with another peer ee:14:7d:c4:d8:6b(drd01)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.114090 Captured frame from MAC (d2:25:db:ab:98:11) to (0a:71:e9:81:60:2a) associated with another peer ee:14:7d:c4:d8:6b(drd01)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.114221 Captured frame from MAC (1a:31:26:1e:5f:3c) to (1a:9a:c7:05:3f:73) associated with another peer ba:60:6d:17:86:cc(drd07)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.119484 Captured frame from MAC (9e:46:db:78:89:55) to (a2:56:60:b7:0a:7d) associated with another peer a6:31:78:8d:d1:02(drd08)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.119553 Captured frame from MAC (9e:46:db:78:89:55) to (ae:17:8a:86:c0:51) associated with another peer a6:31:78:8d:d1:02(drd08)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.120161 Captured frame from MAC (4e:1b:de:40:87:ac) to (3a:be:15:b6:f9:f7) associated with another peer e2:e8:5e:7e:3c:40(drd02)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.131048 Captured frame from MAC (2e:fb:31:5d:7d:f4) to (a2:47:a2:a0:09:28) associated with another peer ee:d7:04:9f:09:90(drw03)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.139629 Captured frame from MAC (6e:a0:cc:d2:a7:2c) to (ae:42:3d:6c:eb:6b) associated with another peer ba:60:6d:17:86:cc(drd07)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.140913 Captured frame from MAC (86:d9:eb:05:01:85) to (ce:85:df:09:b8:6c) associated with another peer a2:08:24:39:97:51(drw06)
Jul 12 05:51:58 drd03 98f12d3f9bd9[21292]: ERRO: 2024/07/12 05:51:58.141398 Captured frame from MAC (76:06:63:1c:82:95) to (e2:e3:90:4f:e2:0c) associated with another peer 72:b3:cf:99:6a:4f(drw09)

This log looks normal. You can see a downed node being removed, from "Unable to find connection to relay peer c6:2f:d0:e1:0e:1c" to "Removed unreachable peer c6:2f:d0:e1:0e:1c(drc02)" to "[nameserver 16:fa:31:50:ca:ee] peer c6:2f:d0:e1:0e:1c gone". It seems that the topology update is not yet complete, but it should be in a while. Are you facing any application-level problems at this time?

yes, while this is happening , we are having issues in our consul cluster as well and due to combination of both these the application is having downtime

I'll try to reproduce this with consul on a weave cluster. Meanwhile, could we try increasing the connlimit to 625?

yes , will try increasing connlimit to 625 .
My understanding is that increasing connlimit to 625 will reduce the no of toplogy updates and will decrease the convergence time also
is that correct ?

It will increase the possibility of decreasing the convergence time, because topology updates are likely to complete faster with more connections available. I'm sorry, but that is all I can promise at the moment.

is there a way to measure the convergence time ?
any kpi to measure convergence times / when convergence is completed ?
If I increase the connlimit to 625 how do we say that we are seeing an improvement in convergence time ?


Reduce build differences between Java and Scala shopping-cart projects

Mostly shuffling build settings, but also some some adjustments. The idea is to make them easier to compare to each other, specially when used in other places (like telemetry samples).

Nice! thanks @marcospereira


Red-black trees

I will implement the RedBlack trees and its important features

I would like to work on this one. Should the tree only be able to handle ints?

@yblank1 Sure you can!

Should the tree only be able to handle ints?

It would be better if it's generic (templated), which would enable it to handle any data type for which the comparison operators are already defined (such as all the built-in types).

@faheel Is this under development by anyone? (No pull requests)
If no one is working on this, I will take this up.

@psarvesh Doesn't look like anyone's working on it, so you can 👍

Closing this since there haven't been any updates for a long time. Please open a new issue if you'd like to work on red-black trees.


Xplat static library improvement v3

This should greatly improve the static library handling/generation on Ubuntu 16.04 LTS, and OS X. I believe that the Force_Load option should help reduce the symbol issues on with OS X regardless of version.
Note: I have not tested these changes on OS X where ChakraCore is stored in a path with spaces, but the fix for this should be fairly easy.
V2: changes: attempt to fix compile/runtime errors with MSVC/OSX, and errors on native tests.
V3: Dropped conversion of existing static libraries to objects.

Hi @kphillisjr, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;

@obastemur - Just as a heads up, Even though OSX failed this time, the current status has great improvement. The logs show that this is failing at the runtime tests.

The next couple of pushes will merge the various static libraries into the core libChakraCoreStatic library.

@kphillisjr We could use ar on linux and libtool on OSX to combine those three into one. However, we had concerns with the ordering of global constructors and destructors so we didn't do it yet. IMO, we don't have much good reasons to do it or push it.
So basically we could merge them without making these changes. (but we shouldn't until we are in a better shape with global cons etc.)
Second; this PR tries to combine the interfaces for shared and static libs under ChakraCore folder / project. This possibly improves the compile times for when someone compiles shared after static lib vice versa ? Please point me out if I'm missing other improvements and why this particular scenario is so important?
Could you please share how this approach would help with our shared lib initialization problem ?
As I mentioned many times; I really appreciate the effort but as long as there is no really good reason, I would go with ar / libtool (but not for now) and make final ChakraCore lib lighter instead.

@obastemur  Wrote: This possibly improves the compile times for when someone compiles shared after static lib vice versa?
This is a Definite yes, it greatly reduces the build time to switch between static and shared libraries... Actually right now due to the changes I made here, the total compile time to change from static build to shared build and back in a single go is under 30 seconds because the only item that gets rebuilt is the ch utility.

Actually, with the build time being this small, it is possible to generate both a static ch utility ( say, ch.static ) and the regular ch utility, and have runtests.sh test both utilities one after another.

Please point me out if I'm missing other improvements and why this particular scenario is so important?

The other improvement by this approach is that there is less chance of bugs sneaking in by switching between static and shared libraries on xplat. Also, this fixes issue #1811 all together since the static symbol used internally by the static library is not  defined out on xplat.

Could you please share how this approach would help with our shared lib initialization problem ?
The new file ChakraCoreCommon.cpp includes all of the symbols common between the static and shared libraries of chakracore. The VALIDATE_ENTER_CURRENT_THREAD() function takes care of the shared library Initialization for us in a well tested fashion... This is actually used in the static library already.

I would like to get this Integrated into the 2.0 release window for pull #2170. What changes would be needed to merge these changes. The biggest Improvements this offers is as follows...

Generates a static library and shared library during initial run of build.sh.
Reduces compile definition pollution when --static argument is passed to build.sh. This provides dramatic build time improvements for older systems where recompiling everything could take more than 10 minutes.
Simpler linker requirements for xplat static builds - End users just need the system library dependencies, and ChakraCoreStatic to handle everything.
Simpler linker requirements for shared xplat builds - All you need to do is link to ChakraCore dynamic library, and this will automatically handle process initialization/termination on xplat.
Simpler packaging requirements for shared/static libraries -  For linux the X86_64 prebuilt binaries compressed in tar.gz format that contains the Headers, static library and shared library is about 13MB for Release builds, and for Debug builds it is about 175mb.  If you only include the Shared Library, and headers the archive is about 5MB for Debug builds and about 55MB for Debug builds.

@obastemur, I went ahead and rebased all of my changes on a new branch located at kphillisjr/ChakraCore at xplat_improvements_for_v2. These Changes are to address most of the problems designated in issue #1616.

I've been using the work done which integrates this merge (along with those in #1616 ) and can verify this is working for me in a 3rd party static library capacity on linux x64 debug. (And is a little more idiomatic than the current cmake targets defined for a/the static library/libraries)

https://github.com/Microsoft/ChakraCore/issues/2575#issuecomment-283128713


feat: add nix support

add flake.nix and default.nix for Nix builds

tests

nix build .# works
nix run .# works
nix develop provisions a dev environment with zig

Works on the first try! :kissing: :ok_hand: :sparkles:
❯ nix run
dt 1.2.4
Learn from my mistakes - someone should.
» [ 1 2 3 4 5 6 7 8 9 ] [ \n: [ ] [ "*" push ] n times  unwords ] map pls
*
* *
* * *
* * * *
* * * * *
* * * * * *
* * * * * * *
* * * * * * * *
* * * * * * * * *
»

❯ nix develop
[hiljusti@blackbox dt]$ which zig
/nix/store/6vgflg2gmqs0cn6n3h2npimfcybizwwp-zig-0.11.0/bin/zig
[hiljusti@blackbox dt]$ zig build
[hiljusti@blackbox dt]$ zig-out/bin/dt
dt 1.2.4
Keep your stick on the ice.
» quit
[hiljusti@blackbox dt]$


As a disorganized cook, I want to create shopping lists for my recipes,

so that I will know all the ingredients I need to buy.

for 2.0


Enable POGO builds in MBv2 daily config, automatic NuGet generation and publication. Add build composition script.

Includes progress on #85

This change is

@digitalinfinity If you have a moment, please review?

@Cellule Any review feedback or is this good to merge?

lgtm

Thanks, @Cellule! Merged.


Video capture plugin??

Android React Native doesn't have a video recording package yet. Has anyone been able to get video capture to work on android using this? I'd give it a try, but I've only done iOS React native work thus far.
Here's currently the only option for video recording on React Native iOS:
https://github.com/maxs15/react-native-screcorder
Here's the main video recording cordova plugin:
https://github.com/EddyVerbruggen/VideoCapturePlus-PhoneGap-Plugin
Incidentally I used and contributed to it 2 years ago, but it seems possibly Android cordova developers are using a built-in video capture plugin now: http://docs.phonegap.com/en/2.2.0/cordova_media_capture_capture.md.html
Either way, anyone have any luck getting one of these 2 video capture plugins to work using react-native-cordova-plugin?

@faceyspacey I just published 1.0.0 version of this plugin on npm. I also now have an example app that shows how to use the plugins. While I don't have an example of the camera plugin yet, it should work.

cool, i'll check it out soon. Finishing up an iOS app that I'll need to make an Android version for, which will require the cordova video capture plugin.

@faceyspacey I just added the cordova-plugin-media-capture in the example app and I do see Audio and Video capture working.
Closing this issue, since it is working. Please do re-open if you run into issues.


Begin the proposal for discovery API

This branch is to have a place to coordinate on the discovery API.
See Endpoint Reqs
As of this writing, any that don't have a solution defined (maybe...) are not documented.
Here are the endpoints we believe we need
# Template
* SECTION
  + ENDPOINT
    - NEW/MODIFY
    - OWNER

# Endpoints

* Order
  + products/skus/search/completion
    - modify
    - John
  + Create PO /orders/create/
    - modify
    - Jeff
* Payment Methods
  + Get Saved Payment Methods
    - new
    - Jeff
  + Create New Payment Method
    - new
    - Jeff
  + Update a Payment Method
    - new
    - Jeff
  + Delete Payment Method
    - new
    - Jeff
  + Set Default Payment Method
    - new
    - Jeff
* Discovery Catalog
  + Get Discovery Suppliers
    - new
    - Jeff
  + Create Connection
    - new
    - Jeff
  + Search Items
    - modify?
    - John
* Products
  + Get Discovery Participation
    - new/modify/nothing at all depending on implementation (see google doc)
    - John
* Suppliers
  + Get Catalogs
    - new?
    - John
  + Get Discvery Participation
    - modify
    - Jeff
  + Update Discovery Participation
    - new
    - Jeff
* Tools
  + Get Suppliers Requesting Discovery Participation
    - new
    - Jeff
  + Update status os Suppliers Requesting Discovery Participation
    - new
    - Jeff

We don't want to merge this into master until it is fully fleshed out and the relevant api changes are actually released, but this PR serves as a basis for discussion and documentation in the meantime.

I don't think any changes to the Item Search API are necessary.  As discussed in the google doc, if the connection is direct then that will show up.  If the connection is not direct, then a retailer's view of the supplier's discovery catalog will be shown.
This also assumes that we add an attribute to the catalog (is_discoverable) or perhaps an attribute properties which might include the choice is_discoverable.

Also, after we've made any final changes to this PR, I'd like to clear any reviews up to this point and request reviews again just to make sure everybody takes a look at the final contract and gives a +1.
Also, @edje-jeter it's missing the change to the search interface that john mentioned in the google doc.
@edje-jeter You may want to ask @nickcoleman to deal with the conflict in the Crux-API-Project.paw since he's well versed with how to handle that. Let me know if I've raised any questions or concerns.

Checklist for updating docs:
Discovery

[ ] PUBLIC POST /discovery/suppliers

Tools

[ ] INTERNAL GET /discovery/participation/<org_uuid>/
[ ] INTERNAL POST /discovery/participation/<org_uuid>/

Organizations

[ ] PUBLIC PUT /organizations/files/upload/
[ ] PUBLIC GET /organizations/connections/
[ ] PUBLIC GET /organizations/connections/request/<uuid>
[ ] PUBLIC GET /organizations/connections/request/
[ ] PUBLIC POST /organizations/connections/request/
[ ] PUBLIC PATCH /organizations/connections/request/<uuid>/


Catalan Windows 10 datepicker uses wrong form for months

copied from internal issue

"In this context, correct/good forms are ones without "de" proposition: gen., febr., marc, abr., maig, juby, jul., ag., set. oct. nov.,and dec."

Closing because this issue will be handled by localization team.

Turns out this is a bug in CalendarView's code behind


Preserve SVG text size after scale transform

After talking about the design for a while internally, we decided against semantic zoom.


Make the deeplink url configurable in the config options

This PR aims at allowing a new url config option which can be used instead of the query param. The query param is still supported, and when provided it takes precedence over the config option.

Thanks @sebphil .
I am curious to know what functionality was missing for you. I assume you could make sure to always pass a url in the query param no ?

Hi @mderazon , thanks for the quick reply.
I'm currently in the process of rewriting an old webapp, and that webapp hosted a deeplink routing feature that I need to port to the new webapp. In the old webapp, the deeplink url was not defined in the query params but was instead configured directly in the webapp. Now, in my new webapp, I need to be backwards compatible with the entry point the old webapp provided, because I cannot easily change the client code of that entry point. Hence the need to be able to provide the deeplink url in the config and not in the query params.

Got it. Thanks for taking the time to write PR with tests

Thank you very much!


support quantity datatype

some notes:

maching numbers without (non-breaking) spaces
repecting interval constraint
an optional field for the unit that template adds by default
optional precision (in %)?

partially done with ee98cbc0c552c3e633da80168198a34ba16bc028 and  fb2892428f6fec3f11069dc9d35fae0df9f3867e
floating point numbers are disabled due to wrong transmission, e.g. https://www.wikidata.org/w/index.php?title=Q4115189&type=revision&diff=324643094&oldid=324200261

Maybe we could allow to add also such values: 173 cm/1.73 m? Should be pretty safe for some cases, right?

In "some cases", yes. But this feeling goes away when you realize that units are often inside a (mostly redundant and possibly wrong) wikilink and the tool simplifies parsing by removing the after-pipe part (which contains the unit symbol).