Setup AnyCpu, uncheck prefer 32-bit as platform target

This is an incomplete pull request regarding the bug #1117 that I encountered. Before completing this for all different Visual Studio versions etc  I would like some input if a complete pull request in the line of these changes would be acceptable.
The unit-tests all work .
The changes makes sure git-tfs.exe will adapt to the architecture of the host shell. By doing this the command line can run in 64-bit mode, hence more memory should be available for the git-tfs process.
I think regardless if #1117 is fixed or not by this is a correct approach to the tool, what do you think?
(I am test runing as I type but it will take time)

Before completing this for all different Visual Studio versions etc I would like some input if a complete pull request in the line of these changes would be acceptable.

Good question. I'm in favor of setting git-tfs to be "Any CPU", and #619 did that. But #1019 changed it back to "x86", because of checkin policies that are built as x86.
I'm interested to hear if this fixes #1117. That said, git-tfs shouldn't be using that much memory, and there probably is another fix that would make git-tfs work in x86 mode.

HI @spraints, thanks for the feedback !
When doing the pull requests all checks passed so hopefully it is all good :)
I do agree that there is probably something that could reduce memory consumption however this is not something I have the time to fix.
However I realize that there might be tons of things about the code I have not considered so if there are any negative side effects please let me know!
I will get back to you regarding #1117, cloning is still in progress.

#1117 was resolved by these changes

But #1019 changed it back to "x86", because of checkin policies that are built as x86.
&
When doing the pull requests all checks passed so hopefully it is all good :)

