Fix for #6696 : Added persist_directory to client_settings if persist_directory is not None in Chroma

Description:

Fixed an issue in Chroma Integration : Add persist_directory to client_settings if persist_directory is not None.
Added Tests for chroma integration to test persistence with client_settings.
Issue: https://github.com/hwchase17/langchain/issues/6696
Maintainers :  @dev2049 @eyurtsev @rlancemartin

Thanks!

stale, believe client instantiation has been fixed. let me know if you're still seeing issues @jaikarnyu!


Sort by "Performance"

I was solving some performance katas recently (such as prime streaming PG-13/NC-17 and The Millionth Fibonacci) and I thought it would be cool if under the 'solutions' tab after you have solved a kata, you can filter by the amount of time the solution took to pass the full test suite.
Sort of like this: (numbers made up) (excuse the messy-ness)

I agree on that. And filter by language. This way you can see how your solution was compared to others with same language. But also globally with all languages.

Duplicate of #2036 #1754 #1133 #959 . See related issues for explanation why it's not as good idea as it might seem.


How to use access token for authorization instead of identity token

Question
Hello,
I am trying to use .AddOpenIdConnect() middleware to integrate IdentityServer4 in AdminUI project, below is configuration options for same.
Grant Type: Implicit
AdminUI.Startup.cs file:
.AddOpenIdConnect(Authentication.OidcAuthenticationScheme, options =>
                    {
                        options.Authority = https://IdentityServerUrl;
                        options.RequireHttpsMetadata = false;
                        options.ClientId = ClientId;
                        options.ClientSecret = ClientSecret;
                        options.ResponseType = OpenIdConnectResponseType.IdTokenToken;

                        options.Scope.Clear();
                        options.Scope.Add("openid");
                        options.Scope.Add("someApiResource"); // apiScope with associated claim types
                        options.ClaimActions.MapAll();
                        options.SaveTokens = true;
                        options.GetClaimsFromUserInfoEndpoint = true;
                    });

The above code was working as expected but recently I have added custom claims from ID4's user profile service. But I am adding those extra claims which are associated with requested ApiScope which means consumer needs to pass that ApiScope in request (like I have added someApiResource scope), so those associated claims would get added in the access token, not in IdentityToken. I understand that to add extra claims in IdentityToken I need to associate IdentityResource with custom claim type (for me which is not acceptable/expected).
Issue
When I added a breakpoint in my controller and explores User object I can see only basic claims and custom claims are missing from User identity. After hours of investigation, I understood that it uses IdentityToken and not access token (which is normal behavior for secured API).
So my question is am I doing something wrong here? Is there any option so I can use access token instead of identity token to fill User object?
This is more like a question and not a bug, but I am asking here for better reach if anyone else facing a similar issue with the Admin UI project. Any article link or sample code would be helpful.
Thanks

Hi,
If you want to use claims for your client - you need configure identity resource. Why do you want to use access token claims for your client? Thanks

Postman call authorization to get token always fails, no friends have encountered
Very similar to yours, I want to use js to call the authorization server to get the token

If I get it right, you want to bring identity resources to your access_token instead of id_token (or both)? Please take a look at IProfileService interface (there is base class for it ProfileService) and method related to it. You can put everything you want in tokens. But, of course, you should keep your access_token smallest as possible.
public static IIdentityServerBuilder AddProfileService<T>(this IIdentityServerBuilder builder) where T : class, IProfileService;


Proxy doesn't work

When I try to execute this:
`
credentials = client.SignedJwtAssertionCredentials(
SERVICE_ACCOUNT_EMAIL,
key,
scope='https://www.googleapis.com/auth/androidpublisher')
httplib2.debuglevel=4
myproxy = httplib2.ProxyInfo(proxy_type = httplib2.socks.PROXY_TYPE_HTTP, proxy_host='http://proxy.my.comp', proxy_port=8080)
myhttp = httplib2.Http(proxy_info=myproxy)
authorization = credentials.authorize(myhttp)
service = build('androidpublisher', 'v2', http=authorization)
`
I get this error:
httplib2.ServerNotFoundError: Unable to find the server at accounts.google.com
I also tried to set the proxy as env-variables. For basic stuff like installing via pip it works fine, but it doesn't work with the client. But I assume it should use the environment variables if nothing is set as proxy_info in the code.
Any suggestions on this?
Thanks!

Just wasnt aware that I have to add RDNS = true. (my company doesnot support DNS-Request to outside from the local machine so I have to force httplib2 to do the DNS-Request through the proxy and not from local)

Here is working with environment variables:
http_proxy=http://proxy_ip:proxy_port
and
https_proxy=http://proxy_ip:proxy_port


Flip expected/actual arguments?

Currently, when one is used to assertions in PHPUnit (first argument "expected", second "actual"), it's easy to get the assertions in this library wrong (first argument "actual", second "expected"). What do you think about flipping the arguments and releasing a 2.0?

Hm. That is an interesting idea. But it only makes sense in some cases, right?
31 of the assertions looks like this:
isArray($value, $message = '')
26 look like this:
isInstanceOf($value, $class, $message = '')
And then there is a handful that has more parameters. But the general idea is:

first parameter is $value
last parameter is $message = ''

What they currently have in common is that all of them starts with the "actual"/$value. Switching almost half of our assertions to be similar to PHPUnit seams strange, because that will not make all our assertion coherent.
What about people that are used to how webmozart/assert does it?
Im not too happy with this change.

It depends on what you call coherent/consistent. I don't think PHPUnit assertions are inconsistent. The first argument is always "expected", the second is always "actual". If there is no "expected", then (obviously) the first argument is the "actual".
PHPUnit_Framework_Assert::assertSame($expected, $actual);

// but
PHPUnit_Framework_Assert::assertTrue($actual);

Since the majority of PHP users is (or should be) used to PHPUnit (much more than the users of this library) this should actually be an improvement in UX. I frequently happen to pass arguments in the wrong order - only to realize at some point that my assertion is wrong. That's not what assertions are for.
In any case, if we do this change, it is absolutely mandatory to me that it comes with an upgrade script that allows an automated upgrade of projects using the library.

It depends on what you call coherent/consistent

Okey. Fair.
I guess it is a matter of taste/opinion.
And I agree with the fact that one should do as every body else does if there is no obvious win doing it in an other way.
I never had an issue with the order of the arguments. And I am hesitant of bumping to 2.0 for only this feature.
I would like to hear the opinion of other users and contributors. Ping @mathroc @keradus @docteurklein. What do you think? Should we plan this feature for 2.0?

Thanks @webmozart for opening this issue, it really makes sense to me to revert assertions such as instanceOf. In fact almost all others already comply with the "expected first" concept except it's in the method name:
Assert::$expectedState($value, $message);
Assert::$expectedExression($expectedState, $value, $message)

Totally agreed on the PHPUnit style compliance, and for what it worth it's a big 👍 for me.

also, :+1: for having expected value first.
never have an issue with params order as well, but consistency with PHPUnit would be nice indeed.
Same here, 2.0 for sure, but it could be combined with more BC breakers, but only if there would be any.
I wouldn't postpone this for ages if there would be no other BC breakers.
Like recently there were postponing of minor release for 2 weeks because of some feature still in progress. Don't hesitate to make smaller releases more often.
I'm willing to help managing repo if that would be appreciated.

I prefer the current style because I read it by placing the arguments inside the function name, eg:
Assert::allIsInstanceOf($employees, 'Acme\Employee');
// assert all $employees is instance of 'Acme\Employee'

maybe that's also because I'm not often using phpunit.
but I don't mind that much as I'm not a heavy user of this lib either

At first I thought I didn't have anything against this proposition, as trying to align with other usages can only be a good thing. However, here are 2 things that just came to my mind:

is breaking BC more important than following common usage (by common I mean phpunit style)
if $expected is placed first, you won't be able to have a default value for it.

example with the Assert::throws that just landed: if you don't provide a 2nd arg, it will default to \Exception.
How would you do that with flipped arguments?
now it's only small problems (especially n° 1.): I'm just trying to bring more arguments to the discussion.
cheers!

example with the Assert::throws that just landed: if you don't provide a 2nd arg, it will default to \Exception.

For me it's very nice, so one will need to specify what he actually expects, being strict about it.
Now, especially in PHP7 world, one may be confused would default value is \Exception or \Throwable.

I tend to agree with @keradus. Explicitly stating
Assert::throws(Exception::class, function () {
    // ...
});

is very explicit, which - in the context of assertions - I think is good.

To reinforce what I already stated: I would only consider doing this change if we have a fully-automated upgrade path.

you wont easily have fully automated migration.

Project FooAssert use this Assert, then class FooAssert extends Assert.
Project App use only FooAssert, where:

$asserter = FooAssert::class;
$asserter::throws(...);

I think this is still a nice to have but as Bernhard already said:

I would only consider doing this change if we have a fully-automated upgrade path.

I hate to get the order of the arguments wrong, but having a BC break without a smooth upgrade path is a no go.

I think its safe to say that this is not something that will be changed.


Please add a list of variable names in the docs

All of the examples make use of a single variable name, 'carbonate'. I found the names of the other variables from the source code
https://github.com/gantian127/bmi_dbseabed/blob/9530b7e9d3e9f0d9588ecaf4c2d82755d7fe910f/src/bmi_dbseabed/dbseabed.py#L11
Please add a list of the variables and their description to the docs. The website  doesnt seem to contain this information (or if it does, it is hard to find). I think the KMZ probably has this information, but I am not allowed to use KMZ by my employer. Thanks

@dbuscombe-usgs Thanks very much for your feedback! I will add the variable info the in README section of this repo. Also, to check a list of all available variables, there are two ways.
method 1: use python code:
from bmi_dbseabed import DbSeabed
dbseabed = DbSeabed()
dbseabed.data_services
method2: check the list of all variable names in the docs at the section of "parameter settings"
https://bmi-dbseabed.readthedocs.io/en/latest/#parameter-settings
The tutorial notebook also mentioned these two methods. Thank you! https://github.com/gantian127/bmi_dbseabed/blob/master/notebooks/bmi_dbseabed.ipynb

