[docs] Update custom-commands.md adding DDEV_UID & DDEV_GID

Adding DDEV_UID and DDEV_GID in the list of variables available on the host
The Issue
How This PR Solves The Issue
Manual Testing Instructions
Automated Testing Overview

Related Issue Link(s)
Release/Deployment Notes

@gilbertsoft uhhhh i haven't done quick one of pull request with just small changes in a text file directly via the github interface very often. so far i was under the impression that forks are kept up to date automatically in contrast to the command line where you run git pull first. but that was a false assumption damn :( still much to learn. thats the reason my main branch was behind i've based the PR on. but in regards of the rebase. am i am able to do that in the github ui as well or is that only possible via the command line? cuz i'Ve looked for how to rebase a PR on github and all the postings (for example https://github.blog/changelog/2022-02-03-more-ways-to-keep-your-pull-request-branch-up-to-date/ ) mention and update branch button at the bottom of the page. but i only have a resolve conflict button instead there.

@rpkoller If you used the web UI to create this patch, it used the latest master version, and created a new branch for you based on upstream/master. The problem is that you in the meantime had another PR pulled, which changed the underlying docs file. So now you have to rebase and solve the conflicts. You can also do that in the web UI, but I find that kind of hard.
There are many merge conflict resolution techniques, you'll want to look at them. If you use vscode I imagine it has one.
This is a very easy one to learn rebasing on, resolving conflicts, so may be worth your time. A lazy person could just do the PR over again. A less lazy person could just check out the branc, git reset --hard upstream/master and overwrite the contents with the intended changes (again).
There are many ways to study the conflicts, one easy one is to click this button,

But it will be a good exercise for you to learn how to rebase and solve conflicts, and this is a really easy one to do it on.

Oh ok. when i checked the variant i suggested to go back to my ddev fork and into the corresponding branch there i would have the option to update the branch but that would drop/delete one commit (supposedly the one i did). but i would go with your suggested approach @rfay and go via the resolve conflicts button. but i suppose the cleanest approach for that is to copy the two line i'Ve added in this PR and copy them from the PR block down into the mast block and then delete the PR block and the dividers <<<<<, ==== and >>>>>. i think that would be the cleanest approach correct?

Oh ok. when i checked the variant i suggested to go back to my ddev fork and into the corresponding branch there i would have the option to update the branch but that would drop/delete one commit (supposedly the one i did). but i would go with your suggested approach @rfay and go via the resolve conflicts button. but i suppose the cleanest approach for that is to copy the two line i'Ve added in this PR and copy them from the PR block down into the mast block and then delete the PR block and the dividers <<<<<, ==== and >>>>>. i think that would be the cleanest approach correct?
update: ahhh the resolve button does the rebase/update as well since after resolving the conflict i see that the master branch got merged into the branch. that wasn't clear by seeing only the resolve conflict page. i "think" i've understood now. hope i've done everything correctly now. (thanks @rfay for the recommendation)

Thanks! We are able to merge now, conflicts resolved :)

Another chance to practice your conflict resolution, thanks. This is a result of your two PRs touching the same area. It probably would have been easier for you to fix both things in one PR. We generally all avoid that but this would have been a good place to relax about it.

yep true, i agree. but hope the conflicts are fixed now.

The docs test failure is an upstream problem, not from this PR. See

https://github.com/ddev/ddev/pull/5004

Updated to pick up the upstream test fix, make sure you pull before working on it.

At first i thought it was a good idea and i wanted to do that within the consistency issue. but i've dropped that idea in https://github.com/ddev/ddev/pull/4998#issuecomment-1596984636 and agreed to @gilbertsoft . @mattstein also agreed to his point https://github.com/ddev/ddev/pull/4998#issuecomment-1597544156. so this issue would be ready now that the tests are green after you upstream fixes.


Speedup the Validate PR Style GH workflow by invoking only mvn validate

dea4ce4 more tweaks to make it work


Better guidance on configuring Azure Cloud Provider

Rancher versions:
rancher/rancher: v2.0.0
Today it's a huge list with no clue what is required and what not. Maybe start with the required options and make an advanced section.

Here's the configuration information for the provider itself.
https://github.com/kubernetes/cloud-provider-azure/blob/master/docs/cloud-provider-config.md

rancher/rancher:master 6/12
Descriptions have been added to Azure Cloud Provider fields.
However, only
cloud
tenantId
aadClientId
aadClientSecret
subscriptionId

are required for the Azure cloud provider to work correctly when Rancher is provisioning the nodes. This should be noted on these fields.  @galal-hussein can you confirm?

@bmdepesa from my testing, i can set up a cluster with Azure cloud provider with only these 4 parameters:
tenantId
aadClientId
aadClientSecret
subscriptionId

I've added the four that @galal-hussein tested with as required fields, so they have the required filed asterisks now

aadClientSecret should be treated like a password.  It is in other parts of the system, but was not here as of 2.0.2

rancher/rancher:master 6/19
The four required fields are noted. Opened #14066 for aadClientSecret enhancement.


Merge com.azure.resourcemanager into com:azure to make it included in com.azure:azure-sdk-bom

Is your feature request related to a problem? Please describe.
Problem:
The fractured Azure SDK causes an increasing amount of issues due to mismatching versions across different sub-SDKs.
A central BOM covering all parts of the SDK would help simplify the dependency management.
Describe the solution you'd like
One BOM covering all parts of the Azure SDK and having everything in the com.azure group, similar as with AWS SDK software.amazon.awssdk:bom
Example:
BOM: com.azure:azure-sdk-bom
Core SDK: com.azure:azure-core
Resource Manager SDK: com.azure:resourcemanager
Describe alternatives you've considered
Include group com.azure.resourcemanager in BOM
Additional context
Gradle sample of current situation:
implementation("com.azure:azure-identity")
implementation("com.azure:azure-core")
implementation("com.azure:azure-core-management")
implementation("com.azure.resourcemanager:azure-resourcemanager")
implementation("com.azure.resourcemanager:azure-resourcemanager-containerservice")

Output of gradle task dependencies
+--- com.azure.resourcemanager:azure-resourcemanager FAILED
+--- com.azure.resourcemanager:azure-resourcemanager-containerservice FAILED

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Description Added
[x] Expected solution specified

Hi @juergenbr, thank you for sharing feedback with us.  I will take your comments in this post as feedback and share them with the right teams.  @pallavit could you please also follow up?
/cc @weidongxu-microsoft

One thing that might not work very well with scheduled BOM release, is that management-plane release data could sometimes being for flexible.
E.g. in May we got request from Spring Cloud to wait for one of their GA api-version, which in worst case will delay management-plane release to 3rd or 4th week of May (ARM onboard process takes about a week). I am not sure whether this kind of difference in release data is compatible with BOM release.

@joshfree @pallavit @weidongxu-microsoft do you have any updates on this issue?

Hey Team, is there any update here? Any timeline when this could be available?

Hey tem, any update here?

@srnagar What is your opinion?
If you think it be beneficial to put azure-resourcemanager to BOM, we can adjust the release date of mgmt lib, to align with data-plane libs (and do monthly release before BOM release).


Fix Experience Page Colors and CARDS

Reference

I want to do this.

I want to do this.

I want to work on this issue as a part of SWoC'21

I want to work on this issue as a part of SWoC'21