@JensNordenbro
That is not that simple :(
Our unit tests (and smoke tests) doesn't test checkin policies that occures only when checking in TFVC.
Which is also one of the main raison why we maintain different version for each TFS version....
So, I don't know what we should do....

@pmiossec - you make me confused.
I noticed in the solution that there are different Visual studio csproj-files for different Visual Studio versions but not the part about "different version for each TFS-version". Maybe it is the TFS version it reflects?
Is there anything I can  do to proceed or is this a matter of changing/disabling the checkin-policy that is neccessary?

@pmiossec  Would making two releases, one for "x86" and one for "any CPU" solve the problem?
I have also been hit by bug #1117 and would appreciate a solution.

@EdorianDark , did you try out my fork?

@JensNordenbro  No, but I am certain, that it would solve the problem.

@pmiossec, do you have any comment to our questions? I would accept a reject but it would be nice to get a definitive reject or directions for approval (aside from the merge from master).

We have 2 possibilities :

use 'AnyCpu' and break the use of check-in policies
use 'x86' and sometimes have an out of memory exception when cloning. An operation that could be continued...

I think we should look around playing with the 32bit flag like described in this post:
https://lostechies.com/gabrielschenker/2009/10/21/force-net-application-to-run-in-32bit-process-on-64bit-os/
Perhaps providing 2 exe, one with the flag on and one with the flag off.
That requires some tests...

Some other options:

ship only AnyCPU and write up directions for how to use corflags to change it if you need to.
build as AnyCPU, but use corflags to mark the distributed exe as x86, and write up directions on how to undo that.

My personal preference is to ship only one exe, because I think it makes for a better UX. In this case, shipping two exes is probably the best experience. I think I'd make git-tfs.exe be x86, and git-tfs-x64.exe would be the same binary but flagged to run as x64. How does that sound?

These TFVC policies you talk about @pmiossec ; are they failing because of rule forbidding Any Cpu or is it some technical reason that breaks all checkin-policy rules?

@spraints

Some other options [...] How does that sound?

Very good summary of my point of view. I am perfectly in line with that point of view.
The only choice remaining is which one will be the default. I can't make a choice. I don't know which one will annoy the less people...
(and test if corflags exists on the build server and update the build and packaging)
@JensNordenbro

These TFVC policies you talk about @pmiossec ; are they failing because of rule forbidding Any Cpu or is it some technical reason that breaks all checkin-policy rules?

When there are checkin policies defined on the server, the TFS client assemblies try to load client assembies to do the checkin. But at the moment, these assemblies are only provided as x86 by Microsoft.
So, to be able to checkin when there are such policies, git-tfs should be able to load these assemblies so be run as x86.
I think that there are not a lot of user in this case nor ones encountering the OutOfMemory Exception.
So, I don't know what should be the state of the flag "Prefer32bit"...
Anyway, please change all the projects as "AnyCPU", we will figure it out later for the flag...

VS runs (or used to) as x86. So checkin policies would always run as x86. A pure .NET DLL that's built as x86 or as AnyCPU would run fine in this scenario. Problems happen if the policy DLL is x86 and git-tfs is AnyCPU.

But at the moment, these assemblies are only provided as x86 by Microsoft.

Ugh, really? If MS is still distributing DLLs as x86, then my vote is that git-tfs should default to running in x86 mode. I think my vote is that git-tfs should default to running in x86 mode anyway. I guess we could be clever and run AnyCPU for everything, and the run an x86 shim exe to do checkins?

Closing due to #1138

Tried it. I had been having repeated out-of-memory errors while trying to clone a large TFS repo (resulting git repo: ~5GB, packed), and no longer had any using this build.

@m-akinc  It would be great, if you could test #1138


[ansible] Provide External Access to Cluster Addon Services

Currently, the ansible project supports cluster addons [1] by default. Many of the addon services should be exposed external to the cluster. The addon manifests do not provide a common way for externally exposing services [2]. The ansible project should provide this mechanism. Here are a few options to achieve this goal:

Use the contrib/service-loadbalancer project [3] in the kube-system namespace to manage each addon service that should be externally exposed.
Use the nginx ingress controller project [4] in the kube-system namespace to manage each addon service that should be externally exposed.

In either case, a new ansible role should be created to manage this functionality.
[1] https://github.com/kubernetes/kubernetes/tree/master/cluster/addons
[2] https://github.com/kubernetes/kubernetes/issues/23620
[3] https://github.com/kubernetes/contrib/tree/master/service-loadbalancer
[4] https://github.com/kubernetes/contrib/tree/master/ingress/controllers
/cc: @rutsky @adamschaub @eparis

@danehans @adamschaub @stephenrlouie any plans to implement this soon?
I'm exploring ways of exposing cluster addons to external network currently, and interested if you started anything to achieve this already?
I want to try Ingress controller, since it looks like promising approach.

@rutsky I was able to use https://github.com/kubernetes/contrib/tree/master/service-loadbalancer to expose addons. I have been in communication with NGINX and they are interested in making https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx work. To make the nginx ingress controller work, we have two options, one is long-term fix while the other is short-term.

The Long term one: Addons you're interested in exposing via Ingress must be able to provide the ability to configure ROOT URL of the http service they provide. Like for example, the graphana addon supports it -- https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml#L66-67. Configuring the same path in the addon configuration file and the same path in Ingress resource should lead to no issues.

The Short term one: A workaround using NGINX on per addon basis, not very elegant, but should be functional.

If you're using NGINX controllers from here, you can use this workaround gist to expose grafana and the dashboard
Although the grafana supports configuring its ROOT_URL, there are still issues, so this workaround also applies to the grafana.

This makes sense. How much more complicated is the feature set of re-write rules? ROOT_URL feels like  a more general re-write policy that would be nicely exposed as:
    http:
      paths:
      - path: /dashboard/
        rewrite: /
        backend:
          serviceName: kubernetes-dashboard
          servicePort: 80

Unfortunately clouds don't support re-write yet, but it's such a common task for a proxy that I don't think we should wait. I don't want to handle this on a per addon basis (either controller per addon, or enabling it on an addon like grafana that supports ROOT_URL).
@pleshakov is there a more general argument for making ROOT_URL different from simple rewrite? I'd like to keep Ingress as cross-platform as possible, so unless there's a stong case to expose both a rewrite AND a root-url, I think we should just do rewrite.
@kubernetes/sig-network @aledbf @lavalamp

In the short term, we could do this through an annotation that applies to all rules in the Ingress, and/or through a cmd line flag that applies to all ingresses satisfied by an ingress controller. We need a way to run multiple ingress controllers in a single cluster anyway (eg: one that watches only kube-system and takes --root-url and one that watches everything else and passes urls as-is).

@erictune and I were just talking about switching addon access to go through an Ingress, we actually have started a doc about this but not published it yet. Let's pick URL paths that are easy to compose (unlikely to collide). /components/dashboard/, /addons/dashboard/, or /ui/dashboard/ instead of just /dashboard/, for example. We're thinking right now that we want to install kube-apiserver at the root of this ingress, so that's got a number of paths you should avoid colliding with.

@bprashanth If every addon could provide an option to configure the ROOT_URL of their HTTP service, exposing them via Ingress should work for existing Ingress controller implementations.
I think rewrite is a nice and useful feature. However, sometimes it does not work by simply sending a request from the load balancer to the backend at the new URL. For example, if an application in its html pages returns hard-coded absolute links. For such applications, to make it work, we inspect the returned html content and headers, and fix the links. In case of NGINX, this can be done by adding sub_filter rules, but they would be different, depending on the application. It looks like the proxy in the kube api-server does that-- https://github.com/kubernetes/kubernetes/blob/master/pkg/util/proxy/transport.go

If every addon could provide an option to configure the ROOT_URL of their HTTP service, exposing them via Ingress should work for existing Ingress controller implementations.

Agreed, but that's just another piece we need to teach everyone writing a new cluster addon about. Given that we probably need some rewrite idiom, I think we can come up with something that doesn't require the backend to explicitly cooperate.

For example, if an application in its html pages returns hard-coded absolute links. For such applications, to make it work, we inspect the returned html content and headers, and fix the links.

Isn't that the common case? We'd just document that our rewrite option is dependent on how the ingress controller implements it, some many not handle it at all, some do a dumb re-write, while those capable maintain a good user experience (eg: fixing links)
@pleshakov is there a case where > 30% users would want fine granied control over re-writes (eg: to say only re-write don't fix hard links) that can't be expressed through annotations (meaning it would be too hard to do at the Ingress scope, instead of Ingress.Rule scope)?

@bprashanth

Isn't that the common case? We'd just document that our rewrite option is dependent on how the ingress controller implements it, some many not handle it at all, some do a dumb re-write, while those capable maintain a good user experience (eg: fixing links)

The common case is the dumb rewrite. But it should work for a lot of applications. It seems to work fine for the dashboard and the grafana addons. Agree, handling of any special cases would be different from one controller to another.

@pleshakov is there a case where > 30% users would want fine granied control over re-writes (eg: to say only re-write don't fix hard links) that can't be expressed through annotations (meaning it would be too hard to do at the Ingress scope, instead of Ingress.Rule scope)?

In the case of NGINX Controller, If we offer a user to put NGINX configuration snippets in annotations in an Ingress resource that will fix any problems by rewriting the response headers and body from the backend, this will be the fine grained control,  with which the user should be able to fix most of the problems. The snippets will be different, depending on the application, and they will be inserted into the configuration file. It will look ugly, but hopefully rarely used.
Another related but useful feature can be a redirect
http:
      paths:
      - path: /ui/
        redirect:
          path: /dashboard/
          type: permanent
      - path: /dashboard/
        rewrite: /
        backend:
          serviceName: kubernetes-dashboard
          servicePort: 80

@danehans please check the rewrite example (gcr.io/google_containers/nginx-ingress-controller:0.7)
Any feedback or suggestion is welcomed


another bug it locks on to someone then a=if i put my cursor on someone else it is still locked on to the original person and wont let me lock on to the person that nearest to my cursot

same to me!

Pls fix!


"Recursive URL" Document loader load useless documents

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangChain documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I am sure that this is a bug in LangChain rather than my code.
[X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

Example Code
from langchain_community.document_loaders.recursive_url_loader import RecursiveUrlLoader
from bs4 import BeautifulSoup as Soup

url = "https://www.example.com/"
loader = RecursiveUrlLoader(
    url=url, max_depth=2, extractor=lambda x: Soup(x, "html.parser").text
)
docs = loader.load()

Error Message and Stack Trace (if applicable)
No response
Description
I'm trying to use "Recursive URL" Document loaders from "langchain_community.document_loaders.recursive_url_loader" to process load all URLs under a root directory but css or js links are also processed
System Info
System Information

OS:  Linux
OS Version:  #1 SMP Tue Dec 19 13:14:11 UTC 2023
Python Version:  3.10.13 | packaged by conda-forge | (main, Dec 23 2023, 15:36:39) [GCC 12.3.0]

Package Information

langchain_core: 0.1.48
langchain: 0.1.17
langchain_community: 0.0.36
langsmith: 0.1.52
langchain_cohere: 0.1.4
langchain_text_splitters: 0.0.1

Hey, @beethogedeon can you provide the URL where you are facing the problem?
For the URL currently given by you (https://example.com/), the problem lies in the extractor. you have used a very basic extractor and the code can be changed to:
from langchain_community.document_loaders.recursive_url_loader import RecursiveUrlLoader
from bs4 import BeautifulSoup as Soup

def text_extractor(r_text: str) -> str:
    soup = Soup(r_text, "html.parser")
    return " ".join(soup.text.split())

url = "https://www.example.com/"
loader = RecursiveUrlLoader(
    url=url,
    max_depth=2,
    extractor=text_extractor,
)
docs = loader.load()

PS: This only solves the problem of extra whitespaces.


Regression when upgrading to 2.0.0

I try to upgrade from 1.8.1 to 2.0.0 but compilation failed with a strange behavior:

first brunch build give some detailed errors (2370, 2488, 2503...).
next brunch build just print on error per file: error: Compiling of [filename].ts failed.

My IDE (VSCode) dont give any error.
Here is my project code:
1.8.1 on master branch: https://github.com/devnewton/shmuprpg
2.0.0 on typescript2 branch: https://github.com/devnewton/shmuprpg/tree/typescript2

Hi @devnewton
If you are coming from version 1.8.1 then you've run into the issue which arose after surfacing the underlying TypeScript errors. You can read the README section for more information: https://github.com/baptistedonaux/brunch-typescript#errors
The bottom line, you can get back to what you had before with this in your brunch-config file:
  plugins: {
    brunchTypescript: {
      ignoreErrors: true
    }
  }

I've set the ignoreErrors parameter, but I still get these errors. Here is the exact shell command to reproduce:
git clone https://github.com/devnewton/shmuprpg t2-shmuprpg
git checkout typescript2
brunch build
brunch build

You were absolutely correct, I had a typo in that code path when setting ignoreErrors to true. I've fixed it and pushed it in for version 2.0.1, but I'll need @baptistedonaux to publish the new version on npm.

Thank you, I'll wait for @baptistedonaux release then!

Hey ! Thanks @devnewton for your issue and again thanks @colinbate for your fix !
Sorry for the response time, I published the new release 2.0.1 !


test framerate python 3.9 on win 10 give me this error

File "C:\Users\trax\PycharmProjects\cccc\testframerate.py", line 1, in
from ffmpeg_screenshot_pipe import FFmpegshot, get_max_framerate
File "C:\Users\trax\PycharmProjects\cccc.venv\lib\site-packages\ffmpeg_screenshot_pipe_init_.py", line 1, in
from appshwnd import (
File "C:\Users\trax\PycharmProjects\cccc.venv\lib\site-packages\appshwnd_init_.py", line 13, in
hwnd: int | HWND, startwindowtext: str, updatedwindowtext: str
TypeError: unsupported operand type(s) for |: 'type' and '_ctypes.PyCSimpleType'

i think is  py 3.9 the problem, on 3.10 works...

Yes, type hints with "|" only from 3.10 on


multiple geometry/tissue data should be displayed on the same graph. Not multiple graphs.

I am working on this in the branch figureManagement.

data display will be completely remade. We will see how the design goes, but we will keep that in mind.


chore: safe crash application on theme APIs failure

Description
Added theme error effects into failureActionEffect during app initialisation.
Type of change

Minor refactor

How Has This Been Tested?

Manual

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

Test coverage results :test_tube:
:red_circle: Total coverage has decreased
// Code coverage diff between base branch:release and head branch: chore/fail-fast-on-theme-apis

Status
File
% Stmts
% Branch
% Funcs
% Lines

:red_circle:
total
56.58 (-0.01)
38.39 (-0.01)
35.84 (0)
56.83 (-0.01)

:red_circle:
app/client/src/selectors/commentsSelectors.ts
83.61 (-1.64)
61.76 (-2.95)
73.33 (0)
88.24 (-2.35)

/ok-to-test sha=8b461e1

/ok-to-test sha=5fbffca


Fabric 1.19.2 - Very heavy load on the server

I started the Spark profiler, and after a while I got the results in the mods department.
Version carpet fixes: carpet-fixes-1.19-1.12.2.jar
https://spark.lucko.me/MtZJywWkwll

and carpet.conf
shulkerSpawningInEndCities true
leadFix true
renewableDragonHead true
piglinsSpawningInBastions true
optimizedTNTHighPriority true
creeperBlockDamage none
railDupingFix true
optimizedFastEntityMovement true
fastRedstoneDust true
sandDupingFix true
renewableElytra 0.1
optimizedHardHitBoxEntityCollision true
quickHarvesting true
renewableDragonEgg true
lagFreeSpawning true
maxEntityCollisions 1
tntDupingFix true

Please only post performance data if you actually understand what you are doing.
Carpet-Fixes replaces some of the servers main class. Making it seem like carpet-fixes is taking up a lot of performance, its not.
Carpet-Fixes actually takes up nearly no performance


Issues with "refresh" and "terminal" options

This is an extremely handy plugin for OSX. However, I am having some issues getting a few of the options to work. One is the "terminal=true/false" option. If I set it to false, to keep windows from cropping up, scripts never executed. I have tried several different executables, and tried supplying the full path, but nothing ever seems to run when using this option.
EXAMPLE: echo "Reset Wi-fi | bash='sudo /usr/local/bin/reset-wifi; exit' terminal=false"
The other option is refresh=true. It would be nice to have other options for refreshing, since some of my scripts (like connecting to a VPN) do not complete immediately. However, even for those scripts that do exit quickly, the refresh never seems to occur.
EXAMPLE: echo "Proxy On | bash='pkill -9 -f <IP_ADDRESS>:12345; exit' refresh=true"

You're using the bash parameter wrong. It breaks when using terminal=false.  Check matryer/bitbar-plugins for examples on how to do this.

I'm not sure what is complex about them. Each line is only command. I just added the "exit" to keep from having a bunch of windows piling up, which is what I was hoping "terminal=false" would solve. Does this method help with the "refresh" issue as well? Thanks.

Well, bash expects a path to an executable and not the full command with arguments. Those have to be passed separately to param1 and so on if you don't want to use my suggestion.

I have changed the using bash='$0" param1=func, and added the appropriate logic at the top of the script. It still fails to run when terminal=false. What is required to  prevent new windows from spawning every time a command runs? I do not see any other information on using this in the documentation.

@cjbaar The process I use in my plugins looks something like the below, as a bare bones example
#!/bin/bash

## Two functions that can be called based on which param1 string gets passed back to the script
function doSomeFunction ()
{
<commands all go here that you want to run for this function>
}

function doSomeOtherFunction ()
{
<commands all go here that you want to run for this function>
}

## This case statement captures what was passed to param1 and decides which function to call
case "$1" in
    doSomeFunction)
    doSomeFunction
    ;;
    doSomeOtherFunction)
    doSomeOtherFunction
    ;;
    *)
    exit
esac

## Simple example of 2 menu items, which will run the script with the param1 string
echo "Menu item name 1| terminal=false bash=$0 param1=doSomeFunction"
echo "Menu item name 2| terminal=false bash=$0 param1=doSomeOtherFunction"

When either of the menus are selected, the $0 tells bash to run the same script that generates the menu, but inject param1 with the associated variable. It (re) runs the script and the case statement captures the param1 string passed to it (as $1) and in turn runs the embedded function, which runs whatever commands you want to run within it. Within the functions you can get about as complex as you want, so you're not limited to including it all in one line.
In practice, its usually a little more complicated than just the above, but it can be achieved this way, rather than sending an entire full command to to the bash function. It just works more reliably that way since you're really just telling it to run the script itself with special parameters instead of generating the menu. The terminal=false always works for me to prevent seeing Terminal windows.
The other advantage to doing this way is that if you need to call that same command or series of commands in more than one location, it's easy to do by simply passing the correct parameter string to the bash command. It keeps it all in one place for editing in case you have to edit the actual commands later.
Hope that helps.

Thanks @mm2270. I understand the concept of running via $0 from the examples, and have implemented my scripts as such. However, they still do not execute with terminal=false, so I end up launching windows all the time. Nor does refresh=true have any effect.

The bash key requires an absolute path to a binary on your system when using terminal=false. Functions doesn't works.
On my phone right now so can't link to any prior discussions. Try searching for it here in the issues. I've explained why this is the case a few times. I also fixed it in my PR.

8 sep. 2017 kl. 03:21 skrev cjbaar<EMAIL_ADDRESS>Thanks @mm2270. I understand the concept of running via $0 from the examples, and have implemented my scripts as such. However, they still do not execute with terminal=false, so I end up launching windows all the time. Nor does refresh=true have any effect.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Sorry, missed $0 in the example. Strange that it doesn't work as $0 should be expanded into an absolute path.

8 sep. 2017 kl. 03:21 skrev cjbaar<EMAIL_ADDRESS>Thanks @mm2270. I understand the concept of running via $0 from the examples, and have implemented my scripts as such. However, they still do not execute with terminal=false, so I end up launching windows all the time. Nor does refresh=true have any effect.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

FWIW I was trying to run the rm command silently and terminal=false wasn't working. After reading the above comment, I realized I was using it wrong:

I suggest you pass the path to your plugin to bash and an argument to param1

Here’s what I was doing that didn't work:
Refresh State | terminal=false bash="rm -f /path/to/file"

I had to point to the entire executable and then use params.
Refresh State | terminal=false bash=/bin/rm param1=-f param2=/path/to/file

While the README points this out, for some reason I didn't think it applied to "system" commands like rm. But it does. Shows how much I know.
Thanks to all for the feedback here.

Is there a way to refresh the script from within the script without having to click on an item using the | bash=xxx syntax?


etcd: rename alert

This PR renames etcd alert as per upstream recent changes
see https://github.com/etcd-io/etcd/pull/14242

/assign @tjungblu
/assign @EmilyM1

/lgtm


Oni open binaries will cause crash

If a user uses Oni to open a binary, e.g Oni.exe, node.dll in the package, it will crash within seconds.

Thanks for logging the issue! I'm assuming you're on Windows?
I'm able to reproduce as well on Windows 10. It looks like Oni gets the disconnect even from Neovim (which I believe means the neovim process died).
This doesn't reproduce in nvim-qt.exe - so I'm wondering if it is related to the default / core set of plugins we use for Oni integration. In particular, the buffer update might be causing problems for these large binary files.

Yes, I am using Windows 10

Interesting, this isn't a problem on Linux; it loads binary files just fine.  I tried with nvim.exe, which is 3.8MB so I don't think large file sizes are a problem.  I wonder if this issue only occurs on Windows.

I will look into this too since I am making a plugin and it sometimes opens very, very large files :).


Login Issue

[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 276c38fe-aa72-6afa-23d8-14ff206c6f50
Version Independent ID: 9ffe59dd-c667-4802-1da0-6917638804c5
Content: Common problems with account two factor authentication - Azure AD
Content Source: articles/active-directory/user-help/multi-factor-authentication-end-user-troubleshoot.md
Service: active-directory
Sub-service: user-help
GitHub Login: @curtand
Microsoft Alias: curtand

@MoneyMan573 Thank you for your engagement on azure-docs repo. We use this repository for gathering feedback on documentation improvement from customers.  We are sorry for the inconvenience you have to face due to the login issue. Since your's is an issue which may require troubleshooting in all probability , I would like to suggest you to open a thread on our forum Microsoft QnA where we have a great community which can help you with your query.
In case you have any query related to the documentation , please let me know and I will be happy to help further. We will wait for your response and close this issue by end of day tomorrow. We hope that this gets resolved soon for you .
Thank you .

Thank you, all!
I appreciate everyone's support and feedback.  I am still trying to recover everything.  It is getting there.


Stability Issues detected in logs on latest version

Upgraded the Lifx beta to 2022.06.05 this morning and now getting the following errors, there were no issues reported in the logs on the previous version.
Detected blocking call to sleep inside the event loop. This is causing stability issues. Please report issue for rest doing blocking calls at homeassistant/components/rest/sensor.py, line 172: json_dict = json.loads(value)
Detected blocking call to sleep inside the event loop. This is causing stability issues. Please report issue to the custom component author for lifx doing blocking calls at custom_components/lifx/light.py, line 562: self.event = asyncio.Event()
Detected blocking call to sleep inside the event loop. This is causing stability issues. Please report issue to the custom component author for lifx doing blocking calls at custom_components/lifx/light.py, line 574: method(callb=self.callback)
Detected blocking call to sleep inside the event loop. This is causing stability issues. Please report issue for rest doing blocking calls at homeassistant/components/rest/sensor.py, line 160: value = json.dumps(xmltodict.parse(value))

That's weird. Those lines have been in the LIFX integration since way before I even started using Home Assistant. I'll have to configure a REST sensor and see if I can reproduce the issue.

Actually, no. I think I know what the problem is. I need to update the component from the changes I made to core anyway, which should fix this.

Ok cool, let me know once it's out and will give it a test. I've gone back to 2022.06.03 for the moment.

I've just pushed 2022.06.06 that contains the latest refactor. If this doesn't work, there must be something weird happening with the REST sensor and I'll have to try and reproduce that. I'm not getting any of those warnings on my test or production instances.

I've got that one installed now, so will give it a day and see what happens.

Back to this warning in the logs now:

Back to this warning now:

I've turned on debugging so will restart in a moment and collect some logs. If there is anything in particular you are looking out for, let me know.

The refactor should reduce the occurrence of that warning but it wasn't designed to eliminate it. The fact that there are 102 occurrences of this however indicates that something is wrong somewhere.
First, check the Home Assistant network configuration to ensure that it is configured correctly.
Otherwise, evaluate what's running on your network to determine if anything could be causing excessive network traffic: all direct communication with LIFX devices is done via UDP which means there is no IP session establishment and no network protocol level acknowledgement or retries.
I seem to recall that you might be using the Photons Interactor add-on: if that's correct, please try turning that off to see if it improves the stability of the integration. Older releases of Interactor were particularly aggressive about updating state information and would overwhelm most wifi networks with traffic.

The refactor should reduce the occurrence of that warning but it wasn't designed to eliminate it. The fact that there are 102 occurrences of this however indicates that something is wrong somewhere.
First, check the Home Assistant network configuration to ensure that it is configured correctly.

Its in Docker, so not much I can do in the way of config, it is setup as per guidelines.

I seem to recall that you might be using the Photons Interactor add-on: if that's correct, please try turning that off to see if it improves the stability of the integration. Older releases of Interactor were particularly aggressive about updating state information and would overwhelm most wifi networks with traffic.

Yer was going to, but didn't in the end, couldn't find any helpful documentation on it for docker in terms of actually interacting with it.
In terms of network congestion, possible, but hard to pin down without some logger in the middle of network, but can't say I've experienced any slow-downs or seeing any issues with other Wi-Fi connected devices and the bulbs and other things respond instantly.
All I can say is that this warning did not appear before 2022.5 and before this custom integration. So whether it was supressed or just didn't occur?!
Will see if the debug log comes up with anymore information.

The refactor should reduce the occurrence of that warning but it wasn't designed to eliminate it. The fact that there are 102 occurrences of this however indicates that something is wrong somewhere.
First, check the Home Assistant network configuration to ensure that it is configured correctly.

Its in Docker, so not much I can do in the way of config, it is setup as per guidelines.

I seem to recall that you might be using the Photons Interactor add-on: if that's correct, please try turning that off to see if it improves the stability of the integration. Older releases of Interactor were particularly aggressive about updating state information and would overwhelm most wifi networks with traffic.

Yer was going to, but didn't in the end, couldn't find any helpful documentation on it for docker in terms of actually interacting with it.
In terms of network congestion, possible, but hard to pin down without some logger in the middle of network, but can't say I've experienced any slow-downs or seeing any issues with other Wi-Fi connected devices and the bulbs and other things respond instantly.
All I can say is that this warning did not appear before 2022.5 and before this custom integration. So whether it was supressed or just didn't occur?!
Will see if the debug log comes up with anymore information.

The fact that it's in Docker means you need to check the network configuration because Docker has a tendency to break discovery and Home Assistant changed the way they handle networking recently. Please review the network configuration documentation and validate that your Docker configuration and Home Assistant agree on what the networking actually is.
If you're running Home Assistant OS on a Raspberry Pi, you should only be using one of the two network interfaces, preferably physical ethernet, unless you really know what you're doing and have segregated your IoT or Wifi network onto a different IP segment.

Its using network mode host as required per the documentation https://www.home-assistant.io/installation/linux
My WiFi and HA are on segregated LANs with firewall policies between the two as required, though HA as almost unrestricted access to IoT devices in that portion of the LAN. Each of these are on static IPs.
As a result Lifx lights are manually configured in a configuration file in HA with their static IP.
Perhaps not using the native discovery is throwing the error, when it shouldn't be attempting to discover them when I've manually listed them in the config?
That warning is probably because some bulbs are currently offline, and if that is the reason then that is fine, if you don't think it is, happy to continue investigating and providing logs.

Manually configuring LIFX bulbs doesn't actually disable discovery, it just restricts it to the specific IP addresses you've manually configured as broadcast targets. It's network trickery that works because UDP is a pretty basic protocol that has no concept of an actual broadcast address.
I'm pretty sure the manually configured offline bulbs are your problem here, but I'm not sure specifically why, because I've never manually configured my bulbs. It's easy enough to test: remove the manual configuration for the bulbs you know are offline and see if that resolves the issue.
In the meantime, I'm going to reproduce it here by manually configuring bulbs that just don't exist to see what the integration does.

I'm pretty sure the manually configured offline bulbs are your problem here

Turns out my assumption here is wrong, or at least, I can't reproduce the issue when I manually configure bulbs. Regardless of whether bulbs are discovered automatically or are manually configured, the integration only starts logging things after it connects to each bulb. If it never connects to a bulb, e.g. if the bulb is offline when HASS starts, then it just marks it unavailable.
Having said that, it will still attempt to discover all the bulbs every 10 seconds, which in the case of manual configuration is a UDP packet per entry as opposed to a UDP packet per network segment, but that's highly unlikely to be the cause of any network issues.
I am now really curious to see your debug logs.

Here is some
There is a whole bunch of the entity created ones after the
2022-06-13 13:14:41 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:2c:bb:30) 2022-06-13 13:14:41 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:44:5a:35) 2022-06-13 13:14:41 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:2c:3a:09) 2022-06-13 13:14:41 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:55:8f:75) 2022-06-13 13:14:41 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:55:5d:8e) 2022-06-13 13:14:41 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:27:56:fe) 2022-06-13 13:14:41 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:39:f3:89) 2022-06-13 13:14:41 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:29:77:15) 2022-06-13 13:14:41 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:27:b0:3f) 2022-06-13 13:14:41 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:27:77:ae) 2022-06-13 13:14:41 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:2c:9d:25) 2022-06-13 13:14:41 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:2f:37:ba) 2022-06-13 13:14:41 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:25:c1:1e) 2022-06-13 13:14:41 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:27:bc:1c) 2022-06-13 13:14:41 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:27:b0:b0) 2022-06-13 13:14:42 DEBUG (MainThread) [custom_components.lifx.light] Entity created for Back Door (d0:73:d5:6d:65:df) 2022-06-13 13:14:42 DEBUG (MainThread) [custom_components.lifx.light] Entity created for Lounge Lamp (d0:73:d5:39:f3:89) 2022-06-13 13:14:42 DEBUG (MainThread) [custom_components.lifx.light] Entity created for Stairs Top (d0:73:d5:55:8f:75) 2022-06-13 13:14:42 DEBUG (MainThread) [custom_components.lifx.light] Entity created for Lamp (d0:73:d5:55:90:ca) 2022-06-13 13:31:26 DEBUG (MainThread) [custom_components.lifx.light] First discovery response received from <IP_ADDRESS> (d0:73:d5:6b:a6:02) 2022-06-13 13:31:26 DEBUG (MainThread) [custom_components.lifx.light] Entity created for Toilet (d0:73:d5:6b:a6:02) 2022-06-13 13:33:13 WARNING (MainThread) [homeassistant.components.light] Updating lifx light took longer than the scheduled update interval 0:00:10 2022-06-13 13:33:13 WARNING (MainThread) [homeassistant.helpers.entity] Update of light.toilet is taking over 10 seconds 2022-06-13 13:33:33 WARNING (MainThread) [homeassistant.components.light] Updating lifx light took longer than the scheduled update interval 0:00:10 2022-06-13 13:33:33 WARNING (MainThread) [homeassistant.helpers.entity] Update of light.toilet is taking over 10 seconds 2022-06-13 13:33:53 WARNING (MainThread) [homeassistant.components.light] Updating lifx light took longer than the scheduled update interval 0:00:10 2022-06-13 13:33:53 WARNING (MainThread) [homeassistant.helpers.entity] Update of light.toilet is taking over 10 seconds 2022-06-13 13:34:13 WARNING (MainThread) [homeassistant.components.light] Updating lifx light took longer than the scheduled update interval 0:00:10 2022-06-13 13:34:13 WARNING (MainThread) [homeassistant.helpers.entity] Update of light.toilet is taking over 10 seconds 2022-06-13 13:34:31 DEBUG (MainThread) [custom_components.lifx.light] Disconnected from Toilet (d0:73:d5:6b:a6:02) 2022-06-13 13:34:33 WARNING (MainThread) [homeassistant.components.light] Updating lifx light took longer than the scheduled update interval 0:00:10