Thanks for that information. I am starting to realize that data is only available for the Gulf of Mexico, is that right? The 'data link's in the docs point to geotiffs that only cover the Gulf of Mexico region, and no data outside the Gulf seems to be available (see my other issue).


Add support for building documentation with VuePress

This pull request adds a config.js file for VuePress, the vue.js community's own documentation tool. This file allows you to make a static build using vuepress build (once vuepress is installed on the machine with yarn or npm).

CC: @LinusBorg

Just for clarification, use vuepress build when you are in the docs directory.

@LinusBorg Is there anything I need to add to my pull request?

hey @LinusBorg is this still planned to be merged?

No. I'm not planning on adding anything to this template.
Vue CLI 3 has been stable for half a year almost. This template won't be developed any further in favor of Vue CLI 3


[RFC][fix test] missing .item() in frozen nf4 test

Context

as titled. missing .item()
but there is another thing. I found the error from frozen-nf4 is larger than the one from bnb-linear

Changelog

updated nf4 test

Test plan

pytest tests/torchtune/modules/low_precision/test_nf4_linear.py

Thanks for your contribution @skcoirz! This was definitely an oversight on my part. Though do we understand why the current test (err.item() < err_bnb) is passing in CI?

good question. Let me dig into it.

@rohan-varma , found out the cause.

unit test is able to detect this test. (confirmed on my local server)
but in CI, the 2 accuracy tests are bypassed because there is no cuda. (confirmed in logging below)

looks integration test is handled in aws. I would assume we have GPU there? Let's mark them as integration_tests?

https://github.com/pytorch/torchtune/actions/runs/8472914261/job/23216077574