@nilisha-jais I'm temporarily un-assigning this issue since Shubham commented first. I've assigned the other issues you are interested in working on to you.

@nilisha-jais I'm temporarily un-assigning this issue since Shubham commented first. I've assigned the other issues you are interested in working on to you.

@nilisha-jais I'm temporarily un-assigning this issue since Shubham commented first. I've assigned the other issues you are interested in working on to you.

okay np

@nilisha-jais I'm temporarily un-assigning this issue since Shubham commented first. I've assigned the other issues you are interested in working on to you.

okay np


[YUNIKORN-551] Deadlock when removing node

When a node gets removed the node alocations get removed as part of the
cleanup phase. The node removal acquires the partition lock and does not
release it until all actions are done. This could cause a deadlock with
scheduling if the node being removed contains allocations for the same
application that is scheduled.
The node removal should only lock while updating the partition and
release before updating the apps and queues. Since node removal is
called as part of the cleanup of a failed add of a node the add flow is
changed inline with the removal to minimise lock time.
The partition lock was also held while placing applications. This is not
required as placing an application does not modify the partition until
everything is done. The lock should only be acquired at that point.

I checked this change also on top of the changes for YUNIKORN-460 (PR #250) and the overlap is not a problem the code touched by the 2 changes is limited to a couple of lines with simple to fix merge clashes

hi @wilfred-s regarding your comment

I checked this change also on top of the changes for YUNIKORN-460 (PR #250) and the overlap is not a problem the code touched by the 2 changes is limited to a couple of lines with simple to fix merge clashes

do you mean we are good to get this merged, this change won't cause any conflicts to PR #250?

do you mean we are good to get this merged, this change won't cause any conflicts to PR #250?

Yes that is what I meant. There is one set of lines that overlaps between the two changes which is easily fixed even on commit. The renamed termination type is the reason for the overlap.

Thanks for the clarification, merged the PR.


Switch around the tutorial files so that Tutorial 1 is based on 2vtq

@pemsley could you omit package-lock.json from the pull request?

Oh dear. I meant to commit only the tutorial directory.
On Fri, 10 Mar 2023 at 17:52, stuartjamesmcnicholas <
@.***> wrote:

Merged #224 https://github.com/stuartjamesmcnicholas/Moorhen/pull/224
into master.
—
Reply to this email directly, view it on GitHub
https://github.com/stuartjamesmcnicholas/Moorhen/pull/224#event-8720083848,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADJ6J6TBXDYZHSI532HAXLLW3NL4VANCNFSM6AAAAAAVWQQITI
.
You are receiving this because you were mentioned.Message ID:
@.***>

OK, that's done. Please pull again.


Remove runner thread in alsa

Summary of the PR
This PR is the result of splitting https://github.com/rust-vmm/vhost-device/pull/556. This PR addresses the required changes to remove the runner thread in the ALSA backend. Also, it propagates the errors from the audio backed  to the device. Finally, this PR prepares the ALSA backend to get rid of the Control Message in a following PR.
Requirements
Before submitting your PR, please make sure you addressed the following
requirements:

[x] All commits in this PR are signed (with git commit -s), and the commit
message has max 60 characters for the summary and max 75 characters for each
description line.
[x] All added/changed functionality has a corresponding unit/integration
test.
[x] All added/changed public-facing functionality has entries in the "Upcoming
Release" section of CHANGELOG.md (if no such section exists, please create one).
[x] Any newly added unsafe code is properly documented.

Overall looks ready to merge after some minor points are addressed

Thanks Manos for your comments, I will address them and update the PR.


Added php hashes

Php has some quirks where hashed text will match even if they don’t actually match if the program is comparing them loosely. This pull request adds plaintext and hashed plaintext from spaze/hashes that has those “magic hashes”
In addition to those magic hashes, other kinds of behavior such as truncation and pre hasing of plaintext resulting in hash collisions are added in this pull request.

This readme can be used as an example for #929 which is a proposal for better readmes.

Thanks @molangning


Consumption sensors

Feature request
Is it possible to add energy and water consumption sensors for applaences.
What version of the integration are you using?
0.1.4
Anything in the logs that might be useful for us?
No response
Additional information
No response

Hi,
There are already the consumption sensors for washers, dryers, washer-dryers and dishwashers. Sensors are disabled by default, so you have to navigate to your device page and enable sensors.

Tx, my bad :)

I have previously already enabled those (dishwasher and dryer), but I also have a Miele@Home fridge (K 7343 D), which doesn't have energy consumption as an entity.
Maybe there is no energy consumption sensor, but if there is, it would be very nice to have that also in one of the next Miele integration versions.
Great work, and thx for your efforts.

Consumption data is available on some later models of washing machines, dryers, washer/dryers and dish-washers. No other appliances report consumption data.


Adds ebs-csi driver base image

Issue #, if available:
Description of changes:
The EBS team has identified the execs which are exec'd via
their driver.  This new image uses the new install_binary
approach to install just these bins along with their required
libraries.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/unhold
/approve

/lgtm
/approve


settings window proposal

Hi
Look at screenshot of foobar2000 very handy settings window.
Maybe you want to make it like this? According to me this is the best way to do it.
A treeview at the left with categories and at the right the selected category with all its options
I also show this because I would love to have a "plugins" section (see this screenshot) which lists the plugins and shows the version of the LIBRARY and not the plugin's version (as seen here in foobar2000).
So it would be great to see for example: adplug plugin, version: 2.3.3 etc
This way we can see if all plugins are up to date easily, by displaying the version number of the library used.
What I also like is the winamp way to configure a plugin: double click it for settings of that plugin.
(here they add each plugin's setting in the treeview)

Yeah I have seen this settings layout in foobar2000 and I will likely make something similar. When it comes to version I think it's good to have a "Version" and "Library Version". The reason I think that is good is because there may be a fix in the plugin so the version of the plugin goes up but the library remains the same.

"Version" and "Library Version is even better!
I would also like very much a checkbox in front of each plugin: in this way we can force the player to use a specific plugin to play files that can be played be more then 1 plugin.
This can be seen in audacious, see screenshot.

But is the screenshot above a global setting or a "per file setting" ? Something I want to have is that you can right click on a file and say "use this player x" (and this can be overriding a directory of files also for example)

This is a global setting. If you disable a plugin in audacious, ALL files that need that plugin can NOT be played (until you enable it again).
In foobar2000 you must uninstall a plugin to disable it (not good!).
Your idea seems a bit complicated. I don't think users will need such an advanced setting. I would personally not need it (global is fine for me). But maybe other people would want to use it. Where will you all store settings for EACH file?
It could introduce much bugs IMHO (compared to global setting)

The idea is if there are several players that can play a certain file but if one of them plays it wrong / with less quality you can override. This is something that XMPlay support for example and has been requested https://github.com/emoon/HippoPlayer/issues/50

It's also so you can tweak settings for an specific song and the player used (as seen in #50)

I didn't think that way, it's very unique feature!
Not much players have it

Indeed. I think very few players allow you to configure it this way. Also these settings can be saved in the database. I'm not exactly sure how to approach it just yet, but then it's a bit down on the priority list as I need to get the general settings in first.

Making some progress on this. This is currently how it looks. It's not done yet, but getting there.

Making some progress on this. This is currently how it looks. It's not done yet, but getting there.


Adding the user config to add prefix of link to the contract for mainly wsl users

The currently generated pytypes source code link is generated like this.
[Source code](file:///home/meditationduck/projects/audit-meditationduck/contracts/MeditationDuck.sol#18)

However, for the WSL, it can not reach the actual source code.
This pull request is for adding a new config to add a prefix to solve the path for the WSL.
The new config will be like this in the wake.toml
~~
[general]
pytypes_link_prefix = "wsl.localhost/Ubuntu"
~~

which generates links in the pytypes like below which solves the path issue.
[Source code](file://wsl.localhost/Ubuntu/home/meditationduck/projects/audit-meditationduck/contracts/MeditationDuck.sol#18)

I was aware there is the config for the printer or detector.
Probably it is possible to merge them, but the format of those paths is different.
Additionally, it seems possible to replace the path of the source_unit.path at compile.py. However, it will be more complicated changes.

by clicking the blue link on the VS-code, direction to the code worked also for WSL and SSH... ><


Why are you shipping user32.dll?

Compatibility insanity aside, I don't think that's a redistributable DLL.
Also looks like its in PIV Manager too. (probably others, but I don't have them installed).

Thanks for reporting this! This looks like the result of a bug in PyInstaller: https://github.com/pyinstaller/pyinstaller/issues/795
In short, it's not used and it shouldn't have been part of the installation. I'll be replacing the installer to not bundle it shortly. In the meantime you can safely delete the file yourself.

The installers for this project (1.3.0) and for YubiKey PIV Manager have now been updated. Note that installing on top of an existing installation will not remove any files, so either delete the file manually to get rid of it, or do a complete uninstall of the application before running the updated installer.

Awesome!


Datatype in CSV wizard won't be accepted

Azure Data Studio Version: 1.21.0 / data virt extension: 1.8.0
Steps to Reproduce:

Run the virtualize CSV wizard
Change the datatype of a string column from nvarchar(50) to char(10) from the drop down
Change it manually to char(2)
Generate the Script
The script will have char(10)

@Charles-Gagnon sorry - I think I got another one for you :)

Good find @bweissman ! I've confirmed the repro and will look into this.
It does work if you press enter while in the input box as a short-term workaround if you need this functionality.


Hooks should be create_* and use_* not *::new()

Perhaps this is a bit of a hot take, and I know the library is just getting switched off of the create_* paradigm but, in my humble opinion, this is a step in the wrong direction. I really love Leptos, and this is more of a nitpick than anything, but I thought I should at least vocalize how I see this particular aspect.
I always thought that the old paradigm made it clear where different functions should be run. Every struct under the sun in Rust has the ::new() associated function, but effects and signals should only be created in certain, specific contexts. Namely, inside of components and not inside of reactive closures. When I see a function that starts with create, use, or provide, I think "ah, this is a hook, and it's going to put something on the reactive graph. I better be careful where I call this."
It also keeps the hooks inline with custom hooks, and gives custom hooks a strong convention to follow. Consider the following:
let signal = create_rw_signal(0);
let (signal, set_signal) = create_signal(0);
let something_cool = use_something_cool();

create_effect(move |_| {
    create_rw_signal(0); // <- bad and I know it
});

These are all following a consistent pattern, but the following are not:
let signal = RwSignal::new(0);
let (signal, set_signal) = signal(0);
let something_cool = use_something_cool();

Effect::new(move |_| {
    RwSignal::new(0); // <- bad but I wouldn't necessarily know it
});

Some things are struct invocations, some are functions, some are obvious hooks. I disagree with the statement that the second example is "more rusty" as there's nothing inherently unrusty about functions. And, should custom hooks continue using the old naming convention? For libraries (including leptos itself) how can one tell the difference between something that should be called as a hook and things that merely perform an action?
I'd actually argue it should go in the other direction and become even more consistent, opting for only use_* and doing away with create_* entirely. This means one can search for all hooks with a simple search for use_ on docs.rs and can be sure something is a hook with one simple glance.
let signal = use_rw_signal(0);
let (signal, set_signal = use_signal(0);
let something_cool = use_something_cool();

use_effect(move |_| {
    use_rw_signal(0); // <- bad and I know it for sure
});

I know it's probably too late to contribute to the conversation on this topic, and unlikely to change your mind, but I think - at the very least - the hook functions should remain available for those who want them. Again, Leptos is awesome and keep up the amazing work!

We don't have hook rules.
This example
Effect::new(move |_| {
    RwSignal::new(0); // <- bad but I wouldn't necessarily know it
});

is completely fine, and is a microcosm of how the whole renderer works.
I just want to clarify that there's nothing wrong with the examples you're giving as wrong, as long as you understand the ownership paradigm/when things will be disposed, so I'm not sure I understand what the helpful hint is supposed to be that the naming conventions give.

What exactly is the ownership model for that then? I assume the effect is tied to the component it's called in and will be disposed of when the component (or its view) drops, but the enclosed signal is not created in such a context, so when is it destroyed?
In my original draft of my post I actually didn't talk about it being bad to put things in particular places, so I suppose I'll still just lean on that then, which is the idea that having functions with a consistent naming convention is still better because it communicates to the user that this will insert data into the reactive graph.

What exactly is the ownership model for that then? I assume the effect is tied to the component it's called in and will be disposed of when the component (or its view) drops, but the enclosed signal is not created in such a context, so when is it destroyed?

There's a pretty complete description of how ownership works here. The short answer is that it is a tree of effects. So your RwSignal is owned by your Effect, and your Effect is owned by whatever render effect created that component, or by the root if it's at the root. When that component is unmounted/its parent re-runs, then yes both the Effect and the RwSignal will be disposed, because it is a parent-child relationship. But the component doesn't own anything; there's nothing wrong with having a signal created inside an effect. It will be disposed whenever that effect re-runs, or when the effect is disposed.

having functions with a consistent naming convention is still better because it communicates to the user that this will insert data into the reactive graph.

This is a less precise concept than you might think! Do you mean "insert data into the arena"? (the thing that makes things Copy) Or "insert things into the reactive graph"? Neither create_rw_signal nor RwSignal::new() inserts anything into the reactive graph; it does insert data into the arena.
===
I'm fine with "I disagree with this as a matter of style" and open to other feedback, to be clear.

Thanks for your quick feedback

The short answer is that it is a tree of effects. So your RwSignal is owned by your Effect, and your Effect is owned by whatever render effect created that component, or by the root if it's at the root.

Ah, I see. Out of curiosity, would it be fine to call RwSignal::new() in a callback or a resource's async block (wouldn't that put it on the root)?

Do you mean "insert data into the arena"? (the thing that makes things Copy) Or "insert things into the reactive graph"? Neither create_rw_signal nor RwSignal::new() inserts anything into the reactive graph; it does insert data into the arena.

I understand that the data given to the signal is put into an arena, but I meant that it becomes part of the reactive graph in the sense that the runtime now tracks it as a source, and will cause effects to become dirty upon being changed. Regardless, I just mean that "some side effect is being created and it has to do with reactivity."

Sorry for the delayed response.

would it be fine to call RwSignal::new() in a callback or a resource's async block (wouldn't that put it on the root)?

That is correct, it does that, and you can see the implications in the difference between the counters example in 0.7/main branch (uses ArcRwSignal to avoid leaking), and in 0.6 (uses manual .dispose() to avoid leaking.

I meant that it becomes part of the reactive graph in the sense that the runtime now tracks it as a source

Creating a signal doesn't cause the runtime to do anything with it, it just creates a struct and stores it in an arena. Reading a signal is what causes the special reactive behavior. So the creation itself does not have side effects on the reactive system, and doesn't insert the signal into the reactive graph, which is why I was clarifying.
I'm going to close this as "not planned" but thanks for the discussion.


Use independent CLI tool with Forge FFI for getting proofs in Solidity tests

Resolved by https://github.com/risc0/bonsai-foundry-template/pull/74


*: update kubernetes deps to v1.18

This commit bumps the kubernetes version dependencies from v1.17
to v1.18.
The kubernetes client-go library introduced breaking
changes in v1.18 by adding context.Context to many of its function
signatures. The kubernetes-sigs/clientgofix tools was used in this
commit to automatically add the necessary context.TODO() arguments
to all client-go usage in the repo.
Fixes #3146

Yep! Looks like I need to make sure my go-bindata and generator binaries are up-to-date.

Thanks, this lgtm on green and after rebase.
cc @coreos/team-monitoring any comments?

This lgtm as well, just one thing: could you open an issue to replace the context.TODO()s with actual contexts? We should eventually pipe through a real context, but I'm fine with having context.TODO() for now as it doesn't make it worse than it was before, but opens the door for improvement.

Thanks! 🎉


type 'String' is not a subtype of type 'bool'

New Issue Checklist

[x] I have searched for a similar issue in the project and found none

Issue Info

Dio Version: 2.1.12

flutter doctor -v
[✓] Flutter (Channel beta, v1.7.8+hotfix.2, on Linux, locale en_US.UTF-8)
    • Flutter version 1.7.8+hotfix.2 at /home/antonio/Documents/flutter
    • Framework revision 2e540931f7 (7 days ago), 2019-07-02 09:31:07 -0700
    • Engine revision b1cb0d9e9b
    • Dart version 2.4.0

[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at /home/antonio/Android/Sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • Java binary at: /home/antonio/Documents/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)
    • All Android licenses accepted.

[✓] Android Studio (version 3.6)
    • Android Studio at /home/antonio/Documents/android-studio
    • Flutter plugin version 36.0.7
    • Dart plugin version 191.7830
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)

[✓] VS Code (version 1.36.0)
    • VS Code at /usr/share/code
    • Flutter extension version 3.2.0

[✓] Connected device (1 available)
    • Android SDK built for x86 • emulator-5554 • android-x86 • Android 9 (API 28) (emulator)

• No issues found!

Issue Description and Steps
DioError (DioError [DioErrorType.DEFAULT]: type 'String' is not a subtype of type 'bool'#0      FormData.length.writeMapLength.<anonymous closure> (package:dio/src/form_data.dart:105:18)
#1      List.forEach (dart:core-patch/growable_array.dart:278:8)
#2      FormData.length.writeMapLength (package:dio/src/form_data.dart:103:27)
#3      FormData.length.<anonymous closure>.<anonymous closure> (package:dio/src/form_data.dart:131:27)
#4      List.forEach (dart:core-patch/growable_array.dart:278:8)
#5      FormData.length.<anonymous closure> (package:dio/src/form_data.dart:127:29)
#6      __InternalLinkedHashMap&_HashVMBase&MapMixin&_LinkedHashMapMixin.forEach (dart:collection-patch/compact_hash.dart:367:8)
#7      FormData.length (package:dio/src/form_data.dart:121:10)
#8      Dio._transformData (package:dio/src/dio.dart:853:23)
<asynchronous suspension>
#9      Dio._makeRequest (package:dio/src/dio.dart:738:26)
<asynchronous suspension>
#10     Dio._request.<anonymous closure>.<anonymous closure> (package:dio/src/dio.dart:711:22)
#11     _rootRunUnary (dart:async/zone.dart:1132:38)
#12     _CustomZone.runUnary (dart:async/zone.dart:1029:19)
#13     _FutureListener.handleValue (dart:async/future_impl.dart:126:18)
#14     Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:639:45)
#15     Future._propagateToListeners (dart:async/future_impl.dart:668:32)
#16     Future._complete (dart:async/future_impl.dart:473:7)
#17     _SyncCompleter.complete (dart:async/future_impl.dart:51:12)
#18     _AsyncAwaitCompleter.complete (dart:async-patch/async_patch.dart:28:18)
#19     _completeOnAsyncReturn (dart:async-patch/async_patch.dart:294:13)
#20     Dio._executeInterceptors (package:dio/src/dio.dart)
<asynchronous suspension>
#21     Dio._request.<anonymous closure> (package:dio/src/dio.dart:703:20)
#22     Dio._checkIfNeedEnqueue (package:dio/src/dio.dart:990:22)
#23     Dio._request (package:dio/src/dio.dart:702:9)
<asynchronous suspension>
#24     Dio.request (package:dio/src/dio.dart:614:12)
<asynchronous suspension>
#25     Dio.put (package:dio/src/dio.dart:169:12)
#26     UserServiceImpl.edit (package:Condor/data/api/user/user_service_impl.dart:43:53)
<asynchronous suspension>
#27     UserRepositoryImpl.editProfile (package:Condor/data/repositories/user/user_repository_impl.dart:71:43)
<asynchronous suspension>
#28     EditProfileBloc._mapEditProfileToState (package:Condor/ui/pages/edit_profile/bloc/edit_profile_bloc.dart:70:29)
<asynchronous suspension>
#29     EditProfileBloc.mapEventToState (package:Condor/ui/pages/edit_profile/bloc/edit_profile_bloc.dart:26:14)
<asynchronous suspension>
#30     Bloc._bindStateSubject.<anonymous closure> (package:bloc/src/bloc.dart:127:14)
#31     Stream.asyncExpand.onListen.<anonymous closure> (dart:async/stream.dart:513:30)
#32     _rootRunUnary (dart:async/zone.dart:1132:38)
#33     _CustomZone.runUnary (dart:async/zone.dart:1029:19)
#34     _CustomZone.runUnaryGuarded (dart:async/zone.dart:931:7)
#35     _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:336:11)
#36     _DelayedData.perform (dart:async/stream_impl.dart:591:14)
#37     _StreamImplEvents.handleNext (dart:async/stream_impl.dart:707:11)
#38     _PendingEvents.schedule.<anonymous closure> (dart:async/stream_impl.dart:667:7)
#39     _rootRun (dart:async/zone.dart:1120:38)
#40     _CustomZone.run (dart:async/zone.dart:1021:19)
#41     _CustomZone.runGuarded (dart:async/zone.dart:923:7)
#42     _CustomZone.bindCallbackGuarded.<anonymous closure> (dart:async/zone.dart:963:23)
#43     _rootRun (dart:async/zone.dart:1124:13)
#44     _CustomZone.run (dart:async/zone.dart:1021:19)
#45     _CustomZone.runGuarded (dart:async/zone.dart:923:7)
#46     _CustomZone.bindCallbackGuarded.<anonymous closure> (dart:async/zone.dart:963:23)
#47     _microtaskLoop (dart:async/schedule_microtask.dart:41:21)
#48     _startMicrotaskLoop (dart:async/schedule_microtask.dart:50:5)
)

Fixed in 2.1.13

@wendux I can confirm that it was indeed fixed on 2.1.13. I'm closing the issue. Thanks for the quick fix and awesome package :+1:


fix: groups on subscribers are full group objects

Resolves #35 and #36.

Thanks for contributing @TobbenTM. However, I have to close PR. This won't solve https://github.com/mailerlite/mailerlite-nodejs/issues/35 nor https://github.com/mailerlite/mailerlite-nodejs/issues/36. And groups param in CreateOrUpdateSubscriberParams has to be an array of ids docs

Okay, do you have any intention to fix this yourself @Mantas97 , or do I need to maintain my own functioning fork?

@TobbenTM Mentioned issues are not isolated to SDK, they stem from API. A fix for this is planned for the near future.

@TobbenTM Fixes for #35 & #36 released in 1.2.2


feat: add support for chunkById, chunkByIdDesc, and chunkMap methods

Hello!
This closes #2065.
Thanks!

Thank you!

Thanks


Retire duplicate Create a gRPC client and server in ASP.NET Core 3.0 using Visual Studio

Sample hosted: Create a gRPC client and server in ASP.NET Core 3.0 using VS only (no VSC or VS Mac)
is a complete duplicate of Tutorial: Create a gRPC client and server in ASP.NET Core (8 K PV/month) with the following exceptions.  The sample hosted version :

Has instructions that no long work.
It's version 3.0
Has only 325 PV/month

Recommend we retire this version - OR remove all the instructions and link to Tutorial: Create a gRPC client and server in ASP.NET Core
That way folks would have an easy download mechanism and updated instructions.
I'm guessing we can't move the VS, VSC, VSmac version to https://docs.microsoft.com/samples/ because it doesn't support tabs.
@JamesNK  please advise.

I don't want to move the tutorial to samples.
Whatever you want to do with the samples copy is fine with me.

@wadepickett can you replace this tutorial with a link to our sample. Update the download  code to the 3.1 version from our repo.

Don't you mean the opposite: replace the sample content with a link to the tutorial?

@JamesNK  Thanks, corrected text.

@Rick-Anderson, will do, thanks!


DOC: Update Mayavi troubleshooting section

This PR follows https://github.com/mne-tools/mne-python/issues/9360#issuecomment-829520105 and adds MNE_3D_OPTION_ANTIALIAS to the list of variables to set if there is an issue with Mayavi.
Closes https://github.com/mne-tools/mne-python/issues/9360

Does it help @bloyl, @larsoner ?

thx @GuillaumeFavelier


New features

A few new features added:

allow hidden options - ones that dont print with educate
"global" settings to enable behavior similar to Perl's Getopt::Long

prevent short-flags from being generated for each option by default
this is more convenient than setting :short => :none for each option
IMX, users often forget to use two dashes for long opts and then inadvertently trigger short-opts, e.g., instead of triggering option  --dog, they effectively trigger -d -o -g, or -d og
enable loose matching of options for the shortest unambiguous match.  Given options apple, apricot and antelope, you could trigger them with --app, --apr, and --an, respectively.

Tests and some amount of documentation also included.

@kbrock any feedback on this PR?

Submitted this PR about 4 months ago.
Can this be approved/denied or otherwise given some feedback, please?

Hi @kbrock, I've addressed much of your feedback with some recent commits.

Reverted versions back to 2.1.2
Removed attr_reader :settings .  There is no need for a public method here to retrieve the settings on the instance of Trollop::options , it was just used for testing purposes.
Settings is documented on lines 856-867 of lib/trollop.rb
However, there is still a need to pass some sort of settings that can be applied to the entirety of the Trollop::options call (insofar as implementing the inexact_match and no_default_short_opts flags are concerned).
A :hidden flag on an option is useful, in my experience.  Developers of command line utilities used in small groups like to roll out undocumented options first - either for their own use, for power-users, or just for limited audience testing.
RE: naming of no_default_short_opts flag, maybe it's poorly named, but it made sense to me.  It is used to suppress generation of short options unless they are manually specified.  Maybe "prevent_default_short" ?
I have modified the inexact-match (lazy match) to handle the case you mentioned, which is to say that if you have options :book and :bookstand, then  --book will exact match :book (unambiguously).  Likewise --books will only match bookstand, as it matches the first portion of the given string against the existing long options.  I enhanced my collision tests a bit.

I understand the hesitation on these features. If some are unpalatable, let me know and i'll remove them.

prevent short-flags from being generated for each option by default

@kbrock Note this is a backwards incompatible change to the very interface of the gem and would require a major version bump.

@chrisarcand i'm not sure how this is backwards incompatible.  All of the previous tests work just fine without this new option enabled.  I think there may be some confusion due to how i named it: it probably should've read something like "An option (defaulted off) that will prevent short-flags from automatically generated".  perhaps that's what @kbrock meant by "not thrilled with this name"  - maybe no_auto_shorts? Or am i missing something about how this will break existing users?

I think the PR should be completely backward compatible for the case you suggest, this was a case of me not clearly expressing my intent.
The aforementioned:

prevent short-flags from being generated for each option by default
enable loose matching of options

Should have read something like
Add two flags:

disable automatic short flag generation
enable loose matching of options

for the sake of backward compatibility with hundreds/thousands of existing projects, neither of these are turned on by default in this PR.  A project developer would have to intentionally throw a switch in order to alter behavior of said project.  My intent is to extend the functionality of trollop, not change what it does when normally configured.

Ahhh I see, my confusion was a due to a combination of just reading your description and not closely looking at the code itself, and that a comment not made by you seemed to indicate this behavior from the linked issue.
I see you have this behavior behind the :no_default_short_opts option.
Forget my comments, you're right! This is good.

latest push:

changed confusing setting name to :disable_auto_short_opts

added another new feature setting.  :suggestions
this uses the DidYouMean module (only when available, but it's standard in 2.3 and 2.4) to provide Git-like responses when a user gives an option name that doesn't exist.  It looks for close matches and gives suggestions.  This only affects the output message on the raised CommandlineError.  The suggestion tests are only enabled when DidYouMean is found, so the developement dependencies do not require it.

I merged on my end with master  / latest and pushed again.  The 'globals' are not really globals (e.g. class methods), but are settings that affect all options created on the instance of the parser, e.g:
## Settings:
##   Trollop::options and Trollop::Parser.new accept +settings+ to control how
##   options are interpreted.  These settings are given as hash arguments, e.g:
##
##   opts = Trollop::options(ARGV, :inexact_match => true, :disable_auto_short_opts => true ) do
##     opt :foobar, 'messed up'
##     opt :forget, 'forget it'
##   end
##
##  +settings+ include:
##  * :inexact_match  : Allow minimum unambigous number of characters to match a long option
##  * :disable_auto_short_opts  : Prevent automatic creation of short options
##  * :suggestions  : Enables suggestions when unknown arguments are given and DidYouMean is installed.  DidYouMean comes standard with Ruby 2.3+
##  Because Trollop::options uses a default argument for +args+, you must pass that argument when using the settings feature.

Maybe it's better to refer to them as 'locals' rather than 'globals'.

Any thought on this?  These enhancements (including the suggestions / DidYouMean) are pretty useful from an end-user standpoint.


Test test_filelock.py::test_lock_mode_soft fails if default umask is 002

Description
Test cases for filelock fail if the umask of the current user is not 022.
This is a problem, because it seems the default umask for Ubuntu 22.10 seems to be 002.
I can see documentation showing it should be 002. I know this is odd, as I was expecting it to be 002.
From /etc/login.defs
#
# Enable setting of the umask group bits to be the same as owner bits
# (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is
# the same as gid, and username is the same as the primary group name.
#
# If set to yes, userdel will remove the user's group if it contains no
# more members, and useradd will create by default a group with the name
# of the user.
#
USERGROUPS_ENAB yes

This leads to the error in testing:
python3 -m pytest
====================================================== test session starts =======================================================
platform linux -- Python 3.10.7, pytest-7.2.2, pluggy-1.0.0
rootdir: .../py-filelock
plugins: cov-4.0.0, timeout-2.1.0, mock-3.10.0
collected 50 items

tests/test_error.py ....                                                                                [  8%]
tests/test_filelock.py ........................................F.....                                                      [100%]

============================================================ FAILURES ============================================================
______________________________________________________ test_lock_mode_soft _______________________________________________________

tmp_path = PosixPath('.../pytest-4/test_lock_mode_soft0')

    def test_lock_mode_soft(tmp_path: Path) -> None:
        lock_path = tmp_path / "a.lock"
        lock = SoftFileLock(str(lock_path), mode=0o666)

        lock.acquire()
        assert lock.is_locked

        mode = filemode(os.stat(lock_path).st_mode)
        if sys.platform == "win32":
            assert mode == "-rw-rw-rw-"
        else:
>           assert mode == "-rw-r--r--"
E           AssertionError: assert '-rw-rw-r--' == '-rw-r--r--'
E             - -rw-r--r--
E             + -rw-rw-r--

tests/test_filelock.py:447: AssertionError
==================================================== short test summary info =====================================================
FAILED tests/test_filelock.py::test_lock_mode_soft - AssertionError: assert '-rw-rw-r--' == '-rw-r--r--'
================================================== 1 failed, 49 passed in 1.65s ==================================================

Steps to Reproduce

Set umask umask 002
Run pytest against repo
Observe errrors

Expected behavior
Test cases should either skip or force the umask to make sure everything is working correctly.

Perhaps there should be clearer documentation that Filelock sets permissions regardless of umask, and SoftFilelock sets permissions using umask? Perhaps changing this behavior?


refactor: remove dead iterator code

Required checklist

[ ] Sample config files updated (both /etc folder and NewDemoConfig methods) (influxdb and plutonium)
[ ] openapi swagger.yml updated (if modified API) - link openapi PR
[x] Signed CLA (if not already signed)

Description
This removed iterator code was not used except in tests. I changed the tests to test the iterator we actually use.
Context
N/A
Affected areas (delete section if not relevant):
N/A
Severity (delete section if not relevant)
N/A
Note for reviewers:
Check the semantic commit type:

Feat: a feature with user-visible changes
Fix: a bug fix that we might tell a user “upgrade to get this fix for your issue”
Chore: version bumps, internal doc (e.g. README) changes, code comment updates, code formatting fixes… must not be user facing (except dependency version changes)
Build: build script changes, CI config changes, build tool updates
Refactor: non-user-visible refactoring
Check the PR title: we should be able to put this as a one-liner in the release notes

Re-opening pull request to kick circleci jobs - I tried triggering a re-run in circle but that messed something up

And of course it's because I've made the PR from a fork. I've pushed the branch to upstream to kick of final CI.


Error in / Application

Hi, i tried to set up portal followed the documentation, it was happened in configuration, after i set the address and, user name and password, also choose the portal. And then this error showed up.

Is there anything wrong with configuration or missed something?

What versions of the various features in the system requirements are you using? Operating system, Dynamics 365 version, .NET framework, Visual Studio, etc.

I'm using, Windows Server 2012 R2, Microsoft Dynamics CRM 2016 (<IP_ADDRESS>5) (DB <IP_ADDRESS>5), .NET 4.5.2, and Built Using Visual Studio 2017 Community Edition.
I tried before in CRM 2016 (<IP_ADDRESS>9) (DB <IP_ADDRESS>9) no problem like this happened, successfully portal displayed after configuration. Could it be incompatible with this version (Microsoft Dynamics CRM 2016 (<IP_ADDRESS>5) (DB <IP_ADDRESS>5))?

I'll test on the same versions and see if I can reproduce the error.

Please update your CRM 2016 installation to the newest supported build of the 8.1, Bing Maps AJAX Upgrade for Microsoft Dynamics 2016 Service Pack 1, version <IP_ADDRESS>0. If there are any issues we'd only be able to address them against the newest version.

I've successfully tested with Windows Server 2012 R2 and CRM 2016 version <IP_ADDRESS>0, hopefully you find the same as well.

just update the crm into <IP_ADDRESS>0, and still get the same error, did i miss something?

It's hard to say, most information I can find on this error has to do with using old CRM assemblies that need to be updated, but those assemblies should already be coming from NuGet packages that work fine.
We need to try isolate the issue. Assuming your CRM organization loads fine when accessing it directly in your web browser, my guess is something is missing on the web server hosting the portal. I would try to host the portal from some other machines and different operating systems to see if the issue occurs on the other ones as well. A simple test would be to deploy the MasterPortal project to an Azure web app. The free tier should work and I've deployed to azure web apps without issues. If the error still occurs there could be an issue with the CRM server. If the issue goes away, something about your web server could be the cause of the problem.

I'm closing this due to inability to reproduce.


[Map] Clicking a marker (point LOI) does not select the LOI

Verified occurring at HEAD; this issue predates refactor #2157.
https://github.com/google/ground-android/assets/228050/71fc0a1b-9eb0-40bf-9ded-de817dfeb3ef

I tried using the below code for adding click events for map markers, but it is not working. Documentation
map.setOnMarkerClickListener {
      Timber.d("Marker clicked" + it.toString())
      true
    }

I tried using the below code for adding click events for map markers, but it is not working. Documentation
map.setOnMarkerClickListener {
      Timber.d("Marker clicked" + it.toString())
      true
    }

Did you add it to the markers being added by PointRenderer? If you add it to the ones created by FeatureClusterRenderer it won't work since those are not displayed.

This listener is added to GoogleMap object and not the individual markers.

This listener is added to GoogleMap object and not the individual markers.

When I try this I get the following warning:

Using this method may override behaviors set by the Maps SDK for Android Utility Library. If you are not using clustering, GeoJson, or KML, you can safely suppress this warning, otherwise, refer to the utility library's migration guide: https://bit.ly/3kTpQmY

Digging deeper, it appears ClusterManager is using a class called MarkerManager which overrides the default listeners.
To fix this, we should extend MarkerManager, overriding onMarkerClick(). The overridde impl should be passed through an update constructor of FeatureClusterManager, for ex, in FeatureManager:
fun onMapReady(map: GoogleMap) {
  ...
  clusterManager = FeatureClusterManager(context, map, MarkerManager(map) {
    override fun onMarkerClick(m: Marker) = super.onMarkerClick(m) ||  this@FeatureManager.onMarkerClick(m)
  })
  ...
}

Thanks Gino!


Searching for vuln reporting info outside of GH's security.md

For the Security Policy field, some projects that use GitHub do have a documented security policy, but are not using the GitHub Security Policy feature, so scraping just for GH's Security Policy via security.md would inaccurately show a false in this field.
I think this is most commonly seen with projects that were established before the Security Policy feature, or for projects mirror to GitHub.

Please provide an example repo (and file path to policy).

Yeah, if you could point us at a few examples that would help!

We want to make this discoverable by people, so standardizing on github security policy makes sense here. we also support the default community health files as well. So closing, if you have examples, feel free to reopen.


TestDoHExchange is flaky

I've started to see the following failure appear in Travis builds:
--- FAIL: TestDoHExchange (10.00s)
	client_test.go:603: failed to exchange: Post https://dns.cloudflare.com/dns-query: net/http: TLS handshake timeout

This is a network request so the failure is external to the test itself and may be a slow network from the Travis container.

@tmthrgd cloudflare is blocking some servers if the servers sent many queries, they may blocked Travis servers.

[ Quoting<EMAIL_ADDRESS>in "Re: [miekg/dns] TestDoHExchange is ..." ]

@tmthrgd cloudflare is blocking some servers if the servers sent many queries, they may blocked Travis servers.

These global recursive servers all have a per-IP block when the qps gets to
high.

That's very surprising of them, and certainly not how I would have expected them to respond. I suppose traffic from other Travis users really could be substantial tohugh.
@semihalev I would have expected an HTTP error not a TLS timeout in that case though. What error did you see?

$ curl -v https://<IP_ADDRESS>/dns-query
* About to connect() to <IP_ADDRESS> port 443 (#0)
*   Trying <IP_ADDRESS>... Connection timed out
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host

same timeout here also. The test can be change to https://dns.google.com

[ Quoting<EMAIL_ADDRESS>in "Re: [miekg/dns] TestDoHExchange is ..." ]

$ curl -v https://<IP_ADDRESS>/dns-query
* About to connect() to <IP_ADDRESS> port 443 (#0)
*   Trying <IP_ADDRESS>... Connection timed out
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host

same timeout here also. The test can be change to https://dns.google.com

Trust me; Google does the same.

I have seen pull request, DoH looks like revert so this will be like no problem anymore.


Fix a minor typo.

Hey @amitmerchant1990, it seems that that typo has been already fixed here: https://github.com/claudiodangelis/qr-filetransfer/pull/14
Thanks for reporting!


Consider dynamic linking ANCM V2

Both other IIS modules and dotnet.exe are dynamically linked and it seems to be recommended for dlls

@pan-wang was there a reason to static link ANCM?

https://github.com/aspnet/IISIntegration/pull/1230


Fix Docker build directory visibility

The project Dockerfile lives in a ./docker directory, but references
files hosted in the root directory, namely:

.nvmrc
setup.py

Dockerfiles can only reference files in the same folder as the build
context. This results in build errors reported in
https://github.com/Netflix/dispatch-docker/issues/2 and initially
addressed in https://github.com/Netflix/dispatch-docker/pull/1
ERROR: Service 'web' failed to build: COPY failed: stat
/var/lib/docker/tmp/docker-builder448268992/.nvmrc: no such file or
directory

This is a simple fix to move the Dockerfile into a reasonable scope via
symlink. However, open source contributors cannot build the image
locally since the build steps appear rely on access to resources on
Netflix internal network.

Was literally just looking at this error. You're correct I need to break an internal dependency (it's not needed).

@kevgliss the changes you made mean I can build the image locally now.
One last problem: the docker build expects ./docker.env to exist. I imagine you don't want local developer changes checked in to version control.
A pattern I see in projects is a .env.example or a .env.schema file with empty fields that a developer can copy over and fill out themselves.
I'd recommend the following:

echo docker/.env >> .gitignore
echo '' > env.example
Update the README to instruct developers to copy and update the file before building

Do you agree?

That pattern sounds reasonable to me, I believe we follow it in dispatch-docker: https://github.com/Netflix/dispatch-docker/blob/master/.env.example


Pressing "View  Diff" causes a DUMP

Hello colleagues,
When I'm Importing the Objects (CLASS) into the repository, I see expected difference in the code line. When I click "View diff" I get a short dump:
Dynamic type conflict
MOVE_CAST_ERROR
CX_SY_MOVE_CAST_ERROR
The issue is caused in the beginning of the Constructor:
mo_repo              ?= zcl_abapgit_repo_srv=>get_instance( )->get( iv_key ).
P.S. I'm using 1.94.0 version
Thank you.

can you help adding a screenshot of the dump, or a reference to the line number / method

Sure!
here  they are

I guess that's an offline repo? It's most likely due to #3283. I'll have a look.


Do not bundle cherry-picked lodash functions for cjs & es targets

Before PR:

Destination: dist/cjs/reas.js
Bundle size: 180.92 KB, Gzipped size: 40.12 KB

After PR:

Destination: dist/cjs/reas.js
Bundle size: 64.93 KB, Gzipped size: 14.2 KB

That's 65% reduction 😉 Ofc those lodash deps will have to be bundled too, but at least they should deduplicate between packages, which is not possible if you bundle them into your source code.

Codecov Report

Merging #24 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master      #24   +/-   ##
=======================================
  Coverage   94.62%   94.62%
=======================================
  Files           9        9
  Lines          93       93
  Branches       29       29
=======================================
  Hits           88       88
  Misses          5        5

Impacted Files
Coverage Δ

src/utils/isSVGElement.js
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Thank you so much, @Andarist.
I'm always struggling with those bundling stuff 😅


Nothing Happens When You Click On Continue After Getting Authentication Failure Message

The Issue
Nothing Happens When You Click On Continue After Getting Authentication Failure Message At The App Start Up
Steps to Reproduce

Close LBRY app from the taskbar/ kill LBRY process
Change date and time settings to some months back(maybe 2 months back)
Open LBRY app and you get Authentication Failure
Click continue and nothing happens

Expected Behaviour
Tell us what should happen.
When the user clicks continue, something should happen, or warning message like (check time and date settings and try again)
Actual Behaviour
Tell us what happens instead.
Nothing happens when you click continue
Suggested Solutions
Tell us your suggested solutions if you have any.
I solved this problem of Authentication failure by making sure the system time and date was correct, once it was set correct, the message never comes up and lbry loads fine, so there should be a message that prompts the user to make sure their date and time are correct when they get the Authentication Failure message. this message can pop up when they click continue as nothing happens when continue is clicked as at now
System Configuration

LBRY Daemon version: 0.20.2
LBRY App version: 0.22.0
LBRY Installation ID: 	42HthHLazo5VAqJvoditQUxCkTm7QxNKyuJt5idW593ektCzUR5fdLnqWTKje9Pcdo
Operating system: 	Windows (Windows-10-10.0.15063)

Anything Else

The Authentication Failure  message was due to the time and date being wrong and dating back to April 2018, no amount of troubleshooting got the app to load pass the Authentication failure issue can be reproduced in the same way mentioned above
Screenshots

https://cdn.discordapp.com/attachments/440189329139171350/464495435814273055/date.JPG

Thanks for filing this Clement! It could be a modal issue with the continue button. If someone does continue, I don't think the app will function correctly without an API key, but that case might be different for the date/time issue.
Can you tell if an API key is passed via the network tab when this occurs?

it only gives err_insecure_response, the insecure response in my opinion is cos of the wrong date/time.
usually that is what you will get in an actual web browser when the date is wrong, you get certificate error and insecure connection error
another thing i just saw was when i click anywhere on the page, it reloads, anywhere on the lbry app
https://cdn.discordapp.com/attachments/440189329139171350/464561321489334332/unknown.png

@seanyesmunt I'm guessing this is another close modal issue, I'll try to take a look myself :)

Keyring has been removed, this should no longer be an issue


Animations on MainActivity break after ad is loaded

Adding this line of code seems to fix the problem
adView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
https://code.google.com/p/android/issues/detail?id=70914


feat(tauri): tray-app mode

Back

[x] Positioned under the tray icon
[x] Open and close when clicking on it
[x] Cannot use the window's controls
[x] Not in the dock
[ ] Toggle-able
[ ] Save state
[ ] Handle decorations (titleBarStyle)

Front

[ ] Cannot drag window
[ ] No header
[ ] No done button
[ ] List mode
[ ] Way to toggle between normal and tray mode

Closing in favor of #183


static-inline generates incorrect guards

For the following program:
import "primitives/core.futil";

component main() -> () {
    cells {
        idx = std_reg(4);
    }
    wires {
        static group incr<1> {
            idx.in = 4'd10;
            idx.write_en = %1 ? 1'd1;
        }
    }
    control {
        static seq {
            static par {
                incr;
            }
        }
    }
}

The following command:
cargo run -- tests/correctness/static/static-mult-dot-product.futil -p dead-group-removal -p validate -p static-inline -p simplify-static-guards

Generates:
...
component main(@go go: 1, @clk clk: 1, @reset reset: 1) -> (@done done: 1) {
  cells {
    idx = std_reg(4);
  }
  wires {
    static group static_seq<1> {
      idx.write_en = !1'b1 ? 1'd1;
      idx.in = %0 ? 4'd10;
    }
  }

  control {
    static_seq;
  }
}

Note that the guard for idx.write_en is false which means the program will never write a value into idx.

I'm reading the static inlining code and I'm not sure if it makes sense. It doesn't seem to implement the inlining technique described in #1344. Specifically, the approach in that overview is that we should keep track of the current relative time when compiling a control operator and only update the guards once we reach an enable.
The current inlining code seems to transform each control operator separately and then & together the guards generated by each level.

Hm, nevermind, I'm wrong. update_timing_assignment seems to be the function that does that but it relies on recursively calling inline_static_control on each of the children of a control program. This means that an assignment in a group nested n levels of seq or par deep, the assignment will be updated n times. This $n^2$ behavior for rewrites is probably not a good idea.

The problem seems to be the assignment:
idx.write_en = %1 ? 1'd1

If I remove this, the example works. This was initiated by me trying to rewrite the static-mult-dot-product test but I see that it's already a test but it doesn't define assignments in the way I wrote them here.

Also, note that this test doesn't work with Icarus for some reason. Running the following command produces an array of all zeroes which means something is wrong:
fud exec --to jq --through icarus-verilog --through dat -s futil.exec './target/debug/futil' -s futil.flags '-p all -d tdst -d group2invoke' -s verilog.cycle_limit 500 -s verilog.data tests/correctness/static-control/static-mult-dot-product.futil.data tests/correctness/static-control/static-mult-dot-product.futil

A further problem is that the inlining process cannot inline the par into the seq which means the resulting code allocates two FSMs when it should only really need one.

I see. Just so we're on the same page:

As you note, the static-inline pass is inefficient right now. If an assignment is written at $n$  levels of nesting, then it gets rewritten $n$ times (This is also why the guards generated are redundant, and the motivation behind the simplify-static-guards pass). Ideally, we would only need to rewrite the assignment once (when turning the "static island" into a static group). I think this would require having some sort of data structure that maps groups to their appropriate "offset", and then, at the end when we're compiling the static island into a single static group, we should "realize" the offsets just once by rewriting the assignments. I think I can take a shot at simplifying this so that the assignments are only rewritten once.
I think the icarus-verilog issue might stem from #1354, in which external cells do not have their reset port inserted. I can read the related issues and try to fix this.
About the last comment:

A further problem is that the inlining process cannot inline the par into the seq which means the resulting code allocates two FSMs when it should only really need to allocate one.

I think (you can correct me if I'm wrong) you're referring to the fact that there are two fsms that are generated when we compile your Calyx program (i..e, the one in the original comment) using static-inliner and compile-static. What's happening right now is that static-inline is creating a bunch of unused groups (for the same reason that it is inefficiently rewriting the assignments in nested groups) and is therefore unnecessarily instantiating fsms that we will never use. If we compile this all the way down (with dead-group-removal and dead-cell-removal optimizations) then it will only generate one fsm. Either way, though, there are still inefficiencies in the current static-inline implementation that we should probably fix.

Ideally, we would only need to rewrite the assignment once (when turning the "static island" into a static group). I think this would require having some sort of data structure that maps groups to their appropriate "offset", and then, at the end when we're compiling the static island into a single static group, we should "realize" the offsets just once by rewriting the assignments
That's right! That's the difference between a bottom-up vs top-down approach. Currently, the pass goes down to the innermost control operator and compiles it fully before popping back up. I will note that the nice thing is that I don't think the generated code would get any better, especially after running guard simplification. You could consider opening an issue about this and working on it as a part of the QoR/overall compiler improvement push later and not block static proposal being done on this working.

Note that we end up generating two FSMs because the inliner did not merge the static_seq and static_par groups together.

Ah, I see what you're saying. In my mind, this was actually expected since the static_par is the body of a static repeat.  Just to be safe, I decided to keep separate fsms for bodies of static repeats to avoid complicated guard expressions with lots of or's (e.g., a.write_en = %2 | % 5 | % 8). However, there are cases where we probably do not need to do this, such as this case: the body of the static repeat has a latency of one cycle, so we don't really need to worry about complicated guard expressions in the body of the static repeat. The cases where we want to keep the same fsm to coordinate the body of a repeat vs. having a separate fsm may be another heuristic/QoR question.

@calebmkim Got it! Looks like there are two separate issues here. One, you've already summarized in #1447. The other one is to do with how guards work in groups which is a bonafide bug and needs to be fixed. Does that make sense?

The other one is to do with how guards work in groups which is a bonafide bug and needs to be fixed. Does that make sense?

Sorry, I'm not quite clear on what you're referring to here? I think the icarus-verilog giving only zeroes is solved by #1446. The "two separate fsms" problem seems to me more of a QoR type of thing. The idx.write_en = %1 ? 1'd1 is out of bounds static timing, which I think is (from no on) going to be deteced by #1443.

Sorry, that PR does not fix that problem. We should have a higher-level error before we hit lowering: https://github.com/cucapra/calyx/issues/1444


9 poc unknownip authenticator

This first POC of the Authenticator has 3 Options for the email:
Always: an e-mail is always sent.
Unknown IP: An e-mail is only sent when the user has never logged in with this IP address.
On Change: An e-mail is only sent when the user logs in with a different IP address compared to the last time. (not implementet)

Merged in https://github.com/B2-Code/Keycloak-GeoAware/pull/13


Complete Documentation for Best Practices

The Best Practices is a list of things that the Project should follow. Following items are pending:

Basics

The information on how to contribute SHOULD include the requirements for acceptable contributions (e.g., a reference to any required coding standard). (URL required)

Reporting

If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private. (URL required)

Quality

It is SUGGESTED that this policy on adding tests be documented in the instructions for change proposals.

Added Security Reporting section to the homepage.

Extended the README.md with information about how to join and what is expected for new committers.

Closing, completed.