The integration is getting at least a discovery response and version response so it creates the entity, but then never gets a response to the request for current state so it disconnects from the bulb. Can you run this for a while and then review the logs to see if it's always the Toilet light or if other lights exhibit the same problem?
If it's just the Toilet light, would it be possible to move that particular bulb to a location closer to your wifi AP to see if it's a pure connectivity issue, i.e. if the wifi signal is low enough in that location that the bulb is having difficulty either receiving or sending packets.

2022-06-13 15:10:28 DEBUG (MainThread) [custom_components.lifx.light] Reconnected to Toilet (d0:73:d5:6b:a6:02)
Turning on the Toilet, it did connect, turning it off again, same info appears in the logs:
2022-06-13 15:12:14 WARNING (MainThread) [homeassistant.components.light] Updating lifx light took longer than the scheduled update interval 0:00:10 2022-06-13 15:12:14 WARNING (MainThread) [homeassistant.helpers.entity] Update of light.toilet is taking over 10 seconds
I did just also get a disconnect for the following bulb "hall":
2022-06-13 14:38:38 DEBUG (MainThread) [custom_components.lifx.light] Disconnected from Hall (d0:73:d5:2d:35:58)
Nothing in between that, and me power cycling it a few moments ago:
2022-06-13 15:09:43 DEBUG (MainThread) [custom_components.lifx.light] Reconnected to Hall (d0:73:d5:2d:35:58)
Not sure why HA is complaining about the Toilet bulb so often, given the bathroom, and 4 other lights are currently off right now as well. Bathroom and Toilet are both Clean bulbs and don't constantly have power.
Additionally HA got discconected from the Hall (no idea why, Lifx couldnt connect either), but it doesn't complain in the logs it was unresponsive.