@skcoirz thanks for debugging this. Yeah this is a weird edge case. We can run this GPU test in CI but right now they are meant for more like E2E runs of fine-tuning scripts. So we can mark this test as an integration via @pytest.mark.integration_test like you suggested, but it is a bit unintuitive (e.g. it'll be our only integration test outside of tests/recipes). That said, we do need a way to catch this. Out of curiosity, @rohan-varma, why is this a CUDA test anyways? Is NF4 only supported on CUDA? Or is this more of a bnb-side thing?

We don't have NF4Linear in torchtune anymore so this PR is no longer relevant


Amplitude & Angular - low performance

Expected Behavior
The SDK shouldn't affect the overall performance of the application.
Current Behavior
The performance of our application dropped significantly after adding the Amplitude SDK. For example: just checking a checkbox takes a few seconds on mobile devices. Even the screen scrolling wasn't smooth. We have removed SDK and everything works smoothly now.
Steps to Reproduce
I haven't tried to reproduce this on another Angular project, so for now I'm adding a list of the dependencies we use in the project and class code what we use to integrate Amplitude. We import AmplitudeIntegrationModule directly into AppModule.  We call init method on application start using the initializer.

Environment

JS SDK Version: 2.11.7
Installation Method: NPM
Browser and Version: Chrome 130

Hi @grzegorzKniazuk, does the same issue happens when you open the page on a laptop browser? Could you try to turn element interactions off by init(apiKey, {autocapture. elementInteractions: false }) and turn autocapture off by ``init(apiKey, {autocapture: false })` and try again to see if reducing tracking events help?

No, I think there is no issue on laptop or high-end mobile devices. I have tested app on a few devices. For example: on Samsung S23+ I did not see any performance issues, but I saw it on Samsung A52 (I use mobile Chrome browser).
I have turned off elementInteractions and everything works fine now. Looks like this is the source of the performance drop.


improve-navigation for forgot password

Issues Identification
#1059
Closes: #1059
Description
Summary
A brief description of what this pull request does and why it is needed.
This pull request addresses a bug where the "Forgot Password" feature fails to reopen if a user navigates back to the login page and attempts to access it again.
Details
Include any detailed information about the changes in this pull request.
This fix ensures that the "Forgot Password" link is functional each time it is accessed, regardless of page navigation.
Tested across Firefox, Chrome, and Edge for consistent user experience.
Types of Changes
Steps to Reproduce
Go to the login page.
Click "Forgot Password."
Navigate back to the login page.
Attempt to click "Forgot Password" again.
Expected Behavior: The "Forgot Password" feature should be accessible each time it is clicked.
Please check the boxes that apply

[X] Bugfix (non-breaking change that fixes an issue)
[] New feature (non-breaking change that adds functionality)
[X] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update (Documentation content changed)
[ ] Other (please describe):

Checklist
Please check the boxes that apply

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

Screenshots
Before:
https://github.com/user-attachments/assets/93e5cf8d-9d9f-4113-8a33-f60a7f088739
After:
https://github.com/user-attachments/assets/bbdb16c7-fbae-4b7f-8c88-e8aa4357c0d1
If applicable, please attach screenshots of the changes made to the user interface.
Additional Information
Please provide any other information that is relevant to this pull request.

Hey @vivekvardhan2810 Could you please review this PR when you have a moment? I understand the deadline and appreciate any feedback you can provide to help keep us on track.

@saras-69 thank you for contribution to ML Fusion Lab.
your contribution gives a value to us.
now please do work on other projects.


[Removal]: Shambolic Marmalade Tapir

Hotspot Name
Shambolic-Marmalade-Tapir
Hotspot b58 Address
11deiTtJXVaBgF6QznyaUdYPu1yxJrfVknJQPgotoFvwYYcN8vT
Discord Handle
Man233#3200
Hotspot Manufacturer
PantherX
Removal Reason
I bought this hotspot on the second hand market on March 26, 2022, total 10 hotspots, but not notice it was included in the denylist, I am buying the machine now to put it in the actual location, and did it right Deployment, without any cheating, please help me get removed from the denylist, thank you!
Modifications
No
Extra forwarders
No
Extra antennas
No
Additional Information
Helium Team
Thank you very much for your contribution to the healthy development of the network. As a victim of buying banned hotspots, I sincerely hope that you can help us solve the problem of hotspots being included in the denylist. I have deployed the machine correctly, please help me Detected, and lifted the denylist, thanks again!

This the same cheater who wants to be delisted from the denylist; Please refer to #3060. The hotspot shall be remain on the denylist.


CocoaPods could not find compatible versions for pod "flutter_barcode_scanner" iOS

Description
The plugin is not working on IOS, i have the following error when running on iOS 15.0, iPhone8

To Reproduce
Steps to reproduce the behavior:

add the plugin from pub dev
add necessary configs for Info.Plist
Add UI widget
See error

Expected behavior
This is the error message that I have
[!] CocoaPods could not find compatible versions for pod "flutter_barcode_scanner":
In Podfile:
flutter_barcode_scanner (from .symlinks/plugins/flutter_barcode_scanner/ios)
Specs satisfying the flutter_barcode_scanner (from .symlinks/plugins/flutter_barcode_scanner/ios) dependency were found, but they required a higher minimum deployment target.

Smartphone:

Device: iPhone8

OS: MacOS Monterey

Version Flutter 3.7

Open the iOS project in Xcode and set minimum deployment target to 12. Then close Xcode and run pod install in /ios folder again.

Hello @petcupaula . I just did changed the deployment target to 12.0. But still, it is not working...

try updating Podfile file in ios folder to
platform :ios, '12.0'


[progressbar] Add progressbar from conda/conda-recipes

From https://github.com/conda/conda-recipes/tree/master/progressbar, since somehow that package is no longer be maintained in the main anaconda channel.

Ah. This may be because progressbar is not yet py3.x ready:
+ /Users/travis/anaconda/envs/_build/bin/python setup.py install
Traceback (most recent call last):
  File "setup.py", line 5, in <module>
    import progressbar
  File "/Users/travis/anaconda/conda-bld/work/progressbar-2.3/progressbar/__init__.py", line 59, in <module>
    from progressbar.widgets import *
  File "/Users/travis/anaconda/conda-bld/work/progressbar-2.3/progressbar/widgets.py", line 121, in <module>
    class FileTransferSpeed(Widget):
  File "/Users/travis/anaconda/envs/_build/lib/python3.4/abc.py", line 133, in __new__
    cls = super().__new__(mcls, name, bases, namespace)
ValueError: 'format' in __slots__ conflicts with class variable
Command failed: /bin/bash -x -e /Users/travis/build/omnia-md/conda-recipes/progressbar/build.sh
Removing old build environment
Removing old work directory

Can you add a skip entry then?

Can we just unmerge?

Can we just unmerge?

:).  Why not just revert?  That's easy to do from gitk

@jchodera: Is progressbar2 py3.x ready? You could consider switching to that. http://progressbar-2.readthedocs.org/en/latest/


Add chart_name to Datadog Charts app to select dashboard chart

Description
Allows people to select which chart they want to display from a Dashboard. Also adds in some better error handling if the response payload is too large.
Copilot

copilot:all

@matslina Can this be merged since there's no issue with breaking changes?

Sure thing. Just to be clear, by "the ones changing the value attribute", I meant the "chart_time_range" schema field. Existing installations will still pass in the former values, like "1d" instead of the new "24h". Guessing the API handles both?


Checklist for episode 143: CAPI Update

Monday or Tuesday:

[X] Pick a topic and create/use an issue in the repo
[X] If applicable coordinate with an upstream project if they're interested in attending the show
[x] Create the graphic
[x] Schedule on Youtube
[x] Add scheduled episode to TGIK playlist on YT
[x] Create short link in rebrandly
[x] Tweet about it from your personal account
[x] Post messages on internal #tgik slack channel and cc Vykky

Before episode:

[x] Create HackMD page for live notes.  Start with README template in this repo
Show Coordination with Assistant (if you have one)

[x] Paste HackMD URL on internal #tgik channel
[x] Assistant adds ~5-10 news items from around the web as possible "News of the Week"
[x] Confirm show time and AV check
[x] Last minute retweets or topic updates
[ ] Sync with external guest one last time if necessary

[x] Get everything tested well before episode so you can debug
[x] Use internal slack channel to ensure that AV se tup is good

After show (ideally right away but can wait until Monday):

Create/submit PR for this repo

[x] Episode directory and README from hackmd
[x] Any other files from the episode that might be useful
[x] Update playlist.md with episode
Feel free to self merge

[ ] Edit YT description to point to episode directory here
[ ] OBS/OS Upgrade if applicable (Never on the day of a show)

PR #350 is open to add episode 143 to the repository

PR #350 is open to add episode 143 to the repository

PR #350 is merged, closing this issue

PR #350 is merged, closing this issue


Staff: As staff I can review an adopter's information on their application

When logged in as staff, I can go to /adoption_application_reviews to see all of the applications on a pet. But I cannot click on the adopter name to see their information.
Every User has a Person model. So, each adopter's information is stored on the person.latest_form_submission.form_answers. This will give you a list of records, each with a question snapshot and value (answer). (Nice to know, these form answers will come from a CSV uploaded by staff that matches the Person's email with a response in the CSV from a form like Google form). We need to show these questions and answers to the staff. Note, that we don't need to worry about grouping questions, for MVP we will just show a list of questions and aswers, however they come in the CSV (it's likely grouped in the original form anyway so that grouping should be loosely retained here).
To do:

add a route and show action for Organizations::Staff::AdoptionApplicationReviewsController that will show the adopter's information. This information is stored as form answers on the adopter's Person model's latest_form_submission.
authorize the route to make sure the staff is in the same organization as the adopter, and has review_adopter_applications permission
add the adopter's name as a link in the table for adopter applications, and when I click on it, redirect me to the show page
the show page will be very simple, rendered in the staff dashboard per the sketch below
I think the edit route/action on this controller is redundant - please check and remove it if so
Please add some seed data so each adopter user has some form answers on their form submission

Questions and answers

@kasugaijin Will Please Assign this

@Aaryanpal how's this going?

Issue up for grabs!

Hi @kasugaijin I would like to work on this issue if it is still open..

All yours @sarvaiyanidhi

Hi @kasugaijin ,
I believe that I need to upload some sample data from this location staff/external_form_upload
Do you have any sample format of CSV which can be used to upload details, basically I need to know apart from person email field what all other fields needs to be uploaded?
Not sure if required but I think we should also provide sample CSV format to download so that user can update data in it and upload it  back.

@sarvaiyanidhi for this there’s no defined dataset per se. We need to take the users latest form submission and then iterate over all of its form answers and show the question and response. You can make up whatever you like for the dummy data in the tests. For example you could include
Have you owned a dog before
What kind of housing do you live in
What’s your preference for dog temperament
How much have you budgeted for a dog per year
Etc etc.
ChatGPT will be good if you ask it for 10 questions on a dog adoption form

Thanks @kasugaijin , I was just trying to upload sample CSV from /external_form_upload path but nothing was getting inserted in form_answers table so I thought I am missing something.. Never mind I will update seed data to insert some data in form_answers as well which can be used to display in required functionality.

Yeh we might need to update the seed adopter account to have a form submission. If the adopter doesn’t have a form submission I don’t think it will upload. On my cell right now so can’t look at it just yet

Also double check your CSv has the date time. Check the csv import service for what it looks for

Sure thanks.. Will check it and try to upload accordingly

@sarvaiyanidhi I have a csv file linked in #1112 that might help you. That should add a few form submission to "Alta" adopters. The email has to match a user in the db. You will probably want to watch the logs during upload as we currently do not have any UI indications for success/failure.

Thanks @jmilljr24 I was able to get few sample form_answers updated using sample CSV. Just one question, I see that question_id is nil for submitted_answers so I think I need not worry about that data for this feature?
@kasugaijin Using sample CSV, we have below details updated in forms_answers table along with other values like form_submission_id, organization_id
|  value  |  question_snapshot |
|  Emile |   First Name             |
|  Mills   |   Last Name             |
|  "74936 Kiesha Turnpike, Port Tarshaton, ME 18261-0840"   |   Address   |
| "452.143.5817"  | Phone Number |
|  "Sunt placeat quod."  | "What type of pet are you interested in adopting? (Dog, Cat, Other)"|
|  "Velit eos officiis." | "What is your living situation? (House, Apartment, Condo, etc.)" |
--- more
Just want to confirm that when I am displaying information in new screen, I will also be displaying details like First Name, Last Name, Address, Phone Number along with other questions as I will loop through latest form_submission_answers or  I need to filter these details like Name, Address etc and just display generic questions (like What type of pet are you interested in adopting? (Dog, Cat, Other))  and answers?

@sarvaiyanidhi for now let’s display all of the associated form answers (question and answer). No need to filter anything


WASM: Fallback to parsing SDP line for OnICECandidate

On Firefox, the RTCIceCandidate interface appears to just be an RTCIceCandidateInit in disguise. That is, it does not have properties for each individual component of the candidate line. It only has the raw SDP string in the candidate property.
This change falls back to parsing the candidate line if some expected property is missing when preparing the candidate for the callback OnICECandidate.
https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandidate
https://caniuse.com/#feat=mdn-api_rtcicecandidate_priority
Let me know what you think!

Nice catch!
This changes makes sense to me. Would you be able to add a simple JS test? If you don't have the bandwidth I am happy to take it :)
This also failed some of our linters, mind taking a look at them? If you don't have the time happy to cherry-pick and fix myself :)
2.04s$ bash .github/assert-contributors.sh
Please add the following contributors to the README
salman aljammaz
salmān aljammāz

0.02s$ bash .github/lint-commit-message.sh
WASM: Fallback to parsing SDP line for OnICECandidate
On Firefox, the RTCIceCandidate interface appears to just be an
RTCIceCandidateInit in disguise. That is, it does not have properties
for each individual component of the candidate line. It only has
the raw SDP string in the candidate property.
This change falls back to parsing the candidate line if some expected
property is missing when preparing the candidate for the callback
OnICECandidate.
https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandidate
https://caniuse.com/#feat=mdn-api_rtcicecandidate_priority
-------------------------------------------------
The preceding commit message is invalid
it failed 'Limit the subject line to 50 characters' of the following checks
* Separate subject from body with a blank line
* Limit the subject line to 50 characters
* Capitalize the subject line
* Do not end the subject line with a period
* Wrap the body at 72 characters

Sounds good, I'll address lint later today.
A side note: would it be more portable if OnICECandidate took ICECandidateInit instead of ICECandidate as argument? It would save us decoding the string only to re-encode again, and it would mirror AddICECandidate.
Obviously it would break the API. Maybe something to consider for v3.

Added a simple test for both webkit and firefox styles.

@saljam :fire: so excited to see you contributing :)
Would it be helpful if I tagged a new version? Are you interested in getting involved in Pion? Would love to add you to the Pion org. Then you can review other peoples PRs (and create branches and tag yourself)
No really commitment, just looking to get more people involved. Would love your helping making all the WASM stuff better!

Glad I can help! Hopefully there's more, time and bandwidth permitting. I'm still finding my way around the codebase.
The changes I have that use this aren't going to be ready for a while, so no rush for tagging a release.


ion-searchbar not working with --prod flag

Ionic version:
[ ] 2.x
[x] 3.19.0
[ ] 4.x
I'm submitting a ...
[x] bug report
[ ] feature request
Current behavior:
When building using the production flag: "ionic cordova build android --prod" or "ionic cordova build ios --prod", the ion-searchbar does not trigger searches and cannot be closed either once open (Cancel button has no effect).
Expected behavior:
ion-searchbar should work normally
Ionic info:
cli packages: (/Users/rob/Desarrollo/Git/consultorio-movil/node_modules)

    @ionic/cli-utils  : 1.19.0
    ionic (Ionic CLI) : 3.19.0

global packages:

    cordova (Cordova CLI) : 7.1.0

local packages:

    @ionic/app-scripts : 3.1.6
    Cordova Platforms  : android 6.3.0 ios 4.5.4
    Ionic Framework    : ionic-angular 3.4.2

System:

    ios-deploy : 1.9.2
    Node       : v8.7.0
    npm        : 5.5.1
    OS         : macOS High Sierra
    Xcode      : Xcode 9.2 Build version 9C40b

Environment Variables:

    ANDROID_HOME : not set

Misc:

    backend : pro

Hello! Thank you for opening an issue with us!
Please try using @ionic/app-scripts version 3.1.7. It contains this fix: https://github.com/ionic-team/ionic-app-scripts/pull/1353
Thank you for using Ionic

Thanks a lot @kensodemann , it's working flawlessly with @ionic/app-scripts version 3.1.7.

Excellent!!


Definition of an unknown position

Currently, structure feature unknown_positions is defined as the following:

unknown_positions: This flag MUST be present if at least one component of the cartesian_site_positions list of lists has value null.

Taking crystallographic structure descriptions in CIF format into consideration, this seemingly means "explicit sites with unknown coordinates". However, there might be implicit sites such as:

Attached hydrogens. Sometimes hydrogen coordinates are left undefined. Instead, their number is listed as a property of the atom they are bound to.
Solvent molecules. These are usually left out, and this fact is not necessary documented.
Other non-modeled sites. Existence of them in a crystal could be inferred from mismatch of the given and the calculated formulae (not as a rule, though).

How should we deal with these implicit sites? Are they important enough to be listed in species_at_sites, and, in turn, affect the unknown_positions?

I suppose we could greatly expand the specification text on how to handle these systems. However, it is clear to me that the only feature we support for this is via null in cartesian_site_positions.
Hence, my, possibly naïve, view of how these possibilities for unknown coordinates would be represented in the present OPTiMaDe specification is that you have to add ALL atoms that conceivably can be said to be "in the structure" to species, species_at_sites and correspondingly pad out your cartesian_site_positions. If you know where the atoms are, you specify the coordinates. If you don't know where they are, you set the coordinates to null.
So:

Attached hydrogens: you make sure you have hydrogen in species, and you add extra hydrogens to species_at_sites and cartesian_site_positions. There presently is no way in OPTiMaDe to indicate that they are bound to a specific atom without specifying the coordinates, so you just set the coordinates for these hydrogens to be null, null, null. (You could e.g., add an _exmpl_bound_to_site member to the species definition inside species to retain the information about which site they are bound to. Perhaps we want to standardize this in a future version.)
Solvent molecules: are they regarded as part of the structure and included in the formula or not? If yes, then you add them to species_at_sites and cartesian_site_positions, if no, then you leave them out and what we refer to as "the structure" contains no unknown positions.
Other non-modeled sites: as far as I see we don't really allow a mismatch between a given and calculated formulae. So, add atoms to sites, species_at_sites and cartesian_site_positions with coordinates null, null, null until the given formula holds.

But this is coming from someone who more or less never have done anything useful with structures with unknown positions. So, if the above doesn't work, I guess there is no other option but to exclude these structures from OPTiMaDe access until the features that allow such systems to be described have been added in a future OPTiMaDe version.
As I recall, the discussion around issue #50 and #93 did call for input from anyone who works with these structures to add their input on what needs to be described.

I completely agree with you about adding the implicit sites to cartesian_site_positions with null coordinates.
However, implicit sites are seldom explicitly described in CIFs. (For example, COD entry 2006714 contains 4 implicit water molecules, and this is evident only from formulae mismatch). In some cases only the mismatch of given and calculated formulae will signal about the implicit sites. Also the mismatch might be due to typographical mistakes and so on, so this method should not be trusted ultimately.

As I recall, the discussion around issue #50 and #93 did call for input from anyone who works with these structures to add their input on what needs to be described.

Yes, I remember these discussions. It's possible that the issue of implicit sites did not occur to me then.

On a general level, in the difficult case you talk about you are dealing with an ambiguity in your source data (typo error or implicit sites), and you are essentially saying "I cannot carry this ambiguity over to the OPTiMaDe representation."
And IMO it is a good thing that you cannot.
There are two ways we could handle this situation:

We extend OPTiMaDe to allow you to represent the ambiguity on a per-structure basis.
We only allow non-ambiguous data to be represented in OPTiMaDe, meaning database providers are forced to make the decision on how to resolve ambiguities, rather than pushing this difficulty onto users.

I am very much in favor of '2' over '1', since I don't think a good format should allow ambiguity. An option for a provider with ambiguous data is to still serve it in an alternative database where one on database-level (rather than structure-level) indicates that these are structures the provider are unsure about.
Hence, specifically for the CIF case, I'd suggest:

If you are very sure what is going on based on formula mismatch, then you modify sites, species_at_sites, cartesian_site_positions so that they are accounted for. Perhaps with a note added in, e.g., an _exmpl_notes field that this was done.
If there is a formula mismatch but which cannot clearly be interpreted, then I would make the decision if the data I am serving is supposed to be a "high reliability" production database, in which case I would reject these structures. If not, I would include them with my best guess resolution of the ambiguity. (But then it would be a bug in my database if that resolution was done incorrectly.)

I am also in favor of option 2. Pinging @sauliusg as here we're close to dealing with policy decisions of the COD.

Hi, thanks for pinging.
I think data interpretation depends very much on application, and since database does not know what is the intended application it should not (and actually can not) interpret the data, but rather should represent faithfully what is known about the structure.
I agree, regarding option 1, that we can not represent all ambiguities that may be present in experimental structures, and we should not do this (otherwise Optimade JSON will duplicate the CIF framework, and there is not point doing that).
I would be in favour of modified option 2, in the following sense:

we drop the strict requirement that calculated summary (Hill) formula matches the one provided by the database;
we drop the requirement that all unknown atoms are present in the sites list; thus, atom sites
we specify in the 'unknown_positions: "yes"' data item that the atom list is not complete.

Regarding 1: it makes little sense to require that both declared summary formula and formula calculated from coordinates match – client can easily calculated formula itself, and the declared formula becomes superfluous and confusing (broken SPOT; denormalised data). I would instead use the difference to indicate how many atoms are actually missing from the coordinate list;
Regarding 2: if the atoms with unknown coordinates can be inferred from the summary formula and/or species list, why should we bother and waste the bandwidth sending 'null' coordinates? The 'null' coordinates (later converted to NaNs) have sense if we know one atomic coordinate (say x=0 since an atom is on a special position) but not the others;
Regarding 3: this is a sole bit that allows to include/exclude structures with unknown coordinates in searches, and an indicator that some atomic coordinates are really missing. No need to send or check 'null' coordinates in the coordinate list; the flag would be sufficient.
This method would allow to represent all ambiguities present in experimental structures without over-interpreting the data. Some information would be lost, but the flag 'unknown_positions: "yes"' gives a clear indication that unknown atomic features are present, and the client can then get the full CIF with complete description if needed.
Does that seem like an acceptable compromise?

@sauliusg your proposal overall looks fine, however:

I'm fine with Hill formula not matching the calculated one. But I'd rather not have to textually parse the Hill formula field to deduce the amount and types of atoms left out of species, species_at_sites, and cartesian_site_positions. Aside being inconvenient, it also seems that parsing would easily be ambiguous, and we should try to avoid built-in ambiguities in the OPTiMaDe representation. So, in my opinion, this requires one additional field that somehow makes precise the species and counts of unknown atoms.
This proposal interferes with my last proposed solution of #258. If we want to adopt that solution to allow for the case where a database cannot easily query for unknown_positions being present or not (which apparently is the case for COD), we may want to make sure the presence of unknown_positions affects structure data "inline", i.e., so that it is very difficult to "misinterpret" a response for an incorrect structure (e.g., leaving out all atoms at unknown positions.)

Also, are we trying to push this for v1.0? Or can we keep the bandwidth-wasting nulls we have right now for v1.0?

I'm fine with Hill formula not matching the calculated one. But I'd rather not have to textually parse the Hill formula field to deduce the amount and types of atoms left out of species, species_at_sites, and cartesian_site_positions. Aside being inconvenient, it also seems that parsing would easily be ambiguous, and we should try to avoid built-in ambiguities in the OPTiMaDe representation. So, in my opinion, this requires one additional field that somehow makes precise the species and counts of unknown atoms.

I perfectly agree with your suggestion No. 1. Although parsing the Hill formula is not a big deal, having the summary formula encoded in JSON saves us specification of the Hill formula grammar, extra parser and removes the question of the element order.
Just – do we want it for 1.0? I would see this as a further development, thus appropriate for v1.1. We can probably live with Hill formulae for now.

But is parsing the Hill formula guaranteed to always yield an unambiguous fixed set of missing atoms? Right now the v1 specification has an unambiguous representation of unknown atoms: include them like any other atoms and set their coordinates to null, null, null. It seems to me it is better to keep that unambiguous representation and do the whole change (including the extra field) in the next version?

2. This proposal interferes with my last proposed solution of #258. If we want to adopt that solution to allow for the case where a database cannot easily query for unknown_positions being present or not (which apparently is the case for COD), we may want to make sure the presence of unknown_positions affects structure data "inline", i.e., so that it is very difficult to "misinterpret" a response for an incorrect structure (e.g., leaving out all atoms at unknown positions.)

The difficulties of querying unknown_positions are implementation problems; though unpleasant, they are not so much an issue.
But when you duplicate information in several fields (flags and coords), then how do you know which is correct? You will say that specification says "they MUST match", but then what is the point of repeating the same information? And if you say that sloppy clients will not check the missing atom coordinates, by the same token they can forget to check formula-coordinate discrepancies.

But is parsing the Hill formula guaranteed to always yield an unambiguous fixed set of missing atoms?

It should. We parse _chemical_formula_sum values for the COD, in most cases they match with what was calculated from the atomic coordinates and in the case they differ, this is a good indication of some peculiarity in the structure (not necessary error or problem ;).

Right now the v1 specification has an unambiguous representation of unknown atoms: include them like any other atoms and set their coordinates to null, null, null.

This is indeed a good representation of atoms with unknown coordinates; however requiring that the server does extra analysis and inserts these null atoms whenever the formula is not matching the atom count  in the coordinate list sounds to me as asking too much from a database.
A database, IMHO, is supposed to retrieve and return information that is stored, and only do minimal required transformations (such as extracting info from SQL or CIF and converting to JSON or XML).

@rartino:

But is parsing the Hill formula guaranteed to always yield an unambiguous fixed set of missing atoms?

It depends on whether the authors of a CIF file have included missing atoms in the formula or not. I am interested in doing a more throughout analysis of the COD: currently 80% entries have matching author-declared and computed formulae. That 20% is interesting to look into, plus there are more indications of missing atoms (such as F000) that we have been ignoring up to now.

Also, are we trying to push this for v1.0? Or can we keep the bandwidth-wasting nulls we have right now for v1.0?

The decision regarding the missing atoms could be delayed for v1.1 or later, indeed.

requiring that the server does extra analysis and inserts these null atoms whenever the formula is not matching the atom count in the coordinate list sounds to me as asking too much from a database. A database, IMHO, is supposed to retrieve and return information that is stored, and only do minimal required transformations (such as extracting info from SQL or CIF and converting to JSON or XML).

The desire to avoid such "heavy" transformations is already broken by OPTiMaDe asking you to serve the filled "P1" structure rather than just the representative atoms. Databases that store only the representative atoms (like COD does in CIFs) are already asked to do the transform to fill the cell before serving the data, and that is far heavier than adding the nulls for atoms with unknown positions.
It has been a goal (of mine, at least) that no implementation should be forced to alter or extend the data stored in their backend database to be able to serve OPTiMaDe. But, I don't think the goal you are trying to set now: that no implementation should have to do any major transform of their data before serving it, is a realistic goal for a common API. With that criteria, there would be very little commonality between the data received from different actors, and OPTiMaDe wouldn't be very useful compared to separate APIs.

It has been a goal (of mine, at least) that no implementation should be forced to alter or extend the data stored in their backend database to be able to serve OPTiMaDe. But, I don't think the goal you are trying to set now: that no implementation should have to do any major transform of their data before serving it, is a realistic goal for a common API.

Sounds like an internal contradiction to me...

Sounds like an internal contradiction to me...

No?
Statement 1 is: No need to change of data stored in backend database. (So, mandatory queries should be translatable to queries against the underlying database engine.)
Statement 2 is: No need for API to invoke major transformation of data before sending it in a response.
I'm saying: 1 is a goal, 2 is not. That is not a contradiction.


Fix typos

Found via codespell -S ./data

Codecov Report

Merging #213 (9306b4e) into master (9db2951) will decrease coverage by 0.19%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #213      +/-   ##
==========================================
- Coverage   89.90%   89.70%   -0.20%
==========================================
  Files          11       11
  Lines        1218     1214       -4
==========================================
- Hits         1095     1089       -6
- Misses        123      125       +2

Impacted Files
Coverage Δ

charset_normalizer/api.py
86.89% <ø> (ø)

charset_normalizer/constant.py
100.00% <ø> (ø)

charset_normalizer/models.py
86.66% <ø> (ø)

charset_normalizer/utils.py
85.25% <0.00%> (-0.93%)
:arrow_down:

charset_normalizer/legacy.py
96.29% <0.00%> (-0.48%)
:arrow_down:

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

:partying_face: :partying_face: :partying_face: :partying_face: :partying_face:


报错CCESS REFUSED - Login was refused using authentication mechanism PLAlN. For details see the

CCESS REFUSED - Login was refused using authentication mechanism PLAlN. For details see the

装新的


raspberry pi

[
{
"id": "8a5fd4d2.06cc78",
"type": "tab",
"label": "voice2json",
"disabled": false,
"info": ""
},
{
"id": "a76c3e16.f7dba",
"type": "sox-record",
"z": "8a5fd4d2.06cc78",
"name": "",
"buttonStart": "msg",
"inputs": 1,
"inputSource": "default",
"manualSource": "",
"inputEncoding": "signed-integer",
"inputChannels": 1,
"inputRate": 16000,
"inputBits": 16,
"byteOrder": "-L",
"encoding": "signed-integer",
"channels": 1,
"rate": 16000,
"bits": 16,
"gain": "0",
"lowpass": 8000,
"showDuration": false,
"durationType": "forever",
"durationLength": "0",
"silenceDetection": "nothing",
"silenceDuration": "2.0",
"silenceThreshold": "2.0",
"outputFormat": "stream",
"manualPath": "",
"debugOutput": false,
"x": 460,
"y": 140,
"wires": [
[],
[
"ddd44a5b.d980e8"
]
]
},
{
"id": "ac291b08.9436a8",
"type": "inject",
"z": "8a5fd4d2.06cc78",
"name": "",
"props": [
{
"p": "payload"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"payload": "start",
"payloadType": "str",
"x": 220,
"y": 140,
"wires": [
[
"a76c3e16.f7dba"
]
]
},
{
"id": "49d18aaf.0ad954",
"type": "inject",
"z": "8a5fd4d2.06cc78",
"name": "",
"props": [
{
"p": "payload"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"payload": "stop",
"payloadType": "str",
"x": 200,
"y": 200,
"wires": [
[
"a76c3e16.f7dba"
]
]
},
{
"id": "ddd44a5b.d980e8",
"type": "debug",
"z": "8a5fd4d2.06cc78",
"name": "",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "false",
"statusVal": "",
"statusType": "auto",
"x": 800,
"y": 180,
"wires": []
}
]
The flow generates debug outout:
2.5.2021, 08:24:12node: ddd44a5b.d980e8
msg.payload : string[8]
"starting"
2.5.2021, 08:24:12node: ddd44a5b.d980e8
msg.payload : string[51]
"sox FAIL sox: Buffer size `undefined' must be > 16↵"
2.5.2021, 08:24:12node: ddd44a5b.d980e8
msg.payload : string[8]
"complete"
/etc/asound contains:
sudo cat /etc/asound.conf
pcm.!default {
type asym
playback.pcm {
type plug
slave.pcm "hw:0,0"
}
capture.pcm {
type plug
slave.pcm "hw:2,0"
}
}
I tried to set the sox --buffer parameter but failed to implement it several ways but failed How can I work around getting this error?
NodeRed Version: 1.3.4

You are using an old version, if you update to the newest version of node-red-contrib-sox-utils there is actually a buffer setting in the nodes config.

I updated the node but there is no option for setting buffer in nodered node.
Inspecting the code I found the new variable and set it manually (just before: node.argArr.push("--buffer",node.buffer);)
diff sox_record.js.ori sox_record.js
315a316

    node.buffer=20000;

With this setting my "sox-record" is running fine.

Thanks for spotting this, I added the buffer argument in 0.5.1 but forgot to push the config change from my dev version. It should be fixed now in 0.5.2 and as soon as it shows up in the pallet you should be able to set the buffer in the config as above.
So can you please update to 0.5.2 and check it works, I will close the issue than.
Best regards Johannes

It's now working as you described.
Great job! Thanks a lot! Have I nice sunday.
Markus


GitHub workflow should target main branch

I used master by default, but that repo is using main branch instead. My mistake.

Thanks @j0k3r !


Use docker image versions

When pulling the docker image from docker hub, it always pulls latest version, example, uditgulati0/neutron-node:latest.
If a version is specified in wasmkit.config.js file, use that version in place of latest.

Would you like to use cosmos-omnibus instead of maintaining your own Docker images?
https://github.com/akash-network/cosmos-omnibus
https://hub.docker.com/u/uditgulati0


Revert "[fix] [broker] [branch-2.10] Upgrade rocksDB version to <IP_ADDRESS> to keep in sync with BookKeeper's RocksDB version

This reverts commit f88a49e2842f19ce8028cebf2fef1675db50c775.

Fixes #xyz

Master Issue: #xyz

PIP: #xyz

Motivation

Modifications

Verifying this change

[ ] Make sure that the change passes the CI checks.

(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (10MB)
Extended integration test for recovery after broker failure

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

If the box was checked, please highlight the changes

[ ] Dependencies (add or upgrade a dependency)
[ ] The public API
[ ] The schema
[ ] The default values of configurations
[ ] The threading model
[ ] The binary protocol
[ ] The REST endpoints
[ ] The admin CLI options
[ ] The metrics
[ ] Anything that affects deployment

Documentation

[ ] doc
[ ] doc-required
[x] doc-not-needed
[ ] doc-complete

Matching PR in forked repository
PR in forked repository:

/pulsarbot run-failure-checks


Make user mover fail if user has defined custom plpython functions

Closes https://app.clubhouse.io/cartoteam/story/76157/make-user-mover-fail-if-user-has-defined-custom-plpython-functions
What does this PR do?
Raises an error during user migrations if he/she has defined custom plpython2 functions.
Example error in Rollbar: https://rollbar.com/carto/CartoDB/items/41484/?item_page=0&item_count=100&#instances

:heavy_check_mark: Acceptance OK


Add a check for the dest node in varLenJoin queries

The front-end should check whether the user is allowed to do a varLenJoin on a relation between two nodes.
Example:
graphflowdb> match (:person)-[:studyAt*2..3]->(:organisation) return count(*)
graphflowdb: ./src/storage/include/storage_structure/lists/list_headers.h:43: uint32_t graphflow::storage::ListHeaders::getHeader(graphflow::common::node_offset_t): Assertion `offset < size' failed.
Aborted (core dumped)

The front-end should error in this case.

See PR #1581


v0.13 merge back

Codecov Report
Patch and project coverage have no change.

Comparison is base (47bf91b) 60.88% compared to head (3bd8cf7) 60.88%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff            @@
##           electron     #246   +/-   ##
=========================================
  Coverage     60.88%   60.88%
=========================================
  Files            51       51
  Lines          1107     1107
  Branches        116      116
=========================================
  Hits            674      674
  Misses          403      403
  Partials         30       30

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

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


x/tools/gopls: field alignment warning has issues on custom types

What version of Go are you using (go version)?

❯ go version
go version go1.16.5 linux/amd66

❯ gopls version
golang.org/x/tools/gopls v0.7.0
<EMAIL_ADDRESS>h1:JQBHW81Gsyim6iDjUwGoPeSpXrSqwen3isPJLfDfaYU=

What operating system and processor architecture are you using (go env)?
go env Output
❯ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/karitham/.cache/go-build"
GOENV="/home/karitham/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/karitham/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/karitham/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.5"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3891545200=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Have a struct with a custom type, for example
// session/permission.go
type Permission int64

// ./session.go
type User struct {
	DeletedAt  sql.NullTime       `json:"deleted_at"`
	Email      string             `json:"email"`
	Name       string             `json:"name"`
	Password   string             `json:"password"`
	Permission session.Permission `json:"permission"`
	ID         int32              `json:"id"`
}

What did you see?
struct of size 72 could be 64
What did you expect to see instead?
No warning, since that same exact struct passes with https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/fieldalignment.
The warning also disappears if I replace my custom type with
type User struct {
	DeletedAt  sql.NullTime `json:"deleted_at"`
	Email      string       `json:"email"`
	Name       string       `json:"name"`
	Password   string       `json:"password"`
	Permission int64        `json:"permission"`
	ID         int32        `json:"id"`
}

From my understanding, this issue only applied to types outside the standard library, since I get the issue on all the structs that contains custom types, either mines or from imported packages, such as https://github.com/shopspring/decimal's decimal.Decimal

CC @stamblerre via https://dev.golang.org/owners
Taking a quick stab at this: it looks like the analysis is assuming you're on a 32-bit platform, which is somewhat surprising to me. On a 64-bit platform that struct is 96 bytes (see https://play.golang.org/p/gbSmYJ9-2XW).
What's even weirder is if on linux/amd64 I run the above program as GOARCH=386 I get 60, which isn't either of the numbers the message is giving you.

BTW if I add back in the Permission type instead of a raw int64, I get the same numbers.

This is almost certainly due to AST trimming of packages outside of the workspace: time.Time is effectively a struct{} in the definition of sql.NullTime. This analyzer unfortunately doesn't make any sense in the presence of embedded non-workspace types.
We need a general solution for this, or should consider walking back the AST memory optimizations.


Floating point tolerance changes

Proposal to at least align the comparisons. A central tolerance value might be preferable, though.

Hopefully this was tidied up in the latest commit.


Burn Bell rings twice with Double Check

https://community.wanikani.com/t/kumireis-userscripts/42445/628?u=kumirei

@bashenk Thank you!!


typo in msdeformattn_pixel_decoder.py

Thanks for your error report and we appreciate it a lot.
Checklist

I have searched related issues but cannot get the expected help.
I have read the FAQ documentation but cannot get the expected help.
The bug has not been fixed in the latest version.

Describe the bug
A clear and concise description of what the bug is.
In mmdetection/blob/master/mmdet/models/plugins/msdeformattn_pixel_decoder.py# , valid_ratios seems to be mistyped as valid_radios, effectively making this argument useless?
Bug fix
Fix typo.

Yes, that's a typo. Thanks.


Issue938 dictionary part5

Closes #938 => New function to provide data dictionaries for part 5 reports. I have tested this in different use cases, exporting as many variables as I could think of in part 5. If any variable is not correctly identified, then the definition in the data dictionary would be blank.

Checklist before merging:

[x] Existing tests still work (check by running the test suite, e.g. from RStudio).
[ ] Added tests (if you added functionality) or fixed existing test (if you fixed a bug).
[x] Updated or expanded the documentation.
[x] Updated release notes in inst/NEWS.Rd with a user-readable summary. Please, include references to relevant issues or PR discussions.
[ ] Added your name to the contributors lists in the DESCRIPTION and CITATION.cff files.

Codecov Report

Merging #942 (0ae610a) into master (0e67881) will increase coverage by 0.29%.
The diff coverage is 97.83%.

:exclamation: Current head 0ae610a differs from pull request most recent head f9dbdb5. Consider uploading reports for the commit f9dbdb5 to get more accurate results

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@            Coverage Diff             @@
##           master     #942      +/-   ##
==========================================
+ Coverage   78.18%   78.47%   +0.29%
==========================================
  Files          93       94       +1
  Lines       12334    12517     +183
==========================================
+ Hits         9643     9823     +180
- Misses       2691     2694       +3

Files
Coverage Δ

R/g.report.part5.R
85.31% <100.00%> (+0.06%)
:arrow_up:

R/GGIR.R
65.74% <50.00%> (+0.11%)
:arrow_up:

R/g.report.part5_dictionary.R
98.33% <98.33%> (ø)

Nancy's group proposes appending definitions of usual acronyms we use in GGIR at the top of the data dictionary files or in a separate file, something like this:

@vincentvanhees do you think this is a good idea or is it enough with the data dictionary files that this branch already generates?

Nancy's group proposes appending definitions of usual acronyms we use in GGIR at the top of the data dictionary files or in a separate file, something like th

This means that we will have three places where each acronym is explained:

vignette
dictionary for each variable that includes the acronym
acronym overview
Maybe too much and also a risky in terms of potential inconsistencies. I wrote the vignette acronym overview in the hope that a dictionary would not be needed.

If there is a need for an acronym dictionary then I think the vignette is the most logical place as those explanations are generic and not dataset specific.

I agree and will explain to them. Then I think the work on this is ready to be reviewed when you have the chance.

Regarding your first 3 points, I followed instructions for storing internal data in R packages).-,7.2%20Internal%20data,-Sometimes%20your%20package), which is the data that will be used by the package but not usually made available to the user.
The file baseDictionary.R contains the source code to generate the internal data (stored in R/sysdata.rda). So, if let's say you want to change the definition of any of the variables included in this file, you can just go to the source code (data-raw/baseDictionary.R), replace the definition and run that script (note the last line would overwrite R/sysdata.rda with your changes). Let me know if this is not clear, I think this is the way to store this information.
Thus, only the R/sysdata.rda needs to pass into the CRAN version for this to work, the folder data-raw does not need to be in CRAN.

Can we make the dictionary optional? When processing large datasets it is helpful to be able to turn off any GGIR part that is not critical for the user and the dictionary would be a good example of this. For example, we could have one new general Boolean argument "create_dictionary" to tell GGIR whether to generate dictionaries (default) or not. This could be part of params_output. In that way we do not need to create a new argument for additional dictionaries in the future.

Sure, I can do that. But note that the function only loads the first row in the part 5 reports because we only need the column names, so it takes very little time to export the dictionaries. But if you want this to be optional I can include the argument tha you propose.

Sure, I can do that. But note that the function only loads the first row in the part 5 reports because we only need the column names, so it takes very little time to export the dictionaries. But if you want this to be optional I can include the argument tha you propose.

I see, ok then maybe the option to skip is not needed.
But what do you think about making the file name generic such that it can become the dictionary for any variable in GGIR or do you foresee that users prefer a separate dictionary for each part of the GGIR output?

Regarding your first 3 points, I followed

Thanks for clarifying, I did not know about this. Ok, my initial thoughts were: Would not be a lot easier if baseDictionary.R was part of the R folder and created the dictionary as part of the normal GGIR routine each time a dictionary is created...
On the other hand, if we do this then it would be good place to also store other data that is repeatedly load in the unit-test. For example, we could store essential parts of example part 1 output. This then helps to minimize the number of times part 1 has to be run inside the unit tests.
However, to allow for that it may be good if:

rename function baseDictionary.R by createInternalData.R because that will allow use to broaden the functionality (not in this PR, but in future work).
rename folder data-raw to dev-functions. The name dev-functions would better cover the content because these are functions and not data objects. By renaming it we also move there 'prepareNewrelease.R' which currently lives in the root and is the function I have used to prepare CRAN submissions.

we could create individual dictionaries for the various parts, and then at the end optionally run a function that appends all of them into one big data dictionary file

I agree this might been interesting in the future when we have dictionaries for more GGIR parts, and I've been piloting some code to do this (trying to merge daysummary with personsummary dictionaries from part 5 reports in a single dictionary).
I was thinking of including an extra column in the dictionary file that stores the filename of the report that contain every variable in the dictionary (column name = Report). The problem comes when a variable is present in more than one report (e.g., ID or filename), then the column Report would have to list a few filenames which would not be very nice visually. See example:

Maybe a separate dictionary per report is not a bad option, at least for now.

I was thinking of including an extra column in the dictionary file that stores the filename of the report that contain every variable in the dictionary (column name = Report). The problem comes when a variable is present in more than one report (e.g., ID or filename), then the column Report would have to list a few filenames which would not be very nice visually. See example:

Another option is to use four columns: format (csv, pdf, ...), part (1, 2...6), time resolution (day, person), and folder (results, QC, ...). or to put the filename(s) the variable can be found in as a final column and just accepted that those columns will be long, but these are just ideas for a future iteration of the work, not for this PR.
I assume we are not storing a dictionary for every part 5 threshold combination because the variables are the same and this would result in a lot of duplication?

Another option is to use four columns: format (csv, pdf, ...), part (1, 2...6), time resolution (day, person), and folder (results, QC, ...).

That sounds good, we can do that in the future when we have more dictionaries then.

I assume we are not storing a dictionary for every part 5 threshold combination because the variables are the same and this would result in a lot of duplication?

Good point, I just made a commit to export only one dictionary for daysummary and another for personsummary (independently on the number of reports with different configurations as variable names are the same).

Good point, I just made a commit to export only one dictionary for daysummary and another for personsummary (independently on the number of reports with different configurations as variable names are the same).

You may want to check that this also works for segment reports, which if I remember correctly have the same variable names as daysummary reports, so can be omitted.


Package not available on pip?

I was unable to find this package on the Python Package Index
I also cannot find a setup.py in the package
How does one install this?

Sorry it's not yet on there. The README is a template. The easiest way right now is to download an archive or use a Git URI with pip.
pip install git+https://github.com/Tatsh/mb8611-cli@master

I'll use this issue for tracking a release.

[ ] Cruft update
[ ] Tag
[ ] Add tests
[ ] Add docs
[ ] Add man page
[ ] Publish to PyPI

This is complete: https://pypi.org/project/mb8611/


Remove unnecessary widget

When merged in, will provide the CSS to style the radio group editor widget for subcontent forms, so https://github.com/NDLANO/h5p-ndla-virtual-tour/pull/136 can be used.

@janlindso Thanks! https://github.com/NDLANO/h5p-editor-ndla-virtual-tour/pull/24#event-10050101012 could then be merged as well if you don't find any trouble.


xSQLServerAlwaysOnAvailabilityGroup / Replica - Logic

Details of the scenario you try and problem that is occurring:
I hope this comes across without sounding too confusing....
At the moment xSQLServerAlwaysOnAvailabilityGroup and xSQLServerAlwaysOnAvailabilityGroupReplica are trying to enforce defaults even when a property is not set but I think it should not check the state of a property if it's not defined in the DSC resource. I would like my DBA's to have control over certain properties and not DSC.
Here is an example.
If I don't set the FailoverMode in xSQLServerAlwaysOnAvailabilityGroup then the resource will enforce 'Manual' mode. So if a DBA gets a call from the network guy to say there will be some network maintenance, the DBA might want to change FailoverMode to Automatic so he doesn't get a phone call in the middle of the night. The problem is now DSC will revert the FailoverMode to Manual even though I haven't specified it in the config.
The "Desired State" should only be what I define in the config. If the properties are not defined then they shouldn't be enforced. @johlju what are your thoughts?
The DSC configuration that is using the resource (as detailed as possible):
N/A
Version of the Operating System, SQL Server and PowerShell the DSC Target Node is running:
Server: Windows 2012 R2 (Update)
SQL Server: 2016 SP1 CU2
Powershell: 5.1
What module (SqlServer or SQLPS) and which version of the module the DSC Target Node is running:
SqlServer v20.0
Version of the DSC module you're using, or 'dev' if you're using current dev branch:
<IP_ADDRESS>

@Zuldan I agree with this. If you haven't set a property it shouldn't enforce it. The problem you are having is that the line 659 is seeing the default values as well and are trying to enforce those default values. It should not do that. Default values should only be used during setup.
@randomnote1 What are your thoughts on this?

@Zuldan, this makes complete sense to me. When I wrote the resource I had to use default values in order to build the AG, but it didn't occur to me that somebody might not want the default enforced. This will take some work to change, particularly on the unit testing side.
Thanks for using & testing these! Glad to know there's some interest in the resources.

@randomnote1 any chance you would have time to make this change before the next release? We're currently getting through the issue by temporarily disabling DSC on the SQL clusters when we need to manage settings not configured by DSC. Not an ideal situation lol. Any improvements you could make to this would be greatly appreciated.

I don't think it's likely in the short term. I have a few weeks of vacation coming up plus some other projects for my day job that need attended to.

@randomnote1 that's ok I understand. Appreciate all your work so far forgetting these modules together.

"Accidentally" started fixing this for xSQLServerAlwaysOnAvailabilityGroup while working issue #468.

Great @randomnote1! Labeling this as in progress.

@randomnote1 fantastic news! :-)


Function exp

The purpose of this PR is to implement and test exp().

Preliminary implementation of exp() is in. I appreciate the method. It's not super-speed optimized but portaboe to 32/64. I also in a future round will want to squeeze the tolreances, as I'm needing something like $96{\times}{\epsilon}$ to pass. I would have hoped for better tolerance.

I will need to correct one final edge case for argument negative infinity, then exp() will be good to go.


release twitch_api 0.7.0-rc.5

this should be the last rc release

bors r+

ehm, what
bors r+

ah shit...
[INFO] [stderr]    --> src/eventsub/channel/follow.rs:125:76
[INFO] [stderr]     |
[INFO] [stderr] 125 |     const SCOPE: &'static [twitch_oauth2::Scope] = &[twitch_oauth2::Scope::ModeratorReadFollowers];
[INFO] [stderr]     |                                                                            ^^^^^^^^^^^^^^^^^^^^^^
[INFO] [stderr]     |                                                                            |
[INFO] [stderr]     |                                                                            variant or associated item not found in `Scope`
[INFO] [stderr]     |                                                                            help: there is a variant with a

twitch_oauth2 needs an update


[FLOC-4393] Release Flocker 1.12.0

Fixes: https://clusterhq.atlassian.net/browse/FLOC-4393

Hey @ferrantim
Will you review the release notes:

http://clusterhq-staging-docs.s3-website-us-east-1.amazonaws.com/release/flocker-1.12.0/releasenotes/index.html

Then I can proceed with the release as soon as the tests have all passed.

@wallrj looks good to me. Please proceed.


[Bug]: Automatic commit issues empty commits

Describe the bug
The .git/COMMIT_EDITMSG as well as some .git/objects files are (sometimes) changed when the automatic commit fires, even if there have been no changes in the vault.
The .git/COMMIT_EDITMSG file will read for example
vault backup: 2024-10-01 02:55:25

Affected files:

"git reflog" does not show any activity, git seems to ignore the empty commit.
Relevant errors (if available) from notifications or console (CTRL+SHIFT+I)
The obsidian console prints
plugin:obsidian-git:314 obsidian-git: Committed 0 files

Interestingly, in the empty vault I set up in order to reproduce the error, obsidian-git will output "Committed 0 files" or "No changes to commit" randomly.

Steps to reproduce

Create a new obsidian vault.
Create a git repository in the vault folder git init.

Enable Community plugins, install the Git plugin and enable it.
Set the Auto commit-and-sync interval to a non zero value ( e.g. 1).
Disable Push and Pull on commit-and-sync.
Don't change any file in the vault and wait for the automatic commit to occur.

Expected Behavior
If no files are changed in the git repository, no commit should be issued. This seems to work only some times.
Addition context
The error seems to stem from this line
if (changedFiles.length !== 0 || hadConflict) {...

I would try to debug this further, but i have never really used ts, so i dont know how to build the plugin from source. (Maybe add a small part to the README on how to help development?)
This might seem like completely benign behavior, however it unfortunately represents a big problem for me.
My obsidian vault is located in a folder synchronized to a nextcloud server.
Since one of the files changed by the empty commit is a 600MB big .pack file, every time the automatic commit is triggered, 600MB of data are uploaded.
Additionally, since nextcloud saves old versions of files, the servers storage is completely filled within hours.
Operating system
Linux
Installation Method
Other
Plugin version
2.27.0

I figured out how to build the plugin.
The changedFiles object is not empty, and the offending file is .obsidian/plugins/obsidian-git/data.json.
I have added
if (
    changedFiles.length === 1 &&
    changedFiles[0].path == ".obsidian/plugins/obsidian-git/data.json"
) {
    changedFiles = [];
}

in front of the if condition mentioned in the bug report as a quick and dirty fix, which seems to be working so far.
I could not detect any changes in the mentioned file, so there has to be something in the logic which identifies the changed files that is misidentifying the data.json file.

That file shouldn't need any extra behavior. Please run git status in the terminal in your repository. If that file is listed there, please run git add -A and run git status again and share all these outputs here, please.

The file was already tracked by git, and git status does not show a change to the file during the bug.
If I change the settings of the obsidian-git plugin, for example the auto commit interval, git status shows the change and the change is committed correctly by the obsidian-git plugin.
Afterwards the weird behavior returns.
I have traced the origin of the bug to be via
main.ts commit() line 674
        if (this.gitManager instanceof SimpleGit) {
            this.mayDeleteConflictFile();
            status = await this.updateCachedStatus();

main.ts updateCachedStatus()
   async updateCachedStatus(): Promise<Status> {
        this.cachedStatus = await this.gitManager.status();
        return this.cachedStatus;
    }

simpleGit.ts status() line 123
    async status(): Promise<Status> {
        this.plugin.setState(PluginState.status);
        const status = await this.git.status((err) => this.onError(err));

The status const at this point contains the following data:
status: {"not_added":[],"conflicted":[],"created":[],"deleted":[],"modified":[".obsidian/plugins/obsidian-git/data.json"],"renamed":[],"files":[{"path":".obsidian/plugins/obsidian-git/data.json","index":" ","working_dir":"M"}],"staged":[],"ahead":0,"behind":0,"current":"master","tracking":null,"detached":false}
Again, this is the case even though git status outputs:
nothing to commit, working tree clean
`

It seems to me that the problem lies with the simple-git package.

Were you able to reproduce the behavior on your end using the steps i provided?

Although I have no reason to do so, I suspect this might be due to some file-system weirdness.

No I cannot reproduce your issue. I don't think simple-git produces an outdated or wrong status result. Can you verify via a git show HEAD, after an empty commit, that the commit is actually empty? Without extra config on your side, git wouldn't commit without any changes. (it needs --allow-empty).
Seems like you are already building the plugin yourself, could you add the following line after getting the status in updateCachedStatus() to see the diff of your changes?
await this.gitManager.getDiffString(".obsidian/plugins/obsidian-git/data.json")

TLDR:
In order to save you from reading the entirety of my response, here is the result of my investigation:
Removing the function call to this.plugin.saveSettings(); in private doAutoCommitAndSync() fixes the issue.
    private doAutoCommitAndSync(): void {
        this.plugin.promiseQueue.addTask(() => {
            if (this.plugin.settings.differentIntervalCommitAndPush) {
                return this.plugin.commit({ fromAuto: true });
            } else {
                return this.plugin.commitAndSync(true);
            }
        });
        this.saveLastAuto(new Date(), "backup");
        this.plugin.saveSettings();

It is unclear to me why the settings are saved during the commit and sync, but I expect there to be a reason.
Is it possible to remove this call completely or check for the condition in which it is needed and only issue the function call if necessary?
Here is the entire response I wrote in parallel to investigating the bug, in case you want to know how I came to my conclusion:
I'm sorry if I was unclear:
Although an empty commit seems to be issued to git, no commit happens.
This is probably exactly because git ignores empty commits without the --allow-empty.
The only changes I have detected so far are the changes of the "modified" and "changed" timestamps that are stored by the filesystem for some of the .git/objects/ files and the content of the .git/COMMIT_EDITMSG file.
These files are probably regenerated/changed by git internally even if an issued commit is ignored because it is empty.
As you have asked, I have changed updateCachedStatus() to
    async updateCachedStatus(): Promise<Status> {
        this.cachedStatus = await this.gitManager.status();
        const diffSting = await this.gitManager.getDiffString(
            ".obsidian/plugins/obsidian-git/data.json"
        );
        this.displayMessage("diffSting: " + JSON.stringify(diffSting));
        return this.cachedStatus;
    }

This yields:
obsidian-git: diffSting: ""

I have also changed the status() function in simpleGit.ts  to:
    async status(): Promise<Status> {
        this.plugin.setState(PluginState.status);
        const status = await this.git.status((err) => this.onError(err));
        this.plugin.setState(PluginState.idle);
        console.log("status: " + JSON.stringify(status));
        const hash = await this.git.hashObject(
            ".obsidian/plugins/obsidian-git/data.json",
            false
        );
        console.log("hash: " + JSON.stringify(hash));
        ...

This yields:
status: {"not_added":[],"conflicted":[],"created":[],"deleted":[],"modified":[".obsidian/plugins/obsidian-git/data.json"],"renamed":[],"files":[{"path":".obsidian/plugins/obsidian-git/data.json","index":" ","working_dir":"M"}],"staged":[],"ahead":0,"behind":0,"current":"master","tracking":null,"detached":false}
I added the hashObject() function call as an additional test to see if the file changes in between the empty commits. The output is something like
hash: "bd3bc3b56f12bae0c9b67a57ca2d72556fd02061"
This hash does not change between the empty commit attempts. This means that the content of the data.json file does not change.
If I change the auto commit interval in obsidian, the hash changes as expected, since this setting is stored in the  data.json file.
Since the content of the file does not change, simple-git has to use something else to detect if a file was modified.
I suspect it uses the "modified" or "changed" timestamps stored in the filesystem metadata for this.
According to this document referenced in this stackoverflow post, git itself uses these timestamps to determine if a file has changed.
Indeed, stat .obsidian/plugins/obsidian-git/data.json shows that these timestamps change every time the auto commit is initiated (on linux systems the stat command prints the file metadata):
  File: data.json
  Size: 1621            Blocks: 8          IO Block: 4096   regular file
Device: 0,48    Inode: 8241998     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/      user)   Gid: ( 1000/      user)
Access: 2024-10-12 08:57:57.823999000 +0200
Modify: 2024-10-12 08:57:57.823999000 +0200
Change: 2024-10-12 08:57:57.826218349 +0200
 Birth: 2024-10-01 04:12:23.445448450 +0200

The "Access", "Modify" and "Change" timestamps all change when the auto commit is triggered.
Since you cannot reproduce my error, I fear this bug might be down to details in how git interacts with the operating system or filesystem I am using (Debian + btrfs).
Preventing these timestamps from changing might fix this issue anyways.
The timestamps are changed due to this call to this.plugin.saveSettings(); in private doAutoCommitAndSync()
    private doAutoCommitAndSync(): void {
        this.plugin.promiseQueue.addTask(() => {
            if (this.plugin.settings.differentIntervalCommitAndPush) {
                return this.plugin.commit({ fromAuto: true });
            } else {
                return this.plugin.commitAndSync(true);
            }
        });
        this.saveLastAuto(new Date(), "backup");
        this.plugin.saveSettings();

Indeed when I remove this function call, data.json is no longer reported as modified by the this.git.status() call, fixing the issue entirely, and the commit and sync functionality still functions.

This is still very strange, because the saveSettings call shouldn't change the data.json file and cause empty commits.
Nevertheless, while refactoring some code I noticed that useless saveSettings call as well, so it's now removed in v2.28.0. You may try that new version.

The problem is fixed in version 2.28.2. Thank you very much!

The problem is fixed in version 2.28.2. Thank you very much!


Improve the Scrcpy Mouse Detection Quality for FPS Games

[ ] I have checked that a similar feature request does not already exist.

Is your feature request related to a problem?
Yes
Describe the feature request you'd like
Currently scrcpy supports the full function of keyboard use well, but I think the quality of connectivity and synchronisation from mouse to mobile on scrcpy needs to be improved as this allows scrcpy to be more flexible than buying OTG cables. I hope this message was well received and I hope in the next update the mouse quality can be improved on scrcpy.

What do you mean by "improved"? What's the problem?

https://github.com/Genymobile/scrcpy/blob/master/doc/mouse.md#physical-mouse-simulation

What do you mean by "improved"? What's the problem?

ooh there is a way, thank you for pointing it out to me. With this my problem is solved, once again thank you.

https://github.com/Genymobile/scrcpy/blob/master/doc/mouse.md#physical-mouse-simulation

It does work but why i cannot click anything?


[SPARK-10013][ML][JAVA][TEST] remove java assert from java unit tests

From Jira: We should use assertTrue, etc. instead to make sure the asserts are not ignored in tests.

Merged build triggered.

Merged build started.

Merged build triggered.

Merged build started.

cc @jkbradley as the source of the JIRA

Test build #42029 has started for   PR 8607 at commit b3777fb.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/42028/
Test FAILed.

Merged build triggered.

Merged build started.

Test build #42030 has started for   PR 8607 at commit 83544e0.

Test build #42029 has finished for   PR 8607 at commit b3777fb.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/42029/
Test FAILed.

Test build #42030 has finished for   PR 8607 at commit 83544e0.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class DCT(JavaTransformer, HasInputCol, HasOutputCol):
class SQLTransformer(JavaTransformer):
class StopWordsRemover(JavaTransformer, HasInputCol, HasOutputCol):

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/42030/
Test PASSed.

Merged build finished. Test PASSed.

LGTM - except the build file.

Merged build triggered.

Merged build started.

Test build #42048 has started for   PR 8607 at commit 869b20d.

Test build #42048 has finished for   PR 8607 at commit 869b20d.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/42048/
Test PASSed.

Merged build finished. Test PASSed.

I've merged this.

Post-hoc +1 -- this was another thing I wanted to fix about the Java suite tests.


Kubectl diff not working as expected with Istio

When using kubectl diff:
kubectl diff -R -f /REDACTED/istio-system

I get a difference that should not be there (as it is not a difference actually), a false positive:
diff -u -N /tmp/LIVE-835569441/admissionregistration.k8s.io.v1beta1.MutatingWebhookConfiguration..istio-sidecar-injector /tmp/MERGED-071657484/admissionregistration.k8s.io.v1beta1.MutatingWebhookConfiguration..istio-sidecar-injector
--- /tmp/LIVE-835569441/admissionregistration.k8s.io.v1beta1.MutatingWebhookConfiguration..istio-sidecar-injector       2019-12-03 15:40:48.684300441 +0100
+++ /tmp/MERGED-071657484/admissionregistration.k8s.io.v1beta1.MutatingWebhookConfiguration..istio-sidecar-injector     2019-12-03 15:40:48.728300888 +0100
@@ -5,7 +5,7 @@
     kubectl.kubernetes.io/last-applied-configuration: REDACTED
   creationTimestamp: "2019-08-13T07:53:42Z"
-  generation: 30
+  generation: 31
   labels:
     app: sidecarInjectorWebhook
     release: istio
@@ -17,7 +17,6 @@
 - admissionReviewVersions:
   - v1beta1
   clientConfig:
-    caBundle: REDACTED
     service:
       name: istio-sidecar-injector
       namespace: istio-system

The manifest:
---
apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
  name: istio-sidecar-injector
  labels:
    app: sidecarInjectorWebhook
    release: istio
webhooks:
  - name: sidecar-injector.istio.io
    clientConfig:
      service:
        name: istio-sidecar-injector
        namespace: istio-system
        path: "/inject"
      caBundle: ""
    rules:
      - operations: [ "CREATE" ]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
    failurePolicy: Fail
    namespaceSelector:
      matchLabels:
        istio-injection: enabled

Expected behavior
No difference.
Steps to reproduce the bug
(above)
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
Client Version: v1.14.8
Server Version: v1.14.8-eks-b8860f

How was Istio installed?
kubectl (from Helm template output)
Environment where bug was observed (cloud vendor, OS, etc)
AWS EKS

We modify the webhook at runtime to patch the cert

Yes, that's what I could guess so far.
As far as I understand, kubectl diff currently uses --server-dry-run feature.
The announcement blog post  says something about setting sideEffects field in webhooks.
Is there something similar that can be done for the MutatingWebhookConfiguration manifest?
This is the only thing that throws an error when I diff my clusters.

that's about the config actually being modified through the webhook. We just have a deployment directly changing the config

Is there anything that can be done to mitigate this, or we just need to wait until the istio operator matures enough to be production ready?

Doesn't the operator have the same problem since there is a deployment modifying the yamls directly? I will admit I have never used diff

The thing is that I need to use a modified version of the exported Helm chart (two gateways is the main difference), and because of that I have all the Istio manifests versioned and I manage them myself.
Hypothetically, if the operator could be used instead of my customized manifests, I would only have versioned the operator manifests and not the istio manifests.
As a consequence I wouldn't diff against the Istio manifests themselves, because I would no longer have to version and manage them myself.
So this is what could maybe mitigate the problem.
But I'm still a bit fuzzy on why/how MutatingWebhookConfiguration is modified and how exactly does it interact with the server-side dry run feature and whether or not it is something that can be addressed in Istio or Kubernetes code.

MutatingWebhookConfiguration has a caBundle field which contains a cert. This cert is not known at installation time and needs to change over time (this is probably not actually correct anymore, but its how we implemented it years ago :slightly_smiling_face: ). So at runtime we inject the caBundle field.
you can do this statically with istioctl, but the UX is pretty clunky right now: https://istio.io/docs/tasks/security/webhook/
In 1.5 we are hoping to have that automated so when you do istioctl manifest apply it will apply all of the config and handle it automatically.
Also in 1.5 we will support multiple gateways so you shouldn't need your own modifications hopefully.

Istio does not work for us out of the box for multiple reasons, also we don't use Helm, because of that versioned manifests are a must, at least until operator is GA.
If caBundle is runtime state then shouldn't it be held under status?

we don't control where it goes, it's part of the k8s spec
On Mon, Dec 16, 2019, 1:17 AM Paweł Prażak<EMAIL_ADDRESS>wrote:

Istio does not work for us out of the box for multiple reasons, also we
don't use Helm, because of that versioned manifests are a must, at least
until operator is GA.
If caBundle is runtime state then shouldn't it be held under status?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/19349?email_source=notifications&email_token=AAEYGXMN73XWEW3LOLNHLRTQY5BSDA5CNFSM4JUZNO5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG6BFDA#issuecomment-565973644,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXPTB77IJ7Q3E6WRAGDQY5BSDANCNFSM4JUZNO5A
.

you can achieve what you want by following the link above with istioctl I think


The code regarding libero-10

Hello! Is there any plan to release the code about experiment on libero-10?

Hi,
The current version of the code already works with LIBERO-10. You will need to set suite/task=libero_10 while running the training and evaluation scripts for using the tasks in LIBERO-10.