TimeoutError

Hi,
your system works for me, speaks correctly, but in the error log I always find this message:
`2020-04-12 21:00:10.065653 WARNING alexa_talking_clock: ------------------------------------------------------------
concurrent.futures._base.TimeoutError
raise TimeoutError()
File "/usr/lib/python3.8/concurrent/futures/_base.py", line 441, in result
result = future.result(self.AD.internal_function_timeout)
File "/usr/lib/python3.8/site-packages/appdaemon/utils.py", line 285, in run_coroutine_threadsafe
f = run_coroutine_threadsafe(self, coro(self, *args, **kwargs))
File "/usr/lib/python3.8/site-packages/appdaemon/utils.py", line 191, in inner_sync_wrapper
self.call_service("notify/alexa_media", data = {"type":"announce", "method":"all"}, target = self.alexa, message = msg)
File "/config/appdaemon/apps/ad-alexatalkingclock/apps/alexa_talking_clock/alexa_talking_clock.py", line 95, in time_announce
funcref(self.AD.sched.sanitize_timer_kwargs(app, args["kwargs"]))
File "/usr/lib/python3.8/site-packages/appdaemon/threading.py", line 766, in worker
2020-04-12 21:00:10.063241 WARNING alexa_talking_clock: Traceback (most recent call last):
2020-04-12 21:00:10.047554 WARNING alexa_talking_clock: ------------------------------------------------------------
2020-04-12 21:00:10.045504 WARNING alexa_talking_clock: Worker Ags: {'id': 'ab1a0d8af83b495aa32d428d8dca761b', 'name': 'alexa_talking_clock', 'objectid': '5485f12708b64a69984a88d3026f6739', 'type': 'scheduler', 'function': >, 'pin_app': True, 'pin_thread': 0, 'kwargs': {'interval': 3600, '__thread_id': 'thread-0'}}
2020-04-12 21:00:10.043761 WARNING alexa_talking_clock: Unexpected error in worker for App alexa_talking_clock:
2020-04-12 21:00:10.042038 WARNING alexa_talking_clock: ------------------------------------------------------------`

can you please post your apps.yaml entry ?
also, if possible you appdaemon.yaml config. I've recently updated the version to 1.0.2 ... can you please update the app and try and see if this issue is still occurring ?

I updated a few hours ago to version 1.0.2, but the issue still occurs.
Required files are attached below.
atc.zip

Can we please do a live debug session over chrome remote desktop, teamviewer or webex. I cant for the love of my life diagnose why it would throw a timeout error on your machine. I've asked around and no one is facing any timeout issues so it's a little difficult to say whats going on. Also, where are you located, plus what's your internet connection speed. Are you using any proxies or adblockers on your network?

You have a PM .

The latest version (v1.0.5) solved the issue!
No more Timeout in Log!
Great!!

Oh no .. Sorry ..
Works if I set "debug: true"
When is set to false the error still appears.
Must be scheduling-related!

I think I found the issue. Can you please update to the latest and try. Also, the latest version has some changes in the apps.yaml structure. Just a note :)

Perfect! Version 2.0.2 has solved the timeout problem.
Thanks a lot!
Only a note: I was just trying the new parameters: I didn't understand if I need the new "half-hour: .." or it still works with old "announce_half_hour: ..".

you need the new half_hour, now it's nested announce > half hour :)


1471: Update android sdk

Short description
This issue was reported from the play store even i couldn't reproduce any crash.
Proposed changes

update android sdk version

Side effects

none

Resolved issues

Fixes: #1471
Testing

build and start the app on android

...

what does this mean @ztefanie ?

Yeah sorry, i wrote that the android plugin version must match the dependency version, which I am not sure if this is currently the case. Then i wanted to check, but I am lost in the rabbit hole of getting protoc plugin working again. So not sure it your PR is valid as i can not check. I wanted to edit the message as soon as i get my setup fixed, but it takes forever.

@ztefanie not sure if this issue is related to this and if this dependency class import is still needed with declarative plugins
https://github.com/digitalfabrik/entitlementcard/pull/1376/files


[Build] Re-include Windows/wine test into Travis build

Builds fine with wine now, see https://travis-ci.org/crowning-/dash/builds/174321935
Changes:

uses wine1.7 instead of wine1.6 (wine1.6 makes trouble in a headless build-environment)
I had to disable the wine-Qt-tests, because the build for Qt for Windows exceeds the maximum time allowed for a job on Travis. In the rare case when it finished within time the tests succeeded.

Some of the performance optimizations I did for the Windows-Qt-build are still included, can't hurt to have a (slightly) faster build.

I noticed in line 42 you folks call for the presence of the Debian Almquist Shell (dash) but nowhere is it ever checked if the user has it installed/enabled on the machine:
.... LDFLAGS=-static-libstdc++" USE_SHELL="/bin/dash" PYZMQ=true
I suggest to add a check for this USE_SHELL="/bin/dash" in the configure.ac file e.g.
Line 69:  AC_PATH_PROG(DASH,dash)
That just throws a warning in case the user does not have it installed. A hard check can be added also before the test e.g starting line 616
if test x$DASH = x; then
AC_MSG_ERROR(/bin/dash shell is required for tests)
fi
Just a thought..


[WIP] Logging callback function

pushes the logging into a callback to separate code from presentation

Codecov Report

Merging #192 (6cd7c9f) into master (713eaf1) will increase coverage by 0.23%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #192      +/-   ##
==========================================
+ Coverage   67.99%   68.22%   +0.23%
==========================================
  Files          13       13
  Lines        1687     1693       +6
==========================================
+ Hits         1147     1155       +8
+ Misses        540      538       -2

Impacted Files
Coverage Δ

src/fw_algorithms.jl
77.20% <100.00%> (-0.92%)
:arrow_down:

src/utils.jl
53.09% <100.00%> (+3.57%)
:arrow_up:

src/types.jl
64.44% <0.00%> (-0.40%)
:arrow_down:

src/polytope_oracles.jl
100.00% <0.00%> (ø)

src/active_set.jl
79.20% <0.00%> (+0.62%)
:arrow_up:

Continue to review full report at Codecov.

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

[ ] FW
[ ] LCG
[ ] SFW
[ ] AFW
[ ] BCG


mathematics or latex notation

First and foremost, millions of thanks for creating such an amazing tool!
As a noob, I have just been to convert part of my blog to wyam. However, I am having trouble with math/latex notations. How do you do it in your blog?
Happy thanksgiving in advance!

Thanks! Glad you're off to a good start.
Most of the time, that kind of functionality is provided by JavaScript resources on the client. Here's an explanation from another issue:

Yep, @LokiMidgard is right. The diagrams are all provided by Mermaid and rendered on the client. The JavaScript code to include this on your pages is baked into the Docs recipe but not the Blog recipe since diagrams probably aren't something the majority of people will use (and there's a code for every JavaScript library you include).
Here's a good article on adding JavaScript libraries to the blog themes: http://www.digitaltapestry.net/posts/wyam-anchors-and-code-copy. It's not specific to Mermaid, but the concepts are the same. You basically need to add the appropriate JavaScript files to the head and then initialize in the body.