If you power off a bulb after Home Assistant has discovered it, then this is expected. Home Assistant will continue to try and get status from the bulb every 10 seconds until the underlying library flags it as disconnected which happens 90 seconds after the last packet was received.
Once flagged as disconnected/unavailable, Home Assistant will stop attempting to update a bulb's status until it becomes available, which will only happen if/when the bulb is successfully rediscovered. Given your manual configuration, this should happen within 10 seconds of the bulb connecting to your wifi network.
Your first log output shows Home Assistant disconnecting from the Toilet bulb, which is expected if it got powered off. If it was still off when you power cycled Home Assistant, it wouldn't have been discovered at all, so you'd get no log entries until it powers on again.
For your use case, I would consider it "working as expected" if Home Assistant discovers a bulb within 20 seconds of it powering on and if Home Assistant marks a bulb unavailable within 100 seconds of it powering off.

Fair enough, then yer seems to be working as expected, least you got some test logs out of it and could test an edge case.
Appreciate the help, and I will just ignore the logs knowing that it is expected behaviour.

Last note: disable debug logging. :) I'd also be curious to know if removing the manual configuration makes things faster or slower for discovery and disconnection.


Offset Issue with items in ItemsRepeater inside a ScrollViewer when modifying Visibility

Describe the bug
So this is a bit of a convoluted one, but the gist of it is the following:
If you have an ItemsRepater contained within a ScrollViewer, with enough items in the repeater that the ScrollViewer can be scrolled. If you then modify the Visibility of the items, you can end up with items being offset outside the visible area of the ItemsRepeater/ScrollViewer
As an example
This is how things should work:

Clicking the respective buttons modifies the Visibility of the items in the ItemsRepeater.
However, if you have scrolled a little and try to do the same, then this will happen:

Now the orangutang appears to be gone, but it is only offset:

The blue square under ItemsRepeater is the actual Item. So it is there, and seemingly Visible, but offset so far that it cannot be seen.
It seems this will only happen when collapsing the later items in the collection. Also if there are so many items being made visible that the ScrollViewer can scroll then this will happen:

Here the first item is offset at first, but once we scroll it snaps back into the correct position.
Steps to reproduce the bug

Created an empty project, and added a page that I navigate to from the MainWindow.
The rest is pretty straight forward. The important bits is to have an ItemsRepeater with enough items that the ScrollViewer Containing it will be activated. And then a way to modify visibility.

Here's the code I had for page I used to make the images with:
MainPage.idl
namespace ScrollViewerAndItemsRepeaterIssue
{
    [default_interface]
    runtimeclass MainPage : Microsoft.UI.Xaml.Controls.Page
    {
        MainPage();
        Windows.Foundation.Collections.IObservableVector<String> Items{ get; };
    }
}

MainPage.xaml
<?xml version="1.0" encoding="utf-8"?>
<Page
    x:Class="ScrollViewerAndItemsRepeaterIssue.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:ScrollViewerAndItemsRepeaterIssue"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d" Background="Aquamarine">

    <Page.Resources>
        <ResourceDictionary>
            <StackLayout x:Name="HorizontalStackLayout" Orientation="Horizontal" Spacing="0"/>
            <NonVirtualizingLayout x:Name="nvl" ></NonVirtualizingLayout>

            <DataTemplate x:Key="ItemTemplate" x:DataType="x:String">
                <Border Background="Red" BorderBrush="Black" BorderThickness="1" Width="64" Height="64">
                    <TextBlock FontSize="38" HorizontalAlignment="Center" VerticalAlignment="Center" Text="{x:Bind}"></TextBlock>
                </Border>
            </DataTemplate>

        </ResourceDictionary>
    </Page.Resources>

    <StackPanel HorizontalAlignment="Center" VerticalAlignment="Center">
        <ScrollViewer x:Name="Scroller" Height="64" Width="300" Background="Green" HorizontalScrollMode="Enabled" HorizontalScrollBarVisibility="Visible">
            <ItemsRepeater x:Name="Repeater" Layout="{StaticResource HorizontalStackLayout}" ItemsSource="{x:Bind Items}" ItemTemplate="{StaticResource ItemTemplate}"/>
        </ScrollViewer>
        <StackPanel Orientation="Horizontal" HorizontalAlignment="Center">
            <Button Tag="orangutang" Click="Button_Click">Show only 🍌</Button>
            <Button Tag="banana" Click="Button_Click">Show only 🦧</Button>
        </StackPanel>
    </StackPanel>
</Page>

MainPage.xaml.h
#pragma once

#include "MainPage.g.h"

namespace winrt::ScrollViewerAndItemsRepeaterIssue::implementation
{
    struct MainPage : MainPageT<MainPage>
    {
        MainPage();

        void FilterOutBanana();
        void FilterOutOrangutang();
        void Button_Click(winrt::Windows::Foundation::IInspectable const& sender, winrt::Microsoft::UI::Xaml::RoutedEventArgs const& e);

        winrt::Windows::Foundation::Collections::IObservableVector<hstring> Items();
        winrt::Windows::Foundation::Collections::IObservableVector<hstring> m_Items;
    };
}

namespace winrt::ScrollViewerAndItemsRepeaterIssue::factory_implementation
{
    struct MainPage : MainPageT<MainPage, implementation::MainPage>{};
}

MainPage.xaml.cpp
#include "pch.h"
#include "MainPage.xaml.h"
#if __has_include("MainPage.g.cpp")
#include "MainPage.g.cpp"
#endif

using namespace winrt;
using namespace Microsoft::UI::Xaml;
using namespace Windows::Foundation;