I'd check out that blog post for a great explanation of how to do something similar. In your case, it would probably be a matter of finding a good math/latex client-side JavaScript library, adding it to the script to the head in one of the layouts, and then using it from within your Markdown.

That seems to be the right direction. Do you happen to know of an example, probably wyam user who is using math notations?
Thanks so much again for your time. :)


minor cleanup of init_position_args

no need to zero fill the position_args struct, since all fields are set in the subsequent lines
no need to cast &args->channels

no need to zero fill the position_args struct, since all fields are set in the subsequent lines

Or maybe we could have kept the memset but remove the two 0 assignments.
In the very unlikely chance that the structure changes, the memset would be still
good though

* no need to cast &args->channels

src/effect_position.c: In function 'init_position_args':
src/effect_position.c:1557: warning: passing argument 3 of 'Mix_QuerySpec' discards qualifiers from pointer target type
include/SDL_mixer.h:161: note: expected 'int *' but argument is of type 'volatile int *'

(Maybe I should add the gc warning options to configure.ac -- it
doesn't seem to add -Wall by default.)
Let's not apply this patch for now.


Improve logging, add OpenTelemetry

Since we migrated to tracing #261, we should be able to improve the experience for logging stuff. Now I want to use Jaeger to monitor more stuff. Let's add tracing_opentelemetry, test it locally, and then run it on the server for atomicdata.dev

Done!


fixed problems with feature term

turns out that for bdg feature:
feature.getFeatureType()
returns just a String not an ontologyTerm.
We can also actually eliminate
private final Converter<String, ga4gh.Common.OntologyTerm> featureTypeConverter;
completely from class BdgenomicsFeatureToGa4ghFeature
which I will do before asking for merge here, unless other feedback.
The previous  code causes problems with null pointer if featureType  is null, and the ontology term converter as it is right now doesn't actually set the term anyhow.
This PR is needed for mango work.

There are some complications around featureType and OntologyTerm, in that bgd-formats tries to be lowest-common-denominator for BED and GFF3.
featureType is required by GFF3 and in fact must be a term name or DBTAG:ID from the Sequence Ontology.  OntologyTerm in bdg-formats reflects the GFF3 definition of an ontology term link as used the ninth column "attributes" (DBTAG:ID format mapped to OntologyTerm.db and OntologyTerm.accession).  To properly represent featureType as an OntologyTerm one must to a lookup from term name to SO identifier, e.g. gene → SO:0000704 or { db:"SO", accession:"0000704" }.
Then GA4GH OntologyTerm is another bag of rocks in that it needs the term (gene above) and a CURIE identifier (defined as [namespace prefix]:[accession], which may but not necessarily be the same as DBTAG:ID).  See http://identifiers.org.
message OntologyTerm {
  // Ontology term identifier - the CURIE for an ontology term. It
  // differs from the standard GA4GH schema's :ref:`id <apidesign_object_ids>`
  // in that it is a CURIE pointing to an information resource outside of the
  // scope of the schema or its resource implementation.
  string term_id = 1;

  // Ontology term - the label of the ontology term the termId is pointing to.
string term = 2;

BED/IntervalList/NarrowPeak formats do not include a column for featureType
https://github.com/heuermh/bdg-formats/blob/docs/docs/source/features.md
We should come up with a proper mapping strategy for featureType and OntologyTerm more generally.

closing this in favor of #40


IE11 moment js date formatting for mm/dd/yyyy gives a correct date for invalid input 55/55/2

Description of the Issue and Steps to Reproduce:
moment('55/55/1', 'MM/DD/YYYY').format('MM/DD/YYYY') returns a valid date instead of NAN
Please include the values of all variables used.
Environment:
*Examples: Internet Explorer 11 on Windows 7,
Both the browser and the OS are important to us, particularly if you have an unsual environment like an IOT application.
Other information that may be helpful:

The time zone setting of the machine the code is running on
The time and date at which the code was run
Other libraries in use (TypeScript, Immutable.js, etc)

If you are reporting an issue, please run the following code in the environment you are using and include the output:
console.log( (new Date()).toString())
console.log((new Date()).toLocaleString())
console.log( (new Date()).getTimezoneOffset())
console.log( navigator.userAgent)
console.log(moment.version)

Ensure your issue is isolated to moment. Issues involving third party tools will be closed unless submitted by the tool's author/maintainer.

What do you mean by valid date? What is the return value? It is not supposed to return NaN.
http://momentjs.com/docs/#/parsing/is-valid/

This shouldn't return NaN. What I get in IE is:
moment('55/55/1', 'MM/DD/YYYY').format('MM/DD/YYYY')
// "Invalid date"
In short, working exactly as designed.

Attached is the screenshot for the same.

See that the date returned is 10/15/0004 which is valid date. while if same thing is given in chrome or firefox it is NAN.

Duplicate of #3972

Duplicate of #3972

Can hardly be a duplicate of an issue that was filed later ;)
I will later try to reproduce it also on IE11 and Firefox, but Chrome at least does not return NaN but simply an invalid date, as it supposed to.

http://jsbin.com/hiwefikidu/edit?html,js,console

The version of moment it use is 2.14.1 and we are using is 2.0.0

The version of moment it use is 2.14.1 and we are using is 2.0.0

Well, that might easily explain it. I'd suggest to upgrade then.

@neroux thankyou will try to update the version and update thread.

Just tried it under Firefox, IE, and Edge and it works everywhere as supposed to.


Bump minSdk to 23 in RN OSS

Summary:
In this diff I'm increasing the minSdk of RN Android to 23 to keep it in sync with Meta min sdk
changelog: [Android][Breaking] Increase min sdk version of RN Android to 23
Reviewed By: NickGerleman
Differential Revision: D48177965

Why does this change increase the size of the app so much?


[Issue] suggestionsThreshold is not applied when set in Global options

I am setting some global options up when initializing the Tags object, but the expected results per the applied settings are not taking place. Only way settings are applied is when using data attributes.
For example:
Tags.init(tagsSelector, {         allowClear: true,         suggestionsThreshold: 0,     });
doesn't work. So I need to explicitly set the data attributes on the element by either altering HTML code or tricking Tags before initializing by programmatically adding the attributes. Like this...
document.querySelectorAll(tagsSelector).forEach(tagsEl => {         tagsEl.dataset.allowClear = true;         tagsEl.dataset.suggestionsThreshold = 0;     });
The expected result is that when initializing Tags with an options object, specified settings take effect on the UI as expected.

that's really odd. in the demo i'm using
Tags.init("select:not(.ignore-tags)", {
  clearLabel: 'Clear tag',
  allowClear: true,
});

and for the following input
Tags (show all + custom colors)
i see the clear icon even though i don't have the data-allow-clear option set to true.
do you have a working example jsfiddle or something with the issue?

Further looking into this, seems like the issue is very specific to the "suggestionsThreshold" option. If set in the constructor it doesn't apply the intended behavior (display the selection popup on focus).
See an example below on jsfiddle.

Indeed! the constructor check was a bit naive
fixed in https://github.com/lekoala/bootstrap5-tags/releases/tag/1.4.5


VSCode 1.24.0 issues

Recently updated to 1.24.0 version of vscode and I've noticed that all functions like !Sub and !Ref is being hightlighted as an error as   unknown tag <!Sub>
Has anyone else had an issue with this?

Hello @sd3z,
yes, I know this issue. But it is not because of this extension.
Do you have an extension installed that will check your yaml files? Like YAML Support by Red Hat?
See: https://github.com/redhat-developer/vscode-yaml/issues/76
Hope that helps.

I will leave this here, because if someone uses YAML Support by Red Hat will get the unknown tag <!Sub> therefore

I will leave this here, because if someone uses YAML Support by Red Hat will get the unknown tag <!Sub>.
You have to use following setting in your user or workspace settings:
    "yaml.customTags": [
        "!FindInMap sequence",
        "!GetAtt",
        "!GetAZs",
        "!ImportValue",
        "!Join sequence",
        "!Ref",
        "!Select sequence",
        "!Split sequence",
        "!Sub",
        "!Not sequence",
        "!Equals sequence"
        ]

...or this to include all the remaining tags as well:
   "yaml.customTags": [         "!Ref",          "!Base64 mapping",         "!Cidr",         "!FindInMap sequence",         "!GetAtt",         "!GetAZs",         "!ImportValue",         "!Join sequence",         "!Select sequence",         "!Split sequence",         "!Sub",         "!Transform",         "!Not sequence",         "!Equals sequence"     ]

Adding this to save someone else the frustration...  I've found that if you don't disable the Ansible plugin, the fix @pravinsingh (and others) provides doesn't work for some reason.

@e4jet, a colleague reached out to me today with the same issue, and after a few minutes of struggling I remembered your comment about Ansible plugin, and that saved the day. So, thank you!
I think we should raise this bug, but I'm not sure with whom. The same behavior happens with the other YAML plugin (from @aws-scripting-guy) as well, so this is clearly not a problem with @dthielking's plugin. This could be either a bug in the Ansible plugin, in the Red Hat YAML server, or in VS Code itself.

If anyone is writing yaml for home assistant, VS code helped me set the custom tags properly:
{     "workbench.startupEditor": "newUntitledFile",     "editor.minimap.enabled": true,     "update.showReleaseNotes": false,     "yaml.customTags": [         "!secret scalar",         "!include scalar",         "!include_dir_merge_named scalar"     ] }
"scalar" allows regular names (like folder names)


Finestra Miner not onboarding

My finestra miner, Upbeat Pink Corgi, is not on boarding and stuck in offline but the miner is on.

Hi Hassant, please reach out to finestra for Hotspot hardware support. This is for app only. thanks!


Google Doc title existing of elements are badly converted to markdown

Google Docs titles aren't parsed well by docs-markdown.
Example of bad markup:

The 'raw' Google Doc object:

{
    "startIndex": 1972,
    "endIndex": 1986,
    "paragraph": {
        "elements": [
            {
                "startIndex": 1972,
                "endIndex": 1975,
                "textRun": {
                    "content": "CO2",
                    "textStyle": {}
                }
            },
            {
                "startIndex": 1975,
                "endIndex": 1976,
                "textRun": {
                    "content": "-",
                    "textStyle": {}
                }
            },
            {
                "startIndex": 1976,
                "endIndex": 1986,
                "textRun": {
                    "content": "besparing\n",
                    "textStyle": {}
                }
            }
        ],
        "paragraphStyle": {
            "headingId": "h.x2tz0gvmechr",
            "namedStyleType": "HEADING_2",
            "direction": "LEFT_TO_RIGHT"
        }
    }
}

The result in markdown:
### CO2### -### besparing

Fixed by https://github.com/bartwr/docs-markdown/commit/01113fe6003a46d83e1e0edbab3b6ffb352a8812
Possible further improvement: take in account element.textRun.textStyle, so that you make headings that are partly bold, partly italic and partly underlined.
I close this one for now, as we now have good looking headings:


Add real sample data from zenodo

This adds some real-world sample data from zenodo that contains a MIP of a 3D volume of hiPSCs. It uses pooch.retrieve to manage downloading and caching this data, so just uses the general pooch cache.

I used the MIP instead of the full 3D volume to reduce the download size (~100MB instead of ~1GB).
Closes #45

Super cool @andy-sweet ! I tried loading via the sample data and loading directly from disk and observed some minor differences:
The on-disk version gets correct channel names, while the one from sample data names everything like the first channel. But the sample data gets the space units correctly set to micrometers, while the on-disk version shows "none" for space units.
See here:

Is the plan to include multiscales metadata or is there also an option to expose additional metadata from the OME-NGFF file? For example, it could be interesting to allow users to edit some of the OMERO metadata like the channel names (already possible in theory I think), the default colors of the layers, their default rescaling (start & end values) and such things.
And, in the future, we may pack additional metadata into those .zattrs files (probably with their own unique keyword). Would be interesting if they can be exposed as well.

Thanks for trying it out!

The on-disk version gets correct channel names, while the one from sample data names everything like the first channel. But the sample data gets the space units correctly set to micrometers, while the on-disk version shows "none" for space units.

Is it possible you have a different plugin registered to read .zarr directories (e.g. napari-ome-zarr) by default? I think that would explain the differences.
Will take a look at the channel name bug for the sample data.

Is the plan to include multiscales metadata or is there also an option to expose additional metadata from the OME-NGFF file?

What else would you want to see from the multiscales metadata? Transform per level? The contents of the "metadata" key in multiscales?
One thing I've thought of is to make the read only view more like a raw dump of the JSON data into a tree.

For example, it could be interesting to allow users to edit some of the OMERO metadata like the channel names (already possible in theory I think), the default colors of the layers, their default rescaling (start & end values) and such things.

Yeah, I wanted to get to this, but didn't quite make it yet. The napari-ome-zarr reader already brings in some of these things (e.g. the colormap) that the napari model supports, so the mapping is already defined, which is the hard part.

Is it possible you have a different plugin registered to read .zarr directories (e.g. napari-ome-zarr) by default? I think that would explain the differences.

Ah yes, I'm reading it via napari-ome-zarr. Is there support for it through the napari core reader then that you're using for the sample data?

What else would you want to see from the multiscales metadata? Transform per level? The contents of the "metadata" key in multiscales?

From the multiscales, I think it covers everything we use at the moment. We only use the coordinateTransformations for the pixel sizes and the one at full resolution are the relevant ones :)