namespace winrt::ScrollViewerAndItemsRepeaterIssue::implementation
{
    MainPage::MainPage()
    {
        m_Items = winrt::single_threaded_observable_vector<hstring>();

        m_Items.Append(L"🦧");
        m_Items.Append(L"🍌");
        m_Items.Append(L"🍌");
        m_Items.Append(L"🍌");
        m_Items.Append(L"🍌");
        m_Items.Append(L"🍌");
    }

    winrt::Windows::Foundation::Collections::IObservableVector<hstring> MainPage::Items()
    {
        return m_Items;
    }

    void MainPage::Button_Click(IInspectable const& sender, RoutedEventArgs const& e)
    {
        auto toFilterOut = winrt::unbox_value<hstring>(sender.as<Controls::Button>().Tag());
        if (toFilterOut == L"orangutang")
        {
            FilterOutOrangutang();
        }
        else if (toFilterOut == L"banana")
        {
            FilterOutBanana();
        }
    }

    void MainPage::FilterOutBanana()
    {
        for (uint32_t i = 0; i < m_Items.Size(); i++)
        {
            auto element = Repeater().TryGetElement(i);
            if (i == 0)
            {
                element.Visibility(Visibility::Visible);
            }
            else
            {
                element.Visibility(Visibility::Collapsed);
            }
        }
    }

    void MainPage::FilterOutOrangutang()
    {
        for (uint32_t i = 0; i < m_Items.Size(); i++)
        {
            auto element = Repeater().TryGetElement(i);
            if (i == 0)
            {
                element.Visibility(Visibility::Collapsed);
            }
            else
            {
                element.Visibility(Visibility::Visible);
            }
        }
    }
}

Expected behavior
The Item not to be offset out of view.
Screenshots
No response
NuGet package version
WinUI 3 - Windows App SDK 1.5.4: 1.5.240607001
Windows version
Windows 11 (22H2): Build 22621
Additional context
No response

Thanks for your report torleifat. Each ItemsRepeater Layout subclass supports Collapsed elements more or less.
In general, collapsing ItemsRepeater children is really not recommended, in particular not for virtualizing layouts. We do not explicitly prevent it at the ItemsRepeater level because it's really a Layout-specific concern.
For example, consider the UniformGridLayout. It uses the first child to determine the children size in general. If it's collapsed, no element will show up (you can give it a try to see that).
As for the StackLayout layout that you are using, it uses the realized items sizes to predict the overall collection extent. If some of those are collapsed, that prediction is poor.
Anyways, because of the virtualization of the items, items get recycled as the users scrolls the content. If an element was collapsed, as it gets recycled and used for another index, it will remain collapsed. This is wrong, and it's an application code problem. The app needs to keep track of which elements are supposed to be collapsed and which are not.
Here's an example in C#:
public sealed partial class TestPage : Page
{
    private List<int> _collapsedIndices = new List<int>();
    private ObservableCollection<string> _colStrings = null;

    public TestPage()
    {
        this.InitializeComponent();

        if (itemsRepeater != null)
        {
            itemsRepeater.ElementPrepared += ItemsRepeater_ElementPrepared;

            _colStrings = new ObservableCollection<string>();

            for (int itemIndex = 0; itemIndex < 200; itemIndex++)
                _colStrings.Add("Item" + itemIndex);

            itemsRepeater.ItemsSource = _colStrings;
        }
    }

    private void BtnChangeEvenItemsVisibility_Click(object sender, RoutedEventArgs e)
    {
            if (itemsRepeater != null && _colStrings != null)
            {
                Visibility newVisibility = Visibility.Collapsed;

                if (btnChangeEvenItemsVisibility.Content as string == "Collapse even items")
                {
                    btnChangeEvenItemsVisibility.Content = "Show even items";
                }
                else
                {
                    btnChangeEvenItemsVisibility.Content = "Collapse even items";
                    newVisibility = Visibility.Visible;
                }

                for (int i = 0; i < (_colStrings.Count + 1) / 2; i++)
                {
                    UIElement element = itemsRepeater.TryGetElement(2 * i);
                    if (element != null)
                    {
                        element.Visibility = newVisibility;

                        if (newVisibility == Visibility.Visible)
                        {
                            if (_collapsedIndices.Contains(2 * i))
                            {
                                _collapsedIndices.Remove(2 * i);
                            }
                        }
                        else
                        {
                            if (!_collapsedIndices.Contains(2 * i))
                            {
                                _collapsedIndices.Add(2 * i);
                            }
                        }
                    }
                }
            }
    }

    private void BtnChangeOddItemsVisibility_Click(object sender, RoutedEventArgs e)
    {
            if (itemsRepeater != null && _colStrings != null)
            {
                Visibility newVisibility = Visibility.Collapsed;

                if (btnChangeOddItemsVisibility.Content as string == "Collapse odd items")
                {
                    btnChangeOddItemsVisibility.Content = "Show odd items";
                }
                else
                {
                    btnChangeOddItemsVisibility.Content = "Collapse odd items";
                    newVisibility = Visibility.Visible;
                }

                for (int i = 0; i < _colStrings.Count / 2; i++)
                {
                    UIElement element = itemsRepeater.TryGetElement(2 * i + 1);
                    if (element != null)
                    {
                        element.Visibility = newVisibility;

                        if (newVisibility == Visibility.Visible)
                        {
                            if (_collapsedIndices.Contains(2 * i + 1))
                            {
                                _collapsedIndices.Remove(2 * i + 1);
                            }
                        }
                        else
                        {
                            if (!_collapsedIndices.Contains(2 * i + 1))
                            {
                                _collapsedIndices.Add(2 * i + 1);
                            }
                        }
                    }
                }
            }
    }

    private void ItemsRepeater_ElementPrepared(ItemsRepeater sender, ItemsRepeaterElementPreparedEventArgs args)
    {
        if (_collapsedIndices.Contains(args.Index))
        {
            if (args.Element.Visibility == Visibility.Visible)
                args.Element.Visibility = Visibility.Collapsed;
        }
        else if (args.Element.Visibility == Visibility.Collapsed)
                args.Element.Visibility = Visibility.Visible;
    }
}

The key points are:

the app keeps track of the collapsed indices in _collapsedIndices.
when an old element is re-used, the ItemsRepeater_ElementPrepared event handler makes sure that it has the correct Visibility.

But there is a preferred way of handling items that should have no UI representation: filter the ItemsRepeater.ItemsSource collection by removing from it the indexes that you wanted collapsed. Make it an observable collection of course, so that the ItemsRepeater becomes aware of the source changes. That's the proper way of doing it. Hope this helps. Thanks.

Thanks for the insight, RBrid. Appreciate it!


Cai mock data generator

Resolves #3036

@joecheuk for which milestone is this being targeted?

@joecheuk for which milestone is this being targeted?

2.21 is the current target (unless 2.20 is being pushed out).

@joecheuk Should we close this out since this is going into it's own repo?

@gkowalski-google sounds good, closed.


[port download failure] openvino

Missing hashes identified for port openvino
Build: https://github.com/danieljurek/vcpkg-cache-builder/actions/runs/7380927050

[!NOTE]
This list is updated by automation and may change as assets cycle out

ee9439e0804bacd365f079cedc548ffe2c12b0d4a86780e0783186884eb5a6d7aa7ceac11c504e242bedc55c3d026b826c90adaafbdbd3e5cfa2562a1c4ee04d

To fix:

If the SHA is not valid or the port has build problems

Add to ignore-ports.txt or ignore-hashes.txt

Ensure that the port downlaods successful which might include...

Ensuring that a required triplet is present (easiest)
Building the port to download the asset (needs build infrastructure)
Ensure features are properly configured

This hash is not listed in the current version of vcpkg. Closing.


VULCAN-133/Adding a legend button for relationships and nodes