One thing I've thought of is to make the read only view more like a raw dump of the JSON data into a tree.

That would be neat!

Yeah, I wanted to get to this, but didn't quite make it yet. The napari-ome-zarr reader already brings in some of these things (e.g. the colormap) that the napari model supports, so the mapping is already defined, which is the hard part.

Good point. I agree, it doesn't make much sense that it would show up in 2 places. Also the start & end values are used by napari to already rescale the image. It's just currently not possible to save a change back to the OME-Zarr file, which would actually be a useful thing to do sometimes :)

Awesome, looks great to me now! Thanks @andy-sweet


cache-control: no-store header being overwritten by .net core CSRF token generator

In order to solve a caching issue in IE I decorated my controllers with
[ResponseCache(Location = ResponseCacheLocation.None, NoStore = true)]
When looking at the response headers in the browser developer tools I noticed that some of my controller action responses had the expected Cache-Control:no-store,no-cache
But others didn't. This was driving me nuts and after doing some digging I found the explanation in the msdn documentation

https://docs.microsoft.com/en-us/aspnet/core/performance/caching/middleware
So I tried disabling CSRF protection in my form by using the asp-antiforgery="false" attribute and sure enough the no-store directive was added to my response header.
So my question is: Is there any way to achieve this without having to sacrifice security by disabling CSRF protection in my forms? It definitely doesn't feel right to have to disable that just to prevent IE from caching my pages.
Thanks in advance for any help/advice that you can give me!

What's the exact issue here with the cache headers? Is the problem that you need Cache-Control: no-cache, no-store and you are getting Cache-Control: no-cache?

@rynowak the issue is that I need the headers to be Cache-Control: no-cache, no-store  and adding the controller attributes allow me to achieve this everywhere but in pages where there is a form (unless I disable CSRF protection in which case it does work but I am left without protection against that type of attack)
Also, it looks like you closed the issue in both the home and the MVC repos!

No, this is issue is open.

FYI here's a workaround that someone else found for this in 1.X.Y. We already addressed this issue in 2.0.0 https://github.com/aspnet/Antiforgery/blob/f258be61fd05ff23d286661c58409b1eba004440/src/Microsoft.AspNetCore.Antiforgery/Internal/DefaultAntiforgery.cs#L372

see https://github.com/aspnet/Antiforgery/issues/116 for the workaround


[SPARK-24338][SQL] Fixed Hive CREATETABLE error in Sentry-secured cluster

What changes were proposed in this pull request?
As detailed in the JIRA ticket, Hive "CREATE TABLE" statement would fail when Sentry is used to manage authorization. This PR fixed this bug by porting the Cloudera fix.
How was this patch tested?
Tested that the table can be successfully created with the fix.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

@vanzin Could you pls review it? I know the fix exists on Cloudera's fork but right now since this is missing from the upstream project, it will affect all sentry users who dont use Cloudera's distro.

Oh man, this thing. I didn't post this upstream because I think this is kinda hacky, and I also consider this primarily a Sentry bug. But if others are ok with it...
Just make sure you have all the necessary changes. My initial patch caused a couple of breakages.
https://github.com/cloudera/spark/commit/4c8289d
https://github.com/cloudera/spark/commit/629b1c3
https://github.com/cloudera/spark/commit/41fc8a1
Also you probably shouldn't reference CDH bugs in the code here...

Thanks @vanzin. I've verified this commit has all the changes you mentioned. I've also removed references to CDH in the code comments.

ok to test