Added a legend button that can be configured such in the dashboard JSON:
"settings": {
"minimizable": "on",
"nodePositions": {},
"nodeLabelFontSize": 3,
"relLabelFontSize": 2,
"backgroundColor": "#ffffff",
"hideSelections": true,
"refreshButtonEnabled": true,
"fullscreenEnabled": true,
"downloadImageEnabled": true,
"legendDefinition": [
{
"enabled": true,
"entries": [
{
"type": "node",
"color": "#EFE289",
"meaning": "SW version",
"textColor": "#000000"
},
{
"type": "edge",
"color": "#4caf50",
"meaning": "HW version",
"textColor": "#000000"
}
]
}
],
The program was tested solely for our own use cases, which might differ from yours.
Brahm Prakash Mishra<EMAIL_ADDRESS>on behalf of Mercedes-Benz Research and Development India.

Provider Information

This PR needs to be merged before all my other PRs (identifiable with the VULCAN prefix) -> since these changes are reflecting in all of them


Facebook check fails

When I try posting a public verification i get: Error 500. Something is not right. We will look into it.
The post is still published and is public. Tried both command line verifications (curl and keybase), and I got the same error in all of them. I don't know what i could have done wrong.

Duplicate of #14537


Update icon to macOS 11 style

Way back in #1, I submitted the currently used app icon for the then-new Yosemite version of OS X. The new icon styling for Big Sur is a pretty big departure from the current styling and it makes sense to have MacVim continue to feel current going forward (once macOS 11 ships).
This PR includes a new MacVim.icns that looks like this:
Option 1

I didn't include any document-specific .icns files because I read the following on this page, but I'm happy to help generate them if I'm misinterpreting.

To compose a document icon, the system combines your app icon with the familiar folded-corner icon shape.

Here's an alternative version that aligns with the original icon better.

Thanks for the update! Between the original and alt version is there one you prefer?
I appreciate the update but I may let this sit a little bit when macOS 11 Big Sur is still in beta to see if others have opinions and let me take a look at Apple's guidelines in the meantime.

Sounds good @ychin. I think it makes sense to gather more feedback during the Bir Sur beta period so that everyone feels confident by the time the macOS 11 ships.
I initially liked the first version better, but after refining the second version more I prefer that one. Since it stays more true to the original Vim logo, that's probably the more sensible (and least controversial) direction.

Just some immediate feedback / thoughts: I like option 1 better. The second option aligns better with the original Vim logo but it looks… kind of off? Like we just introduced a white squircle border for no good reason with yet another solid color border inside it. It in a way reminds me of Vim in that we pile on new features but trying to keep backwards compatibility at all cost, but seems like at first glance at least the first icon seems cleaner.
The other thing that jumped at me was how strong the 3D shading shadow is. The drop shadow is fine, but the "V" almost feels too… 3D to me. I'm still not sure if I'm put off by it itself or just the new Big Sur aesthetics, and I'm going through the list of icons and the official recommendation to see how this fits in, and so far it seems… inconclusive to me and seems like some icons have this strong 3D shading effect (e.g. Messages, App Store) while others still look flat with a squircle around the icon (e.g. Apple TV, Apple Music). So I'm not sure yet.
Maybe will need to wait till I get a beta version installed and can try them side-by-side.

Here's another variant on the first option, but with the shading dialed way down.
Option 3

I perfect the most Option 2. I like that macOS is going back to 3d effects in icons

Option 4

👍  for Option 2 but with the shading dialed way down == Option 4 with white background color.

Sorry for the delay - I was on vacation last week.
Option 5

Hi, @jasonlong , do you mind if you could provide all the different options' icn files? I am trying to look at them in Big Sur beta just to be able to tell how they look like relative to the other icons, and it would be easier if you could provide the icns either in individual commits or just another way to attach them. Thanks!

Just pinging again. @jasonlong , do you mind providing the different options as icn files?  I would like to try them out in macOS 11 beta to see what they look like if possible.

@ychin Sorry for the delay. Here's a link to the different .icns options:
https://macvim-icns-riselanjk.vercel.app/

Just trying out to see how the 5 options look relative to the other icons in the Big Sur beta:
Option 1:

Option 2:

Option 3:

Option 4:

Option 5:

After seeing it side-by-side, I think I'm still not a huge fan of Option 5 (even though it seems to be popular with the limited voting we have). In particular, most default icons seems to have a simple "background color + thing in the middle" design, where as Option 2/5 is a thing within a thing within a thing. But I feel like Option 5 looks a little better in the 2nd screenshot (next to the Home app) compared to the first one.
I think Option 3 remains my favorite, whereas I think Option 4 really doesn't stand a chance.
Also, Apple seems to not be terribly consistent in their 3D shading effect. App Store / Messages' icons use a fairly strong shading effect, but Music / News look pretty flat. The official HIG guidelines only suggests using it so 🤷 .
@jasonlong what do you think? Which one do you personally think look the best?

Going to do a second round of voting below. Feel free to both vote up or down on more than one icon! Kind of doing a poor-man's approval/ranked voting this way.

Vote Option 1:

Vote option 2

Vote Option 3

Vote Option 4

Vote Option 5

Thanks for putting these comparisons together @ychin.

Apple seems to not be terribly consistent in their 3D shading effect.

Agreed, this has made these explorations challenging trying to align the treatment w/ the default icons.

I think Option 3 remains my favorite

Seeing them all in context, I tend to agree with you. Sometimes I feel like that one is too flat, but I feel like that one looks better than the really shaded Option 1. If we want to try some shading options in-between, I'm happy to build some.

The V a little further to the right?

@ychin With Big Sur out, can I help at all getting the icon update ready to ship? I can update this PR to use Option 3 above if you like.

@jasonlong Yes please update to Option 3. I was a little busy with work and got a little behind on making sure MacVim is ready for Big Sur!
Just to make sure https://github.com/macvim-dev/macvim/pull/1054#issuecomment-703696158 is addressed. I personally think the alignment in the original Option 3 looks fine, but it's because of how the "V" looks in the font that it looks a little offset to the left. I think it's fine to leave it as is, but if you want to shift it to the right I'm fine with that too.

Ok, the branch has been updated here and I tried to better optically center the mark in the container. The final version looks like this:

Merged! Thanks for the update.

I know this issue is closed, but I'd like to suggest something like the "overhang" versions proposed for VS Code in this comment, maybe with the bottom and/or the right tip of the V sticking out a bit from the squircle.
Sadly I don't have the design skills to mock that up. Would anyone care to take a shot at it?

Hi, I appreciate the comment but I'm not sure I'm buying the overhang design. Also, the Vim's "V" has always been level at the top, so to make it overhang you would have to change the iconography of it as well to have some part poke out. I think the overhang is usually designed for an object laid on top of the squircle, not for a letter (https://developer.apple.com/design/human-interface-guidelines/macos/icons-and-images/app-icon).
If you have more thoughts though feel free to discuss at https://github.com/macvim-dev/macvim/discussions/1140 since people love to discuss design changes :) .

Ps: the default icon is highly new for me and an icon in docker looks very different than on a GitHub page.
I love the diamond was before and new icon looks flat to me.
Is it possible in macOS to change an icon from app settings like I can do it in iOS?
If yes, is it possible to add all icons and let user decide which icon to show? I somewhat want an option, to decide.

@eirnym See the discussion on https://github.com/macvim-dev/macvim/discussions/1140 (we should focus on using that thread to discuss icon change). No, macOS doesn't allow for multiple icons for an app so it has to be one. You could change it yourself in Finder and the OS will remember it, but we don't have a way for MacVim to bundle multiple icons and let you choose, unfortunately.
With most things icon or interface change related, I think it takes time to adapt. I'm open to see how the new icon is received in a couple more weeks at least to see if people got used to it.

@ychin Thank you for a link and an information. Here I wanted to ask a technical question, not discuss my personal preferences, and you gave me a good answer.

For anyone arriving in this thread wanting to say that they hate the new icon
I hated it 24 hours ago, but now? Looks fine. Whatever. Just give it a few days.

For anyone arriving in this thread wanting to say that they hate the new icon
I hated it 24 hours ago, but now? Looks fine. Whatever. Just give it a few days.

@ychin  I use brew to install macvim.  (as a formula in HomeBrew parlance/terminology) with brew install macvim
(and update to the last version with brew upgrade macvim )
Here I won't discuss homebrew's merit.
I just wanted to point out that it may be possible to have an option in brew to get alternate icons as I believe have seen this for another app in brew... (can't  remember which) This could be a workaround to MacOS 11 BigSur limitations ?
I'll try to get some time to investigate this (as I am not a brew wizard)

@ychin  I use brew to install macvim.  (as a formula in HomeBrew parlance/terminology) with brew install macvim
(and update to the last version with brew upgrade macvim )
Here I won't discuss homebrew's merit.
I just wanted to point out that it may be possible to have an option in brew to get alternate icons as I believe have seen this for another app in brew... (can't  remember which) This could be a workaround to MacOS 11 BigSur limitations ?
I'll try to get some time to investigate this (as I am not a brew wizard)

Homebrew doesn't build from source by default. It builds a default bottle that you download from their server, so this would only be an option if you build MacVim from source using Homebrew, and I think that's just too niche an option.

@ychin this option exists in MacPorts and I'd like to see it. In home-brew it was cutoff as they have a policy to support only one configuration.
PS: I have questions on MacVim to provide better support in MacPorts

What would MacVim need to do to support MacPorts better? I used to use MacPorts but moved away from it, and it seems like MacPorts usually falls behind MacVim releases by a couple versions (https://ports.macports.org/port/MacVim/summary). Looking at metrics on that (which to be fair I don't know how accurate that i), it also appears the usage is quite low, which is why I'm not sure if I want to spend too much time supporting it (homebrew-core's MacVim formula is maintained by Homebrew themselves).
Anyway let's make a new issue if you want to add more support for MacPorts, which I'm not against. I do question if it's worth spending effort to make the icon customizable just for MacPorts though. It's a pretty niche within niche use case.

I want to take maintainership of MacVim in MacPorts

macvim-dev doesn't own the MacPorts definition. You may want to go to https://ports.macports.org/port/MacVim/summary and ask the maintainer instead.
FWIW I don't particular support having customizable icons for the reasons I already discussed (majority of users would not be installing MacVim in a way that supports icon customization, and also I don't really think that's good for help identifying the app if we give too many icons to choose from).

"it seems like MacPorts usually falls behind MacVim releases by a couple versions"
maybe that explains why I just recently got the new icon...
I'm not sure why a new icon was needed, but now it looks imho totally out of place with the Vim icons on my other computers. It hardly looks like Vim at all, really. Where did the "im" go? Was that really needed to drop it?

@oseiberts11 The "im" has been part of the MacVim logo for a long time (at least 6 years).

Interesting, you're right! I guess that the change somehow made it more "in my face" :)

Also, are you using macOS 11 Big Sur @oseiberts11 ? If you are, I would be surprised if you find the old icon preferable to the new one. If you aren't, unfortunately, as been discussed on this thread already, there isn't an easy way to support multiple icons, and as a project we should be supporting the latest macOS versions as top priority while remaining backwards compatible with older versions.

@ychin No, I don't (yet). Company policy has not approved it yet, I think... So this is on my work computer, that's why I notice that the icon differs so much from other Vim versions, because for my personal use I use the generic Unix version of Vim with GTK GUI.


printing all of the active tile layers

I have a map with one background layer and some wms layers. it prints only one of the tile layers(the last one that added to the map)... is there any way to get all of the tile layers when printing?
thanks

Hello,
You have one base tiles layer and a few images over the map that you want to print? Can you create an example (jsbin/codepen or any other) to show your use case and recreate issue?
Regards,
Igor

I've added some improvements, not sure if they will help. Please check the latest version and let me know if it works for you or not. And if not - please provide an example to reproduce and understand the issue.

thanks. I checked the latest version but still I have this problem...
I created an example here: https://jsfiddle.net/fatemi994/2s05gwxz/

I see. Thanks. It should be fixed right now. Please check next version 0.5.13
Also, Auto printing will not work with WSM layers, will need to think about this problem later.


open-cluster-management/backlog#3613 Desc rev

Description review

you will need to run make update before submit the pr

Redone in a collective PR, #66 .


Type dropdown box on advanced search contains SO / SBO identifiers

E.g., http://identifiers.org/biomodels.sbo/SBO:0000169 is not meaningful without going to an external resource (versus, e.g., 'inhibition').

ontology issue duplicate, closing


Publish changes for external_report_url from External Activities

When a LARA author publishes an activity or sequence to the portal, if the activity or sequence has an external report URL, the portal setting for the external report for that activity/sequence is set using the external report URL from the LARA activity/sequence.
see this PT story for more details.

@dougmartin maybe you can take a look while  @scytacki  is away?  Please DONT merge the PR though.

Other than the (possibly dumb) question about using find_by_url shown above it looks good to me :+1:

👍


permission denied

go get github.com/pilu/fresh: open /usr/local/go/bin/fresh: permission denied

Try agaibn with sudo
sudo go get github.com/pilu/fresh


Fix background color in dark mode

Fixed background color in dark mode.
Motivation:
I use chrome with dark mode. Background color and text in dev tools is white, so i cant see frame content:

Modifications:
Added one css line.
Result:

Hey, @dakr0013! The new version should be available in the extension store now.


when I open VScode，shows that NuTCRACKER fatal error：Failed to register with service. Make sure that service is running

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version:1.67
OS Version:

Steps to Reproduce:

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.67.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

VS Code doesn't have anything to do with "NuTCRACKER", I'd suggest reaching out to your admin or investigating issues with that software yourself if you're not on a work machine.


TextToSpeech - JavaScript Samples - Include enumerating available languages/voices

Is your feature request related to a problem? Please describe.
I am not finding a way to enumerate available languages/voices for speech synthesis with the JavaScript SDK, and it doesn't appear to be covered in the sample.  In C#, it's on the SpeechSynthesizer class ("GetVoicesAsync" -- https://docs.microsoft.com/en-us/dotnet/api/microsoft.cognitiveservices.speech.speechsynthesizer?view=azure-dotnet) but I don't see an equivalent in JavaScript (https://docs.microsoft.com/en-us/javascript/api/microsoft-cognitiveservices-speech-sdk/speechsynthesizer?view=azure-node-latest).
Describe the solution you'd like
If there is a way to do this it would be great if you could add it to the sample.  If there is no way to do it my request is that this functionality be added to the JavaScript SDK for parity with the C# API (and also something I would expect for API completeness -- hopefully it's already there and I'm just missing it).
Describe alternatives you've considered

One alternative is to hard-code the list from https://docs.microsoft.com/en-us/azure/cognitive-services/speech-service/language-support which seems less than ideal.
The other option is to use the C# API, but I am calling this from a Blazor Webassembly project and using the C# SDK in that scenario is currently broken (see #903).  I prefer this option but can't use it.

Additional context
I have also submitted a question on the forum (https://docs.microsoft.com/en-us/answers/questions/663637/how-to-enumerate-voices-in-azure-text-to-speech-in.html) but this approach was not fruitful the last time I asked a question about the JavaScript SDK.  They just pointed me to the sample here where my question was also not answered.

GetVoicesAsync is a gap between the C# and JS implementations. @glharper and I discussed this today and this is going to go into his backlog of tasks.
In the meantime, there is a REST API that will return the supported language list. It's documented here.

hi @mkb13 , were you able to use the workaround suggested by @rhurey?. We have internally a work item to add this feature to JS so you should be able to see it in a later version.

hi @mkb13 , were you able to use the workaround suggested by @rhurey?. We have internally a work item to add this feature to JS so you should be able to see it in a later version.

Thanks to both, yes, it worked.  Thanks for considering adding it to JS.

Closing the issue since GetVoicesAsync API has been added.

From the 1.20 release notes:
JavaScript: Added getVoicesAsync() API to SpeechSynthesizer to retrieve the list of supported synthesis voices (GitHub issue 1350)


support FreeBSD 11-RELEASE

ruby-build fails when I use on FreeBSD 11-RELEASE.
$ rbenv install 2.3.1
Downloading ruby-2.3.1.tar.bz2...
-> https://cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.1.tar.bz2
Installing ruby-2.3.1...

BUILD FAILED (FreeBSD 11.0-RELEASE-p2 using ruby-build 20160913-13-g8ef0c34)

Inspect or clean up the working tree at /tmp/ruby-build.20161104153337.41276
Results logged to /tmp/ruby-build.20161104153337.41276.log

Last 10 log lines:
                              rake 10.4.2
installing rdoc:              /home/yuichiro/.rbenv/versions/2.3.1/share/ri/2.3.0/system
installing capi-docs:         /home/yuichiro/.rbenv/versions/2.3.1/share/doc/ruby
The Ruby readline extension was not compiled.
ERROR: Ruby install aborted due to missing extensions
Configure options used:
  --prefix=/home/yuichiro-n/.rbenv/versions/2.3.1
  CFLAGS= -O3 -Wno-error=shorten-64-to-32
  LDFLAGS=-L/home/yuichiro-n/.rbenv/versions/2.3.1/lib
  CPPFLAGS=-I/home/yuichiro-n/.rbenv/versions/2.3.1/include

The reason of this error,
FreeBSD 11-RELEASE has changed not to export readline shared library.
Application should use readline library in Ports Collection.
c.f.
https://www.freebsd.org/releases/11.0R/relnotes.html
In FreeBSD Ports Collection,
ruby interpreter compiled with libedit by default.
To follow this configuration,
this patch prefers to link libedit first, readline next.

Thank you. We need to add --with-openssl-dir option as same reason.
And We're investigate this issue on ruby core side.

Do you like to use openssl library from Ports Collection ?
Have a look at my second patch.

Seems good.
Sorry, my information is not enough. I pointed out https://bugs.ruby-lang.org/issues/12849 and https://github.com/rbenv/ruby-build/issues/1009

Our CI is fragile status. I will merge when it fixed. Maybe It caused Travis boxes.

I'm sorry that my response is late.
I'm not familiar with Travis ci.
My last commit fixed all test cases have been passed.
Will you check the test code?

I found older ruby (before 2.1) needs readline library.
So I fixed to use readline first, libedit second.
Latter ruby (not before 2.1) works with readline, too.
This fix has no problem for most of ruby versions.
Will you check the latest code?

Thank you! 🙇


WebP Quality Option

This pull request adds support for a quality setting in WebP, which is based on the existing solutions for JPEG and PNG.
Since this feature does not touch the default value (-q 80) this should not break anything.

Thanks!


Add input pre-process support by Scale, Mean, and Std Dev to enable c…

…orrect output predicitons for specific CV models (e.g. densenet121, resnet50).

Initially implemented as a command-line argument to WinMLRunner, so that it can be used with existing opset 7 and opset 8 ONNX models.  Please review / discuss.

Hey Paul! Can we have a test for your change? Your earlier comment said that this change gives correct outputs for CV models like DenseNet121, Resnet50. How about Squeezenet? How can we see the range that the model expects? (0,255)? (-1,1)?

Would need to verify the output result is correct.  SqueezeNet actually requires 0-255 input, so that is operating correctly, and scaling the input will actually cause incorrect results.  I was trying to determine a good way to verify that the predicted result is correct, but am not seeing a great way to do it in the currrent test code (just checking for error messages).  Welcoming any suggestions here.
Since the only models that I've immediately found are DenseNet and ResNet50, should one of them be added to the repo so they can be used to test as well?  DenseNet is a little smaller, but ResNet50 seems to be much more relevant.

One more thing... going back to Paul's comment earlier... this information really should be embedded in the model in the long term.  If an Opset 7 model could contain the scale and meadStdDev information, that would be ideal.  This would only be a workaround for models that don't have the info available on hand.

      Would need to verify the output result is correct.  SqueezeNet actually requires 0-255 input, so that is operating correctly, and scaling the input will actually cause incorrect results.  I was trying to determine a good way to verify that the predicted result is correct, but am not seeing a great way to do it in the currrent test code (just checking for error messages).  Welcoming any suggestions here.

Since the only models that I've immediately found are DenseNet and ResNet50, should one of them be added to the repo so they can be used to test as well?  DenseNet is a little smaller, but ResNet50 seems to be much more relevant.

Hey Paul, how are you able to determine what kind of inputs that the model expects? Does Netron give you this information? Do you get this information from documentation about the model?

I've also known unit tests that were able to snoop specific values in buffers / memory... will this test environment support that?  Or is WinMLRunner dependent on the return value of the exe?

Would need to verify the output result is correct. SqueezeNet actually requires 0-255 input, so that is operating correctly, and scaling the input will actually cause incorrect results. I was trying to determine a good way to verify that the predicted result is correct, but am not seeing a great way to do it in the currrent test code (just checking for error messages). Welcoming any suggestions here.
Since the only models that I've immediately found are DenseNet and ResNet50, should one of them be added to the repo so they can be used to test as well? DenseNet is a little smaller, but ResNet50 seems to be much more relevant.

For checking the output result. You can compare the output SoftwareBitmap with the expected SoftwareBitmap(created from ground truth image) byte by byte. And if the error rate is low enough, you can say the output result is correct.

Updated per all suggested changes, and has passing unit tests.  Ready for code review / next steps.

Closing because this PR is now stale. https://github.com/microsoft/Windows-Machine-Learning/pull/223 is used to track the on client tensorize change.


Using -var inline is not supported

Used Extension : Terraform Build & Release Tasks Charles Zipp
Problem:
We cannot use the -var to set variables inline during plan and apply, this is because by default the input=false is added to the command. Why this limitation ??

@SamirFarhat
The input option controls whether or not the command line prompts users to input variables that were not provided with the initial apply/plan command. It does not cause it to ignore -var arguments.

https://www.terraform.io/docs/commands/apply.html
This input=false setting was deliberate to prevent builds/releases from running indefinitely. If terraform asked for a var input during the context of a build/release, the user would not be able to provide such input. Thereofore the build would be hung indefinitely.
Can you please post your task setup and any errors you may be getting when running your pipeline? I suspect the issue you are having has a different root cause.


Use pkg/errors for error handling

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/40819922-use-pkg-errors-for-error-handling?utm_campaign=plugin&utm_content=tracker%2F34898442&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F34898442&utm_medium=issues&utm_source=github).

Skip that, it prints out too much!


[Bug]: I still have 2 different gamerules of Leading Light that were used in SS2

What happened?

Self explanatory. I'm apparently the only one with this too.
Platform
Epic Games

Email me the data.db file.

File is too big. Add me on Discord : taupe. / Taupe#0069 so i can share it to you

Upload the file here and email me the link.

@qutrits They're probably this round id. Could you add this to UpdateDatabaseVersion?

round_follow-the-leader_ss2_launch
round_follow-the-leader_ss2_parrot

Fixed now


vundle test minirc.vim causing errors when running vim from git bash

Environment
Windows 10, Git Bash
My _vimrc
set encoding=utf-8
set fileencoding=utf-8
set nocompatible
syntax enable
filetype plugin on
set path+=**
set wildmenu
imap <F3> <C-R>=strftime("%Y-%m-%d %H:%M")<CR>
command! MakeTags !ctags -R .
let g:netrw_banner=0		" disable banner
let g:netrw_browse_split=4	" open in prior window
let g:netrw_altv=1		" open splits to the right
let g:netrw_liststyle=3		" tree view
let g:netrw_list_hide=netrw_gitignore#Hide()

My _gvimrc
set guifont=Consolas:h10
set guifontwide=MingLiU:h10
set background=dark
filetype off                  " required
set rtp+=~\.vim\bundle\Vundle.vim " set rtp+=~\vimfiles\bundle\Vundle.vim
call vundle#begin('~\.vim\plugin') " call vundle#begin('~\vimfiles\plugin')
Plugin 'VundleVim/Vundle.vim'
Plugin 'irrationalistic/vim-tasks'
Plugin 'altercation/vim-colors-solarized'
call vundle#end()            " required
filetype plugin indent on    " required
colorscheme solarized
source $VIMRUNTIME/vimrc_example.vim
set langmenu=en_US.UTF-8
language en

What
When starting vim from git bash, I receive the following errors:
Error detected while processing function vundle#config#bundle[2]..<SNR>33_check_bundle_name:
line    1:
E121: Undefined variable: s:bundle_names
E116: Invalid arguments for function has_key(s:bundle_names, a:bundle.name)
E15: Invalid expression: has_key(s:bundle_names, a:bundle.name)
line   11:
E121: Undefined variable: s:bundle_names

Starting vim with vim -u NONE -U NONE -N made the issue disappear. So I started debugging my _vimrc and _gvimrc files, however the errors occurred while executing the ~/.vim/plugin/Vundle.vim/test/minirc.vim file.
This issue does not happen when I open my vim or gvim that's installed outside of Git/usr/bin.
Temporary fix
Deleting the test folder inside Vundle.vim makes the errors disappear.

Hmm, this is an interesting behavior. I don't think so many people test vundle on Windows (nor do I, for that matter), so I wonder how long such a problem exists.
What do you mean when you say that this doesn't happen when you open vim/gvim that's installed outside of Git/usr/bin?


Error on CRTBNDRTPG actions - undefined library

When a user profile has CURLIB(*CRTDFT), then it sets the connection config prop currentLibrary to undefined, causing further issues later.
It needs to default to QGPL instead.
Discussed in https://github.com/halcyon-tech/vscode-ibmi/discussions/231

Originally posted by robinsg August  3, 2021
Hello,
I'm running v0.6.6.
My source file is in the IFS but when I run the CRTBNDRPG I get the following:
Action Create Bound RPG Program (CRTBNDRPG) for undefined/RPABOTS001 was not successful.
This is missing the object library name from what I can tell.
If I prompt the CRTBNDRPG action and type in the object library the compile works fine.
In the actions I can see the following for the CRTBDNRPG stream file option:
CRTBNDRPG PGM(&BUILDLIB/&NAME) SRCSTMF('&FULLPATH') OPTION(*EVENTF) DBGVIEW(*SOURCE) TGTRLS(*CURRENT)
From the documentation &BUILDLIB is meant to reflect the &CURLIB setting.
When I press the  Change Current Library icon on my User Library List pane nothing seems to happen.
Any suggestion how I correct this issue?

@worksofliam Please keep in mind that setting the QGPL as the default curlib can have side effects. Esp. on a large system running multiple installations of IBM i software.

@szsascha i am just following what *CRTDFT follows.
Do you recommend a different default current library?

@worksofliam Ahhh sorry. You're completely right. I had remembered it wrong.
If it had not been correct, I would have recommended to show an error.

@szsascha no problem! Appreciate the support through all this :)


containerapp job ContainerTerminated/ ContainerCreateFailure

This issue is a: (mark with an x)

[x] bug report -> please search issues before submitting
[ ] documentation issue or request
[ ] regression (a behavior that used to work and stopped in a new release)

Issue description

I am reusing a working containerapp docker image for a new containerapp job and overriding the command to echo test

I get a single log which contains these reason codes: ContainerTerminated/ ContainerCreateFailure (No console logs as per container create failure) with no additional details

Execution remains running until timeout

Additional context
I am new to azure container apps

Can you paste your azure System logs to further understand the issue ?

The solution to my issue was supplying the --command with space separated values and not a comma seperated value. (I'm not sure where I got the idea to use a csv)
Closing this issue

the naming of variables in the resource do not help. There are commands and args that map to entrypoint and cmd override respectively. Has been a massive headscratcher.


Worktree repository display bug

After commit, reset, and other operations in the new repository created by git worktree, it will not be immediately displayed in the tab where the worktree repository is located, but will be displayed in the tab of the original repository. I need to reopen the worktree repository to display it.
Run command such as git log in worktree repository in console would has correct result.

The worktree feature is not in the supported list for the current version.

The reset command can trigger Watcher.OnRepositoryChanged on these path
FullPath: ${originRepo}/.git/worktrees/${worktreeRepo}/logs/HEAD
Name: logs/HEAD

FullPath: ${originRepo}/.git/worktrees/${worktreeRepo}/ORIG_HEAD
Name: ORIG_HEAD

FETCH button triggered this:
FullPath: ${originRepo}/.git/worktrees/${worktreeRepo}/FETCH_HEAD
Name: FETCH_HEAD

git rev-parse --is-inside-work-tree can judge if current repo is a worktree repo.

Could you please write a PR? I have not used the worktree feature.

You can try commit 1fe050ed0bf4eb7ea6753e47eb7baca6d5d3f064.


Training Problems

Has anyone encountered this error?  Have you solved this problem?


add user search from steem api, remove steemj library(no use)

Why were so many binaries present here? Do we have more of them?

No, there are no more binaries.


Invite members UI throws exceptions and stops rendering for organization

Preliminary Checks

[X] I have reviewed the documentation: https://clerk.com/docs
[X] I have searched for existing issues: https://github.com/clerk/javascript/issues
[X] I have not already reached out to Clerk support via email or Discord (if you have, no need to open an issue here)
[X] This issue is not a question, general help request, or anything other than a bug report directly related to Clerk. Please ask questions in our Discord community: https://clerk.com/discord.

Reproduction / Replay Link
https://jam.dev/c/f83ea49c-8671-4728-aab1-4b429a4f3a7b
https://app.replay.io/recording/settings--5195416e-5c66-4e93-a898-1720edbee081
Publishable key
pk_test_Y2xlcmsucHJvbW90ZWQucXVldHphbC0yMy5sY2wuZGV2JA
Description
Invite members UI throws exceptions and stops rendering for organization
Steps to reproduce:
When clicking the invite UI in the component, the rendering breaks and throws exception.
Expected behavior:
Not to break.
Actual behavior:

TypeError: Unexpected MODIFIER at 40, expected END
    at u (ui-common_f3b649_4.70.1.js:1:241095)
    at ui-common_f3b649_4.70.1.js:1:241686
    at h (ui-common_f3b649_4.70.1.js:1:241704)
    at g (ui-common_f3b649_4.70.1.js:1:242054)
    at p (ui-common_f3b649_4.70.1.js:1:238804)
    at l (ui-common_f3b649_4.70.1.js:1:242618)
    at Object.matches (ui-common_f3b649_4.70.1.js:1:243125)
    at ui-common_f3b649_4.70.1.js:1:65894
    at Array.every (<anonymous>)
    at ui-common_f3b649_4.70.1.js:1:65830
    at lu (vendors_f3b649_4.70.1.js:2:110794)
    at Es (vendors_f3b649_4.70.1.js:2:130916)
    at ss (vendors_f3b649_4.70.1.js:2:123217)
    at Vl (vendors_f3b649_4.70.1.js:2:64207)
    at vendors_f3b649_4.70.1.js:2:129718
    at Ss (vendors_f3b649_4.70.1.js:2:129723)
    at os (vendors_f3b649_4.70.1.js:2:122220)
    at S (vendors_f3b649_4.70.1.js:2:148237)
    at MessagePort.M (vendors_f3b649_4.70.1.js:2:148769)

See attached replay.
Environment
System:
    OS: macOS 14.2.1
    CPU: (12) arm64 Apple M3 Pro
    Memory: 262.56 MB / 36.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.10.0 - ~/.nvm/versions/node/v20.10.0/bin/node
    npm: 10.2.3 - ~/.nvm/versions/node/v20.10.0/bin/npm
  Browsers:
    Chrome: 122.0.6261.94
    Safari: 17.2.1
  npmPackages:
    @clerk/nextjs: ^4.29.7 => 4.29.7
    @clerk/themes: ^1.7.9 => 1.7.9
    @google-cloud/firestore: ^7.1.0 => 7.1.0
    @octokit/rest: ^18.5.2 => 18.12.0
    @stripe/stripe-js: ^1.13.1 => 1.54.2
    axios: ^0.24.0 => 0.24.0
    custom-protocol-check: ^1.4.0 => 1.4.0
    delay: ^5.0.0 => 5.0.0
    depd: ^2.0.0 => 2.0.0
    dotenv: ^8.2.0 => 8.6.0
    firebase: 9.16.0 => 9.16.0
    firebase-admin: 11.1.0 => 11.1.0
    gray-matter: ^4.0.3 => 4.0.3
    intercom-next: ^1.3.5 => 1.3.5
    isomorphic-unfetch: ^3.0.0 => 3.1.0
    lodash: ^4.17.21 => 4.17.21
    markdown-it: ^12.3.2 => 12.3.2
    marked: ^2.0.3 => 2.1.3
    moment: ^2.24.0 => 2.29.4
    next: ^14.0.3 => 14.0.3
    next-firebase-auth: ^1.0.1 => 1.0.1
    next-sitemap: ^2.5.17 => 2.5.28
    nextjs-progressbar: ^0.0.16 => 0.0.16
    nprogress: ^0.2.0 => 0.2.0
    posthog-js: ^1.96.0 => 1.96.0
    prettier: ^2.0.5 => 2.8.8
    react: ^18.2.0 => 18.2.0
    react-content-loader: ^6.0.3 => 6.2.1
    react-dom: ^18.2.0 => 18.2.0
    react-modal-video: ^2.0.1 => 2.0.1
    react-notion-x: ^4.15.0 => 4.19.8
    react-switch: ^7.0.0 => 7.0.0
    slug: ^5.3.0 => 5.3.0
    slugify: ^1.6.4 => 1.6.6
    stripe: ^8.67.0 => 8.222.0

Narrowed it down:
This breaks:
    <OrganizationProfile>
      <OrganizationProfile.Link
        label="Plan and billing"
        labelIcon={
B
}
        url={`/account/plan-billing?account=${currentOrganizationId}`}
      />
    </OrganizationProfile>

This works:
    <OrganizationProfile>

    </OrganizationProfile>

Hey @auchenberg thank you again for reporting this. This is now fixed in the latest version of clerk-js. Version: 4.70.4