(Although I'm pretty sure it will fail style checks.)
Also, @cloud-fan since you wrote the original change.

Test build #90992 has started for PR 21398 at commit 0f4be31.

Test build #90992 has finished for PR 21398 at commit 0f4be31.

This patch fails Scala style 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/90992/
Test FAILed.

Test build #90994 has started for PR 21398 at commit 5f64a95.

Test build #90994 has finished for PR 21398 at commit 5f64a95.

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

Merged build finished. Test PASSed.

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

@vanzin should we merge this or add a comment in the docs?

I'm kinda neutral on what should happen, except maybe for filing a Sentry bug. I'll let @cloud-fan decide whether this makes sense in Spark.
For the Sentry bug, there's an easy way to reproduce this, just run the following (either in Spark or using the old Hive CLI - not beeline nor jdbc):
USE some_db;
CREATE TABLE foo(idx int) LOCATION 'hdfs://blah.example.com/user/hive/warehouse/some_db.db/foo';

Even if the user has permissions to create table on that database, Sentry will not allow it. Works fine if you remove the explicit location.

@vanzin But in Spark SQL, even when LOCATION is not specified, Sentry would still not allow the table to be created.

If that's the case then your user does not have permission to create the table. The issue that my patch works around is a bug in Sentry where creating a table with the location specified to the same location as it would have been automatically assigned does not work. My patch removes the explicit location in that case, and things work.
But if you don't have permissions, you'll get an error regardless of my patch.

I can double check. But I remember clearly that the user did have all the necessary privileges. Without this patch, a permission error was thrown. With this patch it worked fine. The CREATE TABLE statement didn't involve a LOCATION.

Yes, that's exactly what I said. I'm not sure what part is confusing you.

You said: "even when LOCATION is not specified, Sentry would still not allow the table to be created."
I said that if that's the case, then your user doesn't have the needed permission. Because all my patch does is remove the location.
I'm still confused about what it is that you're confused about.

I'm not confused about anything.

I think you were confused by my example. It was not meant to be a workaround for Spark users (since currently Spark will just add the location if it's not there), it was meant to be used if creating the Sentry bug report ("this command should work but fails, and the corresponding command without the explicit location works").

Can one of the admins verify this patch?

I don't think working around a bug in Sentry is a good reason to add a hack in Spark. HiveExternalCatalog is already full of hacks...
If you have a proposal to clean that up and can also work around the Sentry bug, that will be great.

@vanzin @cloud-fan. Going back to the facts. The fix/work-around in Cloudera's distro obviously exists because the distro integrates with Sentry anyway. Removing the location did fix the Spark Job at the customer side. To re-phrase the last request from @cloud-fan, if we remove the explicit location what are the consequences, when do you need the explicit location for managed tables? Can this be a default behavior in general?

To weigh in a bit, we're one of the larger enterprises that hit this bug, which we consider a regression going from Spark 1.6.3 (on Mesos, attempting to perform DDL to a Hive instance on CDH) to >= 2.1.x.  I think many more large enterprises will hit this with Spark on K8S to any Sentry-secured Hive databases.
IMO, this commit, while well intended in removing some of the hacks for 2.1.0, was a reversal of Spark's sort-of-implicit-commitment to have Sentry/Hive DDL work.  I agree this should be fixed upstream in Sentry too, but that would be a long wait for us:  creating tables in Mesos Spark 2.x is blocking 100's of devs from upgrading to Spark 2.
Basically, the hacks / workarounds had existed in the past and were working.  Please add a workaround back until Sentry can fix the location issue on their side.

I don't disagree with what you guys are saying, but I also don't have the context of why the original change was made.

Can one of the admins verify this patch?

@vanzin any decision on this?

I didn't make the original change so I'm refraining from making a decision about whether this should go in. Perhaps another fix is desired, perhaps the current behavior is desired, but either way this isn't an area where I'm comfortable making these kinds of decisions.
(CDH is another thing altogether.)

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?


remove vendor dependencies for build/lint/test rules in Makefile

Without vendor the build will fail. Why do we need to remove vendor from build dependencies?

Without vendor the build will fail. Why do we need to remove vendor from build dependencies?

I think we expect that user doesn't have to do glide update when building binary locally.
All the vendor pkg update shall be committed along with the actual feature code change via PR.
This doesn't remove vendor update rule in Makefile, it can still be updated via make vendor, but this will likely be used by developers to run the glide update.

I think make dependencies are behaving as expected. The reason this build failed because the glide files were updated where the required updates in the vendor were missing. So make did the correct course of action by trying to glide update because vendor weren't updated. If you look at other build history, the glide update is not triggered for all build.
We just need to make sure that vendor dir is updated whenever dependencies are updated in the glide.yaml and glide.lock. IMO having the vendor prerequisite helps us identifying this kind of issue from travis-ci. What do you think?

I think make dependencies are behaving as expected. The reason this build failed because the glide files were updated where the required updates in the vendor were missing. So make did the correct course of action by trying to glide update because vendor weren't updated. If you look at other build history, the glide update is not triggered for all build.

In Makefile, glide update is triggered due to glide.lock or glide.yaml file changes, not a missing vendor pkg. When the timestamp of vendor pkg folder is older than glide.lock or glide.yaml, even if there is no vendor pkg missing (meaning build can pass without updating vendor pkg), glide update will also be triggered. In such case, I think we shall not trigger vendor update.
Let's say if there is indeed a vendor pkg missing, then we shall expect the building of binary fail, not glide update is executed. because the reason why vendor pkg gets updated is that new code imports a new vendor pkg. If we allow every build to update vendor pkg via glide update, then there might be case that it doesn't report missing vendor pkg failure when building binary.

We just need to make sure that vendor dir is updated whenever dependencies are updated in the glide.yaml and glide.lock. IMO having the vendor prerequisite helps us identifying this kind of issue from travis-ci. What do you think?


Allow for plugin use without Conda

Closes #60.

[x] I have added the tests to cover my changes.
[x] I have updated the documentation, VERSION, and CHANGELOG accordingly.
[x] I have read the CONTRIBUTING document.

@wjcunningham7 --- thoughts on this one? I think this should be ready to go whenever you agree.

This should be good to go now.
One comment:

My personal opinion is that we should remove the source $HOME/.bashrc line. If the user needs to source their .bashrc, they should include that as a prerun_command. We don't want to force the sourcing of the .bashrc (for instance, on NERSC, there are several .bashrc files and the usual $HOME/.bashrc isn't always the desired one). I've removed the line altogether, but if you disagree, let me know.

@wjcunningham7 --- FYI there are some sporadic GitHub actions test failing both PRs. Might need to have them retriggered later.

It wasn't actually clear to me why we are sourcing the bashrc. Wouldn't the bashrc be sourced already, just like it is at login? I don't think I've ever had to source the bashrc in my Slurm jobs, personally.

It wasn't actually clear to me why we are sourcing the bashrc. Wouldn't the bashrc be sourced already, just like it is at login? I don't think I've ever had to source the bashrc in my Slurm jobs, personally.

It depends on a few things -- the default shell on the system, the behavior of sshd, and the behavior of asyncssh.  For perlmutter it looks like this may not be necessary.  In general, the bashrc file is only sourced if the shell is interactive.  Additionally, even if SSHD does source bashrc for non-interactive connections, the bashrc skeleton (at /etc/skel/.bashrc) often includes a return statement for non-interactive shells.  Since there are a few variables in play here, we can't necessarily assume a system we haven't interacted with before will source the file automatically.
All that being said, the pattern here has been applied in a few different ways across different plugins, and it appears to me that asyncssh always uses an interactive shell.  So it may not be necessary at all!

Ah that's useful context! Well, good news is that if a user doesn't want to source anything, they don't have to now. They can just do bashrc_path = False, so at worst we just have an additional config option that can maybe be deprecated eventually (and replaced with an additional prerun_command by the user).


Problem loading editor template when Areas are applied

Given an application that uses areas and has the following folder structure.
\Areas
	\Admin
	          \Views
			\Home
			\Shared
				\EditorTemplates

If inside the EditorTemplates there is a view called Custom.chtml loading it using dynamically is possible only by providing the full path to the view. For example if we are loadining it using the following code.
private string GetEditorForModel(IHtmlHelper htmlHelper, string templateName, object additionalViewData)
{
  //....
  IHtmlContent editorContent;

  if (templateName.HasValue())
  {
    editorContent = htmlHelper.EditorForModel(templateName, additionalViewData);
  }

Calling GetEditorForModel("Custom", ....) will not work while calling GetEditorForModel("~/Areas/Admin/Views/Shared/EditorTemplates/Custom.cshtml", .....) will.

Thanks for contacting us, @ag-petrov.
In order for us to investigate this issue, please provide a minimalistic repro project that illustrates the problem.

Hi @mkArtakMSFT , here  is a small sample that illustrates the problem.

Thanks for contacting us, @ag-petrov.
@NTaylorMullen, can you please look into this? Thanks!

Hi @ag-petrov in your ViewContextForType you're not passing in the pre-existing view context's RouteData so it doesn't know it's coming from an Area.
Aka:
public static ViewContext ViewContextForType<T>(this ViewContext viewContext, IModelMetadataProvider metadataProvider)
{
    var actionContext = new ActionContext(viewContext.HttpContext, viewContext.RouteData, new ActionDescriptor());
...

Adding RouteData to the newly constructed ActionContext makes things work.

@NTaylorMullen thank you. I did not see that.


NotaryRepository refactor proposal

NotaryRepository is sort of one big monolithic object with a lot of things on it right now, mostly made together to serve the CLI and may not necessarily make sense for something that uses NotaryRepository as a library.  Also, the fact that everything is bound to a single config directory, and a URL, makes testing slightly more inconvenient.
The proposal is to break up NotaryRepository into a two or three composite pieces, and to clean up the package tests to try to inject more in-memory objects as opposed to creating a temp directory, running a whole server so the repo can update, etc.  (the integration tests for the CLI should of course continue to do so).
We could keep the function NewNotaryRepository to conveniently create a single repo given a config directory, and possibly with the roundtripper, etc. as well.  But it'd be good to have NotaryRepository that can use other implementations of cache/remote stores etc.
Update:  This would also address/supersede #932 and #380.
NotaryRepositoryChanger object
I am completely uncommitted to the name, just the first thing that springs to mind.  Basically this wraps a changelist.Changelist object and the following functions will be attached to it:

AddTarget
RemoveTarget
GetChangelist (this function maybe can just be removed, because it doesn't make sense)
AddDelegation
AddDelegationRoleAndKeys
AddDelegationPaths
RemoveDelegationKeysAndPaths
RemoveDelegationRole
RemoveDelegationPaths
RemoveDelegationKeys
ClearDelegationPaths

As far as I can tell, none of these functions require anything from NotaryRepository except the tufRepoPath field to tell it where to create a new FileChangelist.
In addition #700 suggests that Initialize should also create a set of changes to be applied, as opposed to create some initial metadata.
Proposal 1: completely break up NotaryRepository into 2 objects

A NotaryRepositoryInfo object (again, I am completely uncommitted to the name) - this just wraps a tuf.Repo object and just gets random useful information on it.  The following functions will be attached to it (and they will stop calling Update - the user should explicitly call something to obtain the latest on the repo first, and then we can get all sorts of information from the repo without having to re-download new data every time):

ListTargets
GetTargetByName
GetAllTargetMetadataByName
ListRoles
GetDelegationRoles

A constructor probably only take a tuf.Repo, and maybe a GUN just for informational purposes.

  The following functions will be attached:

RotateKey
Publish (which should now take a changelist.Changelist object as an argument; the unexported private publish function already does)
DeleteTrustData

A constructor should probably only take a store.MetadataStore to use as a cache, store.RemoteStore to use to update the tuf.Repo object, a signed.CryptoService for signing, and maybe a GUN for informational purposes.

Other changes:

bootstrapClient and Update:  I think can these be rolled into TUFClient, and TUFClient can be a helper object that will download you the latest version of a tuf.Repo, which can be used to construct a NotaryRepositoryInfo object or used byNotaryRepositoryWriter.  Alternately, maybe TUFClient and NotaryRepositoryInfo can be the same object, as the comment for it suggests it might be.

Initialize:  If we don't want to move this to NotaryRepositoryChanger, maybe it can be a standalone function that takes a store.MetadataStore to write the initialized metadata files to and a signed.CryptoService for generating keys and for signing?  It can return a NotaryRepositoryWriter object, since if it's empty, there's probably no point in reading anything from it.

Proposal 2: keep the NotaryRepository object, but change function signatures
The NotaryRepository object will remain an object with both read and write functionality, and without all the NotaryRepositoryChanger functions.
However, the constructor will only take a store.MetadataStore to use as a cache, and a GUN for informational purposes.
The following function signatures would change:

Initialize should also take a store.RemoteStore and a signed.CryptoService, if we don't want to move it to NotaryRepositoryChanger
RotateKey should also take a store.RemoteStore and a signed.CryptoService
Publish should also take a changelist.Changelist, a store.RemoteStore and a signed.CryptoService
DeleteTrustData should also take a store.RemoteStore

I think it would still be awesome to roll bootstrapClient and Update into TUFClient, and TUFClient.

cc @endophage @riyazdf @HuKeping @ecordell

also see https://github.com/docker/notary/issues/932

@HuKeping Ah yes, thanks, I was looking for that one and for some reason my eyes kept skipping over it.

Related, but not part of this particular proposal:  I just wanted to leave a breadcrumb here since the previous issues about this were already closed.
@ecordell made the awesome suggestion of making some of the parts of notary more "batteries removable", such as the x509 requirements:  https://github.com/docker/notary/issues/794#issuecomment-231818928, https://github.com/docker/notary/issues/977#issuecomment-251482246
Also, https://github.com/theupdateframework/taps provides some nice augmentation proposals that will maybe make it into TUF, but it would be nice to have cleaner interfaces for library writers to plug in extra features that they might want to support.
I don't really have any concrete proposals about this yet, so I didn't open a new issue, but since we're discussing some of the refactoring I thought I'd mention it as well in case anyone had any good ideas.


Please included drawwhitespace from rxi/lite-plugins

Kindly add drawwhitespace form rxi/lite-plugins here.

The functionality is included by default on 2.0.5 and can be enabled by setting config.draw_whitespace=true in your user module.


[21.11] evolution 3.42.1 -> 3.42.4

Description of changes

When debugging #168645, I noticed that release-21.11 does not carry the newest minor release of Evolution. Judging from the commit history it contains quite a bit of bug fixes that might be relevant to people.
See also #169058 for an Evolution regression fix.
I've tested these versions with my daily driver email setup.
@NixOS/gnome
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Evolution-Data-Server 3.42.4 2022-02-11
Bug Fixes:

I#374 - LDAP: Let open when server is offline and marked for offline work

Miscellaneous:

IMAPx: Avoid creating NOSELECT CamelFolder-s
CamelMimeFilterCRLF: Correct encoding part of the filter
CamelMimeParser: Correct body content parse when CRLF is used
camel-net-utils: Allow NULL string arguments in IDNA/ASCII functions

Evolution 3.42.2 2021-12-03
Bug Fixes:

I#1679 - e-convert.js: Do not re-wrap gmail_quote paragraphs (Milan Crha)
I#1696 - Composer: Consider only accounts, which can send messages (Milan Crha)
I#1697 - e_text_to_html_full: Use large enough buffer for character escape (Milan Crha)
I#1708 - Composer: Wrap quoted long words (Milan Crha)
I#1712 - Tasks: Correct overdue calculation for DATE value type (Milan Crha)
I#1714 - Composer: Prefer HTML over image on LibreOffice data paste (Milan Crha)
I#1715 - Calendar: Ensure value type matches for start/end, start/due (Milan Crha)
I#1717 - ECalModel: Properly show also UTC times (Milan Crha)
I#1721 - Calendar: Leftover tooltip after event delete (Milan Crha)

Miscellaneous:

Misc: Generate appdata  from the NEWS file (Milan Crha)
news-to-appdata: Escape text exported to XML (Milan Crha)
flatpak: Update build manifests (Milan Crha)
Calendar: Cannot always remove custom reminder message (Milan Crha)
Composer: Don't show blockquote indicators on both sides for 6th+ level (Milan Crha)
Calendar: Not all task lists included in the task panel (Milan Crha)
Load JavaScript plugins for message preview and WebKit editor (Milan Crha)
icalendar-importer: Can show incorrect time in imported data preview (Milan Crha)

Translations:

Rūdolfs Mazurs (lv)
Quentin PAGÈS (oc)

Evolution 3.42.3 2022-01-07
Bug Fixes:

I#1571 - Broken font settings can break message display
I#1729 - Composer: Forward can lost unreferenced attachments with Content-ID
I#1747 - ETableColumnSelector: Correct column names' translation (Ivan Chevychelov)
I#1756 - Mail: Let always available Go To->Previous/Next Unread Message
I#1757 - Add icons for mail-smart-backward and mail-smart-forward
I#1758 - Calendar: Adapt to libical 3.0.12 change

Translations:

Gianvito Cavasoli (it)

Evolution 3.42.4 2022-02-11
Bug Fixes:

I#1763 - Composer: Correct line wrapping with a link followed by a text
I#1783 - EShell not emitting activate signal

Miscellaneous:

Use gtk_widget_is_visible() instead of gtk_widget_get_visible() on some places
Composer: Backup from toplevel BLOCKQUOTE on split for Undo/Redo
Composer: Special-case requote of BLOCKQUOTE nodes in Plain Text mode
Composer: Various changes for Plain Text re-quote
ECompEditor: Timezone can be reset on component save

Translations:

Boyuan Yang (zh_CN)
rofiquzzaki rofiquzzaki (id)

Evolution-EWS 3.42.3 2022-01-07
Bug Fixes:

I#174 - Silently retry on I/O errors (like 'Connection terminated unexpectedly')

Miscellaneous:

Misc: Hide some headers' value in EWS_DEBUG=2 output

Evolution-EWS 3.42.4 2022-02-11
Bug Fixes:

I#77 - Can sometimes stop listening for server notifications

Miscellaneous:

Misc: Correct response print in debug output
Retry on Unauthorized response when server disconnected
e-ews-connection: Clear cached connection before sending a request

Translations:

Daniel Șerbănescu (ro)

Thanks.


Token Count Difference (Followup)

The token count for Tools is still having a difference of 1.
Request Body:
{
	"model": "gpt-4",
	"messages": [
		{
			"role": "assistant",
			"content": null,
			"tool_calls": [
				{
					"id": "call_Id8ycVMsW8gdsf7kSXfgAcf1",
					"type": "function",
					"function": {
						"name": "get_current_weather",
						"arguments": "{\n  \"location\": \"Boston, MA\"\n}"
					}
				}
			]
		},
		{
			"role": "tool",
			"tool_call_id": "call_Id8ycVMsW8gdsf7kSXfgAcf1",
			"name": "get_current_weather",
			"content": "29 degree celcius"
		}
	]
}

My count: 34
OpenAI Count: 35
My guess is that even "tool" role requires 3 tokens.
Thanks

I just saw you've reopened #4 , closing this one as duplicate.


error: Function not implemented (os error 38)

i'm currently using M1 mac Air and docker
os version: macOS Monterey 12.4
docker version: Docker version 20.10.16, build aa7e414
docker-compose version: docker-compose version 1.29.2, build 5becea4c
error step
step 1
run deno run -A -r https://fresh.deno.dev test
step 2
make docker-compose.yml
version: "3.3"
services:
  test:
    container_name: test
    image: denoland/deno:latest
    working_dir: /test
    ports:
      - "8000:8000"
    volumes:
      - ./test:/test
    entrypoint: >
        sh -c "deno task start"

step 3
run docker-compose up
then
you can see like below
Warning deno task is unstable and may drastically change in the future
Task start deno run -A --watch=static/,routes/ dev.ts
Watcher Process started.
error: Function not implemented (os error 38)

i got it. there is no official deno image for arm architecture
so i use lukechannings/deno (https://github.com/LukeChannings/deno-arm64) image
version: "3.3"
services:
  test:
    container_name: test
    image: lukechannings/deno:latest # changed
    working_dir: /test
    ports:
      - "8000:8000"
    volumes:
      - ./test:/test
    entrypoint: >
        sh -c "deno task start"


Add a linter and associated Travis checks.

This is a test branch for introducing a linter -- please don't review yet.
Still TODO:

[x] Fix deliberately-introduced lint issue, once it is confirmed that Travis catches it and blocks the submit accordingly.
[x] Update config options.

This is (finally) done, I think! Requesting review from @eyurko.
/cc @apicardgoog @rabidbit

FYI, to run the linter, just run the following from the command line:
 bash scripts/run_linter.sh

I'll add this info to the playbook, too.


Drop support for Python 3.6

Closes #5699.

Jenkins, test this please.

Jenkins CI test (for commit f32300d95e5a2de7d3673e5143e516a73db61907, target branch master) failed with status FAILURE.

pfnCI, run Jenkins please.
Will trigger FlexCI after image rebuild: https://ci.preferred.jp/cupy.prep-linux/79597/

pfnCI, run Jenkins please.

pfnCI, run Jenkins please.
Will trigger FlexCI after image rebuild: https://ci.preferred.jp/cupy.prep-linux/79613/

All tests passed except for cupy-py36 (which is expected).
I'll exclude running cupy-py36 for master branch after this PR got merged.

All tests passed except for cupy-py36.


Display Emotional State Images in Spinner

In the emotional state spinner there should be images of the emotional states displayed alongside the list items.
This might involve making a custom adapter.

I got display emoticons in the mood spinner to work and have pushed it to origin/dev.

Reopened because the implementation is not that clear and many things are unessesary. In addition, issues should only be closed when they reach master.


Fix/current time is hard to read when number of decimal places keeps changing

Problem
The current time display in the playback controls is hard to read when the number of decimal places keeps changing:

Solution
Left-align the current time value instead of centering it:

@blairlyons brought this issue up again (issue has been mentioned before but we never discussed solutions) and this was the simplest solution I could think of.
Type of change
Please delete options that are not relevant.

Bug fix (non-breaking change which fixes an issue) - Actually this is more like a design change, but it feels like a bug fix

I wonder if it would be possible to keep the decimal point in the same spot...


[Audit][Implementation] - Use only supported locales to reduce the APK size

Details

This PR is part of Audit by callstack and is concerned with reducing the APK size. Since it's regarding APK size, it only affects android.
Applications often have dependencies which supports multiple locales. These translations strings are then made part of the APK that is installed by the user. So the user is installing an APK which has translations which he will not even use because it's not supported by the application. For eg, Expensify only supports en and es, so there's no point compiling all other locales in the APK.
Take a look at below screen shot, which has whole lot of other locales like Arabic which we don't even need. They come as part of google-play-services-core, material etc.

We can remove all the non-supported locales by explicitly telling android build tools that we support only en and es. See below how unused strings are then removed from resources.arsc

We managed to reduce the resources.arsc from 3.4MB to 1MB in raw file size. Let's see the impact of this on the APK size. We will benchmark this on the results gained from this PR, they are not related but to only show the final benchmarks from these two PRs:
Before ( linked PR ):
| APK Size MB | Download Size MB
-- | -- | --
All architectures | 103.1 | 99.3
  |   |
After:
| APK Size MB | Download Size MB
-- | -- | --
All architectures | 100.8 | 98.7
  |   |

We get 2.3 MB of reduction in APK size and 0.6 MB of reduction in Download size 🚀
Fixed Issues

$ https://github.com/Expensify/App/issues/39700
PROPOSAL: https://github.com/Expensify/App/issues/39700
Tests

Testing Steps:

Switching between English and Spanish locales should work fine

[X] Verify that no errors appear in the JS console

Offline tests

QA Steps

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[X] I linked the correct issue in the ### Fixed Issues section above
[X] I wrote clear testing steps that cover the changes made in this PR

[X] I added steps for local testing in the Tests section
[X] I added steps for the expected offline behavior in the Offline steps section
[X] I added steps for Staging and/or Production testing in the QA steps section
[X] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[X] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[X] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[X] I included screenshots or videos for tests on all platforms
[X] I ran the tests on all platforms & verified they passed on:

[X] Android: Native
[X] Android: mWeb Chrome
[X] iOS: Native
[X] iOS: mWeb Safari
[X] MacOS: Chrome / Safari
[X] MacOS: Desktop

[X] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[X] I followed proper code patterns (see Reviewing the code)

[X] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[X] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[X] I verified that comments were added to code that is not self explanatory
[X] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[X] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[X] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[X] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[X] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[X] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[X] I verified the JSDocs style guidelines (in STYLE.md) were followed

[X] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[X] I followed the guidelines as stated in the Review Guidelines
[X] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[X] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[X] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[X] I verified that if a function's arguments changed that all usages have also been updated correctly
[X] If any new file was added I verified that:

[X] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[X] If a new CSS style is added I verified that:

[X] A similar style doesn't already exist
[X] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[X] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[X] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[X] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[X] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[X] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[X] I verified that all the inputs inside a form are aligned with each other.
[X] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[X] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[X] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/47336142/51fe983f-257a-4e56-a3e6-47f27d2baf85

Android: mWeb Chrome

N/A

iOS: Native

N/A

iOS: mWeb Safari

N/A

MacOS: Chrome / Safari

N/A

MacOS: Desktop

N/A

@hurali97 Conflicts.

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

Hey @Julesssss
I went through automatic per-app language support and it looks like it's designed for android only projects. Which means the projects which keep their language resources in this format res/values-fr/strings.xml. We can set the default locale in resources.properties but for the alternative language we will have to follow the format and keep our strings there and since Expensify is a RN project this doesn't fit.
This is to only enable the language switcher for the app from settings and it doesn't remove any other unused locales from the dependencies, so it's not worth adding.
If we are concerned about adding new language in the future, can we update ReadMe or language docs to include this information that you have to add let's say fr to resConfigs in app/build.gradle?

@hurali97 ah okay no worries and thanks for explaining. That's a shame.
I'm still worried that this is going to confuse people who add languages in the future, but maybe a comment above the Gradle config would make this a bit easier to locate. Something like this maybe: // Language variants must be declared here to avoid the resources from being removed during compilation

@hurali97 ah okay no worries and thanks for explaining. That's a shame.
I'm still worried that this is going to confuse people who add languages in the future, but maybe a comment above the Gradle config would make this a bit easier to locate. Something like this maybe: // Language variants must be declared here to avoid the resources from being removed during compilation

Yes makes sense, I will add it 👍

Conflicts resolved on behalf of @hurali97 as he is out of office. Feel free to hit me up anytime needed with the PR 👍

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/Julesssss in version: 1.4.62-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/Julesssss in version: 1.4.62-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/Julesssss in version: 1.4.62-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/thienlnam in version: 1.4.62-17 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Issue with grpc_logging example

Hi - I tried to compile the grpc logging example and received the following error:
wasm_compile_log_1     | In file included from examples/wasm-cc/plugin.cc:1: wasm_compile_log_1     | examples/wasm-cc/plugin.h:1:10: fatal error: 'extensions/grpc_logging/config.pb.h' file not found wasm_compile_log_1     | #include "extensions/grpc_logging/config.pb.h" wasm_compile_log_1     |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ wasm_compile_log_1     | 1 error generated.
Are there files missing? or am I doing something wrong? Thanks!

How did you compile it?

I replaced the source in the envoy example here with grpc_logging:
https://github.com/envoyproxy/envoy/tree/main/examples/wasm-cc
Should I compile it differently? what is the best way to do a simple test on envoy?


Refactor so we can use different implementation handlers (e.g. fake and real) with the same underlying types

The main purpose of this PR is to enable us to hook up the under-development implementation model to the concrete properties without breaking or losing our fake implementation and proofs about it.  This further enables proving multiple variants on an implementation.  The main changes are:

Refactor Yasm so that we first instantiate it with the types, and subsequently instantiate it with initialisation information and handlers.
Tease apart Concrete namespace from Impl*, so that anything it needs to know about an implementation is provided as a module parameter, not directly from an implementation as it did before.

As a result, there is one new proof (NewVoteRound≢0) required in LibraBFT.Concrete.Properties.VotesOnce and an implementation obligation is provided about honest votes that should enable this proof.

Move initialisation-related information (mostly postulated for now) into LibraBFT.Impl.Consensus.Types, so both Impl and FakeImpl can share it.
Establish ImplementationObligations for the fake handler (FakeInitAndHandlers); the real implementation will need one too, and it can use the same genesisInfo and initRM, while providing its own handlers.

I had some naming conflict pain and couldn't easily resolve it the "right" way, so had to rename some things to avoid the conflict.  Not ideal but expedient.
I have tried to separate this work into coherent commits (including a couple that are indent-only), but there is no guarantee that each commit builds successfully.
@cwjnkins, this should enable you to establish a handler for the real implementation model, and work towards creating ImplObligations for it, analogous to theImplObligations in LibraBFT.ImplFake.Properties.
@lisandrasilva, assuming we merge this or something like it, it should be a good time to port a version of your proofs in #43.  I would suggest looking at the changes to LibraBFT.Concrete.Properties.VotesOnce first, as you will likely have to make similar changes.  P.S., I bet you can't prove NewVoteRound≢0 😉

From what I can tell, this looks good! The best test though is for me to merge this into my current work and see if I can write stubs for the proofs of the implementation obligations for the more realistic implementation, so I will do that now.

@mark-moir This is perhaps only partially related, but I think that it would make sense for this PR to also move the  code in LibraBFT/ImplFake/Handle.agda responsible for converting List Output to List (Action NetworkMsg), since all types mentioned are shared between both the fake and real implementation handler.
(Context: to connect the contracts for the peer handler to the system state, I am finding we will need some lemmas relating the outputs of e.g. processProposalMsgM to the list of actions produced from this using outputsToActions).

Oh, I see now that since this PR is on a branch which still has MetaEpochIndep.agda, moving outputsToActions near the definition of Output in this PR does not make sense -- better to wait until we remove MetaEpochIndep.agda from the main branch.

Oh, I see now that since this PR is on a branch which still has MetaEpochIndep.agda, moving outputsToActions near the definition of Output in this PR does not make sense -- better to wait until we remove MetaEpochIndep.agda from the main branch.

Great, thanks @cwjnkins.  I asked @haroldcarr to review only to keep him in the loop, but he's out, so I'll merge now.


Sublocation does not display existing data in Item Edit (so you have to re-enter that or it becomes blank)

Should be fixed now.


planning_gflag.cc:194 parament config question

apollo5master.
in file planning_gflag.cc:194:
DEFINE_double(planning_upper_speed_limit, 31.3,
"Maximum speed (m/s) in planning.");
31.3m/s means 112.68km/h. Is it too fast to apollo?

@BigBenSure that's the upper bound.  31.3 m/s = 70 miles/hour.  the speed limit of most freeway in US are 65-75 miles/hour.

@BigBenSure that's the upper bound. 31.3 m/s = 70 miles/hour. the speed limit of most freeway in US are 65-75 miles/hour.

thank you!