Code editor not opening in Bot Composer

When I add a trigger, Send a Response and go to the properties pane on the right and Click on Go to Code Editor,
it pops up : Something went wrong.....

Error Detailed Screenshot

@achint740 Can you stable reproduce this error, or if you restart Composer still see this?

@zhixzhan this error pops up even after restarting.
I have tried re-installing the Composer many a times as well.
Reproduce the error

Open any Bot.
Go to a Dialog.
Add "Send a Response field".
Go to properties pane on the right.
Switch to Code editor. This error pops up.

@achint740 can you share the bot? I did not see  this on latest build with empty bot example.

@zhixzhan Here is the bot. I have attached the zip file.
Reproduce the error :

Go to Greeting Dialog
Go to the empty trigger below the Welcome User trigger.
Select it and go to properties pane on the right.
Click on "Switch to Code Editor".
Error pops up, click on OK and the code editor goes to a locked "Loading State".

Reproduce the error (Way 2)

Go to Greetings Dialogue.
Click on "Show Code" in the top right.
Error pops up, click on OK and the editor goes to a locked "Loading State".

BotSample_first.zip

@zhixzhan I have assigned this issue to you. Please keep helping the customer on this issue.

@ninggao Sure, I can follow on this.

@achint740 Which Composer version are you using? I have try your bot on Composer v1.4.1 it works as expected.

@zhixzhan I am using Bot version 1.4.1 only

I have opened the same on Composer v 2.0, even after converting it shows the same!

@achint740 Can this error reproduce on a new created bot ?  Are your using nodejs v14+ ？

Yes, this error reproduces on every bot I create.
Node Version :

@achint740 Did you try add some other filed,  delete an existed filed, or add a trigger to see if it's LG only issue or all bot resources are not be able to write.
And if it is possible, can you record a video, it would be very helpful for us to debug it.

@zhixzhan Here is the video. Might be a bit blur.
https://user-images.githubusercontent.com/42889869/118634763-879a4300-b7f0-11eb-8a3f-5fb89c1725e2.mp4
Also, I tried creating the Ask a Response trigger and the same issue pops up there.

@achint740 It looks you are running Composer inside a virtual machine. Could you see if you are able to repro it on a non VM instance. We have tried to repro this error and are unable to.

@srinaath Yes I am running it on a Virtual Machine since I have to work on that only for my work.
I tried it on a non-VM machine. No error there.
But the whole bunch of my work is on my VM only.

@achint740 Could you paste a snapshot of the Chrome Developer Tools, networks tab and console tab view for us to see what if any network calls are failing.

@hatpick also identified that this PR https://github.com/microsoft/BotFramework-Composer/pull/5547 to download monaco and fabric assets would allow offline usage of the assets.  @jwiley84 also something to consider in investigating this ticket.

Console

Network

@srinaath

@hatpick We can definitely confirm your investigation. https://github.com/microsoft/BotFramework-Composer/pull/5547/files#diff-96bd06513353b0cd4b08269cfe491f21242a411b7189a5017e2735c68021c1a1R8. The network call fails at loading monaco.

@srinaath Are you saying this error is caused by some resource of Monaco editor didn't load, or network issue in VM ?  I tried offline open Composer, when I click a trigger, it popup error immediately, seems different from this case.

Could this caused by some file system write issue in VM? In @achint740 's video, when delete a trigger will also meet this error, even Monaco editor is not opened

@srinaath Are you saying this error is caused by some resource of Monaco editor didn't load, or network issue in VM ? I tried offline open Composer, when I click a trigger, it popup error immediately, seems different from this case.

Could this caused by some file system write issue in VM? In @achint740 's video, when delete a trigger will also meet this error, even Monaco editor is not opened

FS is less likely to have issues, and even when it have issues, it's an issue in persistence layer and the error message should be clear.
I guess it's still related to manaco editor, and probably the firewall\NSG in VM blocks the manaco editor download.
How about we create a customized build including @liweitian's previous fix and ask customer to try again?

I created a build task on the Monaco fix branch.
https://fuselabs.visualstudio.com/Composer/_build/results?buildId=246786&view=results

@achint740 Here I uploaded the above fixed build, can you try it?
https://github.com/zhixzhan/BotFramework-Composer-1/releases/tag/v2.0.0

@zhixzhan thankyou so much for your co operation.
I installed the fixed build. It's working all fine. No error.
The code editor is opening as well :)

Thanks to @srinaath @boydc2014 and @ninggao and all others for helping out

We will look to incorporate this PR in our next release. @liweitian  can we make sure this PR gets merged. Thanks. Closing the ticket now


Stop asking me to find a latex extension

When writing LaTeX, sometimes VS code will open up a dialog asking me to install a LaTeX extension. When I click on the button to search for LaTeX extensions, nothing comes up. I don't want to use a LaTeX extension. I'm fine with the highlighting that I have. There's no way to disable the pop-up, and it interrupts my LaTeX writing workflow. Can we add a checkmark to never ask again?

Does "extensions.ignoreRecommendations": true work for you?


fatal: Not a git repository (or any parent up to mount point /opt/nodemcu-firmware)

livecd Ubuntu 16.04 LTS, after installing git and docker (17.05.0-ce):
cd ~
git clone https://github.com/nodemcu/nodemcu-firmware.git

Cloning into 'nodemcu-firmware'...
remote: Counting objects: 14202, done.
remote: Compressing objects: 100% (52/52), done.
remote: Total 14202 (delta 23), reused 30 (delta 12), pack-reused 14138
Receiving objects: 100% (14202/14202), 100.65 MiB | 3.67 MiB/s, done.
Resolving deltas: 100% (9499/9499), done.

Ok..
cd ~
git init
cd /
sudo git init

Ok, one more time
cd ~
sudo docker run --rm -ti -v `pwd`:/opt/nodemcu-firmware marcelstoer/nodemcu-build

fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

how to fix it and build? Thanks.

https://github.com/marcelstoer/docker-nodemcu-build#run-this-image-with-docker

...and change to the NodeMCU firmware directory (in the Docker console). Then run...

cd ~/nodemcu-firmware
docker...

I am having the same problem
it is not that I did not enter the firmware directory after the git clone, but rather:
[rafael@asusraf nodemcu-firmware]$ docker run --rm -ti -v $(pwd):/opt/nodemcu-firmware marcelstoer/nodemcu-build bash
root@f2e68fbc3563:/opt/nodemcu-firmware# ls -l
ls: cannot open directory '.': Permission denied

One would ask how is it that an image running as root cannot access any directory?
That rings the bell as SELINUX or similar

yes.
sudo setenforce 0

I use fedora 31 that has SELINUX enabled, apparently.


Downloading file from internet with UrlVfs.

I want to download a file with UrlVfs:
UrlVfs("https://raw.githubusercontent.com/korlibs/korio/master/README.md").copyTo(resourcesVfs["readme.md"])

This however creates a readme.md that doesn't contain the plain text I was expecting:�      �R]o�0}ƿ�� B�G���A���4M �\7q3'�l'���ݤ	��yp>��{N���y5�RQ9a��
^�,s,��w���X�ν¹�F����tE�i�0�����T��^%7v��J�ڲ�[�f+HM�*��%$fuBH\S=k̊�+?-
�F;%+�f_ ��3���·�WX(��l%L+~��Z�V�m����_�`����������
|?y��E̡0b{�a��tq�O�ԕ�����T�䮱;���is�Uzg��mx�j�޹��!
��&+�IZ�VTT��q��1ħV���_t��{��<�z�
�7\M�b��*�g{?ݷ���$��̤M�ɺ^\��}�g���[� �΃�,��0<�p�?
9�����l��s�cgG���lW�R��iS�^��2�x���RC8��
�a���)�^�����a��𻏭�m0���@H&jQe�JM����#�缍���іѫ��N��v�����

It takes ~40 seconds to download this 3kb file.
It isn't possible to use custom headers.

The problem is that the download encoding is GZIP. So it should be instead:

UrlVfs("https://raw.githubusercontent.com/korlibs/korio/master/README.md").copyTo(resourcesVfs["readme.gzip"])

Then I need to uncompress the file manually with
resourcesVfs["readme.gzip"].readBytes().uncompress(GZIP).toString(UTF8)

Any idea, why the download takes so long?

Was not aware of that. Can you curl or wget with speed info and compare? Feel free to create a separate issue for that


Feature/20 Project Overview/Search: Rework of some UI controlls

@MirusVirus Please do not close PR's. They are done when they are merged and in general are not being closed manually.


[ISSUE-426] add prefetch event to state machine

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


.gradle directory in version control

Issue type
Wrong or misleading information
Problem description
In this section, it is mentioned that the .gradle directory is usually checked into source control.
I think you meant the gradle directory, without a dot.
Context (optional)
No response
Page with the problem
https://docs.gradle.org/current/userguide/gradle_directories.html

This is already addressed in

https://github.com/gradle/gradle/pull/30058
It's in master, but cherry-picking it to release so it's available faster:
https://github.com/gradle/gradle/pull/30154


Gateway should restart backoff timer after it succesfully connects

Right now, each time it connects the timer increases and it should only do that when a connection fails and reset after it's successful.

@conectado I believe this has already been completed?

@jamilbk no, I think the timer still increases with each transient error


aggregate plugin measurements into a single measurement

It might make sense to aggregate the readings from a plugin into a single measurement, rather than having multiple measurements with matching timestamps. For example, the disk plugin currently sends multiple measurements (total, free, used, etc...), each containing a single field called value. This would be changed to a single measurement named disk with multiple fields (total, free, used, etc...) in it. The advantage of this would be that we could calculate derived values from such measurements in influxdb 0.9+. For example, the disk plugin currently has no option to calculate percentages and send those as well. If all the values were in one measurement, the percentages could be calculated on the fly, and the disk plugin would not have to support calculating and sending percentages.

That's a very good point, I like this idea
/cc @beckettsean @toddboom what do you guys think? Any reason not to have a plugin's output contained within a single series?

@sparrc I do think it makes more sense to write into a single measurement with multiple fields, rather than decoupled measurements. It makes math on the results much easier.
The downside is that it means querying disk_free requires pulling all the points from disk, including the other unused fields. That's potentially a lot of unnecessary I/O if users are only graphing one value. Then again, all values can be trivially queried with a single select statement.

How about leaving it as is, with single fields, and adding another measurement with all fields combined.

@beckettsean wouldn't it just be SELECT disk_free FROM disk rather than SELECT * FROM disk_free?
@skynet is there a reason that combining the fields into a single measurement won't work for you?

@sparrc SELECT disk_free FROM disk still has to pull the entire point from disk, including all field values. The DB cannot extract only the disk_free field. It's not a huge consideration but one thing to watch for after the switch.
Perhaps we can make it a configuration option? Some users want it all in one measurement, some want it in multiple measurements. Rather than doubling the data by writing to both let's give users the choice.

Sounds fair, I guess I'm just worried that it might confuse and overly complex the documentation,
ie,
Querying Data
To get CPU Idle percentage, use
SELECT cpu_percentageIdle FROM cpu

unless you set separate_series = true, then
SELECT value FROM cpu_percentageIdle

It's not a huge deal, I'm just not sure I understand the use-case of continuing to support the latter.

Good points, @sparrc. I, too, don't have much use for the multi-measurement setup. Maybe we should ask on the mailing list?
@pauldix want to weigh in?

@sparrc as long as we can select what's being stored in InfluxDB from the data generated by a plugin, multi-measurement setup is just fine.

I'm fine with storing them all as different fields against a single measurement name. The storage engine that will be released in 0.9.5 won't actually have to read all the fields off disk when querying one specific field so that won't be an issue then. Each field will be stored in its own contiguous block of space.
For the field names, they should have underscore casing, and not include the measurement name as part of it. For example: cpu measurement idle_time as the field.

:+1:, will fix all field names as part of this as well

Awesome to see this is in the works! This will be super useful for us. I'm not sure how far you've gotten on this, but about a month ago I made a similar change to the CPU plugin on a branch of our fork of telegraf. See the last two commits of https://github.com/Asana/telegraf/tree/cpu_percentages.
I added a few methods to the Accumulator to make it easier to send measurements with multiple fields, and then changed the CPU plugin to use those new methods. Feel free to use as much or as little of this as you like!

The branch also removes the cpu "busy" measurement, since when all the other metrics are in the sam measurement the "busy" time can be calculated in an influxdb query

very cool, thanks @jpalay, that will be useful. Currently we're thinking that we'll wait until InfluxDB 0.9.5 to implement this across the board. That is because an influx query currently will get ALL fields within the same measurement, even if you only want one or two of them.

@sparcc Any update as to whether you guys will be implementing this change across the board? I work with @jpalay, and we'd be happy to help change some of the plugins we use to aggregate the metrics if it's something that will be better supported as you suggest will be the case in 0.9.5.

@marcogallotta update is still the same as above, we'll be waiting for the next version of InfluxDB (0.9.5) which is gated on the new storage engine.
The new storage engine will remove query penalties, such as all fields being retrieved from measurements at the same time, there will also be very significant storage compression improvements.
I'm not sure the exact timeframe on that, but I would suspect it's not going to be more than 2 weeks. I will start working on a branch to make that change soon, which I'll make public and builds will be available via CircleCI and from source

How about creating global option separate_series = true (I would call it separate_measurements), to make AddWithFields behave differently?
Then, for example, in net plugin we could use
acc.AddWithFields(
    "", // empty suffix in this case
   map[string]interface{}{
       "bytes_sent": io.BytesSent,
        "bytes_recv": io.BytesRecv,
        "packets_sent": io.PacketsSent,
        "packets_recv": io.PacketsRecv,
        "err_in": io.Errin,
        "err_out": io.Errout,
        "drop_in": io.Dropin,
        "drop_out": io.Dropout,
        },
   tags)

instead of
	acc.Add("bytes_sent", io.BytesSent, tags)
	acc.Add("bytes_recv", io.BytesRecv, tags)
	acc.Add("packets_sent", io.PacketsSent, tags)
	acc.Add("packets_recv", io.PacketsRecv, tags)
	acc.Add("err_in", io.Errin, tags)
	acc.Add("err_out", io.Errout, tags)
	acc.Add("drop_in", io.Dropin, tags)
	acc.Add("drop_out", io.Dropout, tags)

(which is quite repeatable).
This will accomplish three goals:

Let users of older influxdb use telegraf without penalty of storing multiple values in a measurement. Or if they just want multiple measurements.
Let users of influxdb 0.9.5 aggreate values to one measurement
Use the same code in plugins, regardless of influxdb version, as well as unify accumulator interface
Later rename function AddWithFields() to Add() (as the commented in the code)

@ekini I just don't see a strong justification for having separate measurements anymore. It complicates the documentation significantly (see https://github.com/influxdb/telegraf/issues/152#issuecomment-136461809)
There is a reason that Telegraf is still in the 0.1.X phase of releases, so I don't find backwards-compatability enough of a justification at this point.

Hi, any news now that influx 0.9.6 has been released ?

@aderumier the new storage engine is in 0.9.6, although it's not the default. I will be making breaking changes soon to Telegraf and cutting a 0.3.0 branch, I just wanted to first make sure we had all the bugfixes for 0.2.x in before doing that.
0.2.x will continue to be supported for a time

:+1: how soon can we expect a release?

@skynet I'd like to have a "beta" 0.3 version ready by December 20th

@sparrc Great :+1:  Waiting for Christmas :)

I'm a little confused regarding the change in connection with the httpjson and exec plugins. Currently when an endpoint returns value that value is then stored in series like so
exec_prefix-from-telegraf.conf_json-field
httpjson_prefix-from-telegraf.conf_json-field

I wonder what would it look like after the switch? Would it be exec_prefix or exec.prefix (does it make a difference?) or could we finally make that 100% configurable and just state what should be the series name without gluing it together with the plugin name?
My case here is that I use the exec plugin to collect data from a set of sensors. currently what is being pushed to the database is more less like so:
exec_sensors_pressure
exec_sensors_temperature
exec_sensors_humidity

I add there the lat and lon as tags and the name of the location as well. I think it'd be a lot nicer to store it in the database in the series sensors with 3 tags (name, lat, lon) and 3 values (humidity, pressure, temperature). That way querying the data is a breeze and it doesn't occupy as much space as all 3 separate series (if I'm not mistaken).
I think that it would look just like the ability to create external plugins without needing to submit them to the project which is great for closed-source projects.
Do you think that it is something that you could squeeze in into the work that you do on the aggregation?

@padcom This is one of the goals of this change. I agree that there needs to be more measurements that are fields rather than their own measurements.
In 0.3.0 I'm going to be changing the way in which the exec and httpjson plugins are defined in the config file, as well as adding some more plugin options for redefining measurement names, so you'll be able to do something like this:
# exec collector 1
[[plugins.exec]]
  # the command to run
  command = "/usr/bin/collector1"
  name_override = "sensors" # default measurement name would be `exec`

# exec collector 2
[[plugins.exec]]
  # the command to run
  command = "/usr/bin/collector2"
  name_override = "other_things"

As you can see, you won't be defining separate services within the same plugin, each plugin will be a single service in of itself. Secondly, name_override is going to be a new argument available to all plugins that users can use to change a measurement name of a particular plugin. (There will also be name_prefix and name_suffix)
Anyways, I think that covers what you suggested, let me know if there is something I'm missing there from your original question.

That sounds PERFECT! Can't wait to get it implemented in my setup :) Thanks for all your hard work. It's much appreciated!

Just one comment: since you pointed out that all plugins will benefit from the name_override option it seems that monitoring multiple Java services with JMX and Jolokia will finally make sense :) That will be awesome!

FYI: a beta build of 0.3.0 is now available, see here: https://github.com/influxdb/telegraf#version-030-beta
The README on the 0.3.0 branch may also be helpful, as well as the configuration guide.

I have tried the exec and httpjson plugins. Both, the command and an HTTP service return the same data:
exec
{ "pressure": 99271, "temperature": 26.8 }

httpjspn
* Rebuilt URL to: http://home.aplaline.com:32768/
* Hostname was NOT found in DNS cache
*   Trying <IP_ADDRESS>...
* Connected to home.aplaline.com (<IP_ADDRESS>) port 32768 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.35.0
> Host: home.aplaline.com:32768
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Content-Type: application/json
<
{ "pressure": 99264, "temperature": 26.9 }
* Closing connection 0

The exec plugin performs as advertised resulting in a series sensors with a tag host and 2 values for pressure and temperature. However the httpjson plugin returns with the following exception:
$ ./telegraf -config /etc/opt/telegraf/telegraf.conf -test
* Plugin: httpjson, Collection 1
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x5691f8]

goroutine 36 [running]:
github.com/influxdb/telegraf/plugins/httpjson.(*HttpJson).sendRequest(0xc820181b20, 0xc82017ee01, 0x15, 0x0, 0x0, 0x0, 0x0)
	/home/telebuild/go/src/github.com/influxdb/telegraf/plugins/httpjson/httpjson.go:185 +0xd28
github.com/influxdb/telegraf/plugins/httpjson.(*HttpJson).gatherServer(0xc820181b20, 0x7f917edc26b0, 0xc82026e2c0, 0xc82017ee01, 0x15, 0x0, 0x0)
	/home/telebuild/go/src/github.com/influxdb/telegraf/plugins/httpjson/httpjson.go:122 +0x71
github.com/influxdb/telegraf/plugins/httpjson.(*HttpJson).Gather.func1(0xc820274a20, 0xc820181b20, 0x7f917edc26b0, 0xc82026e2c0, 0xc820190300, 0xc82017ee01, 0x15)
	/home/telebuild/go/src/github.com/influxdb/telegraf/plugins/httpjson/httpjson.go:89 +0x7e
created by github.com/influxdb/telegraf/plugins/httpjson.(*HttpJson).Gather
	/home/telebuild/go/src/github.com/influxdb/telegraf/plugins/httpjson/httpjson.go:92 +0x186

goroutine 1 [runnable]:
sync.runtime_Semacquire(0xc820274a2c)
	/usr/local/go/src/runtime/sema.go:43 +0x26
sync.(*WaitGroup).Wait(0xc820274a20)
	/usr/local/go/src/sync/waitgroup.go:126 +0xb4
github.com/influxdb/telegraf/plugins/httpjson.(*HttpJson).Gather(0xc820181b20, 0x7f917edc26b0, 0xc82026e2c0, 0x0, 0x0)
	/home/telebuild/go/src/github.com/influxdb/telegraf/plugins/httpjson/httpjson.go:95 +0x1b3
github.com/influxdb/telegraf.(*Agent).Test(0xc8201780f8, 0x0, 0x0)
	/home/telebuild/go/src/github.com/influxdb/telegraf/agent.go:197 +0x49e
main.main()
	/home/telebuild/go/src/github.com/influxdb/telegraf/cmd/telegraf/telegraf.go:115 +0xe3c

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1696 +0x1

goroutine 20 [syscall]:
os/signal.loop()
	/usr/local/go/src/os/signal/signal_unix.go:22 +0x18
created by os/signal.init.1
	/usr/local/go/src/os/signal/signal_unix.go:28 +0x37

goroutine 35 [runnable]:
github.com/influxdb/telegraf.(*Agent).Test.func1(0xc8201902a0, 0xc820190240)
	/home/telebuild/go/src/github.com/influxdb/telegraf/agent.go:176
created by github.com/influxdb/telegraf.(*Agent).Test
	/home/telebuild/go/src/github.com/influxdb/telegraf/agent.go:185 +0xd6

The service http://home.aplaline.com:32768 is public facing - feel free to use it

Apart from the above I have tested the Apache plugin and the Docker plugin. They work like a charm!

Thanks for the report @padcom, I'll look into that

@padcom this has been fixed, you can now download 0.3.0-beta2 from the README.
Thanks again for the report!

Installed the latest, tested both (exec and httpjson) - all OK. Thank you!!

I have noticed a memory use reduction by about 400MB. Might not be related (changed from exec to httpjson plugin but also did more changes in the mean time) but it always is nice to see gauges go down :)

closed by 0.10.0


Configure Renovate

Welcome to Renovate! This is an onboarding PR to help you understand and configure settings before regular Pull Requests begin.
🚦 To activate Renovate, merge this Pull Request. To disable Renovate, simply close this Pull Request unmerged.

Detected Package Files

.github/workflows/build.yml (github-actions)
.github/workflows/release.yml (github-actions)
package.json (npm)

What to Expect
With your current configuration, Renovate will create 6 Pull Requests:

Update dependency chai to v4.3.6

Schedule: ["at any time"]
Branch name: renovate/chai-4.x
Merge into: master
Upgrade chai to 4.3.6

Update actions/setup-node action to v2.5.1

Schedule: ["at any time"]
Branch name: renovate/actions-setup-node-2.x
Merge into: master
Upgrade actions/setup-node to v2.5.1

Update dependency mocha to v9.2.2

Schedule: ["at any time"]
Branch name: renovate/mocha-9.x
Merge into: master
Upgrade mocha to 9.2.2

Update dependency rollup to v2.70.0

Schedule: ["at any time"]
Branch name: renovate/rollup-2.x
Merge into: master
Upgrade rollup to 2.70.0

Update actions/checkout action to v3

Schedule: ["at any time"]
Branch name: renovate/actions-checkout-3.x
Merge into: master
Upgrade actions/checkout to v3

Update actions/setup-node action

Schedule: ["at any time"]
Branch name: renovate/actions-setup-node-3.x
Merge into: master
Upgrade actions/setup-node to v3.0.0
Upgrade actions/setup-node to v3

❓ Got questions? Check out Renovate's Docs, particularly the Getting Started section.
If you need any further assistance then you can also request help here.

This PR has been generated by Renovate Bot.

Renovate is disabled
Renovate is disabled due to lack of config. If you wish to reenable it, you can either (a) commit a config file to your base branch, or (b) rename this closed PR to trigger a replacement onboarding PR.


Please invite me to the GitHub Community Organization

Name
Mohamed Abdullahi Hassan
Discord Username (if applicable)
zayidmohamed
Additional Context
No response

Welcome to ChryzHub @zayidmohamedy 🚀🥳


Allow interceptors to yield and update request arguments

This change allows Ruby interceptors to modify request values. (Response values are currently passed through the interceptor, and we have no issues modifying those values.) This was encountered while working on supporting OpenCensus in gRPC requests/responses. Specifically, streaming requests/responses are passed as Enumerable values. The approach we would like to take is to wrap the Enumerable with a Lazy Eumerable that will log when a request or response passes through the gRPC client. However, the current implementation does not allow the request Enumerable to be modified.
This change does not pass all the tests. There are some tests that specify that the request is opened before the values are passed through the interceptors. I don't know how to keep this behavior while still allowing interceptors to wrap the request Enumerable. Therefore I am opening this PR to start a discussion on how to move forward.

@apolcyn Have you had a chance to look at this?

sorry @blowmage this and https://github.com/grpc/grpc/pull/17650 slipped past me. Taking a look

@blowmage I should add, can we please add a test here? A test will help my understanding of this change for review. Regarding your comment, if we can find a backwards compatible way to make this change, then it should be ok; if it's breaking, we can evaluate. However, if this becomes a significant API addition or a breaking change, we'll need to at least at some point have a gRFC for too.

Yeah, I'm still trying to get the grpc ruby code to build and pass cleanly on OS X. I may have to bail on OS X and move this to a Linux VM.
Which Kokoro build includes the Ruby tests?

We have mac and linux Kokoro builds for automated CI:
see https://github.com/grpc/grpc/blob/master/tools/internal_ci/linux/grpc_basictests_multilang.cfg
and https://github.com/grpc/grpc/blob/master/tools/internal_ci/macos/grpc_basictests_objc_dbg.cfg and https://github.com/grpc/grpc/blob/master/tools/internal_ci/macos/grpc_basictests_objc_opt.cfg

I see ruby test output in the "Basic Tests Multi-language Linux (internal CI)" build, but I don't see the ruby test output in any of the builds for MacOS or Windows.


chore(#72): Theme Lint and Detekt

chore(#72): Theme Lint and Detekt

Code Coverage

Total Project Coverage
100.00%
:white_check_mark:


Fix spelling errors in interning module

@bors: r+

:pushpin: Commit c036952 has been approved by alexcrichton

:hourglass: Testing commit c036952f28b0e7d01eacaf5970de5a1e7c290e22 with merge ad7d177adeb358ff0a93c00dfdbb67d71b0431e1...

:sunny: Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing ad7d177adeb358ff0a93c00dfdbb67d71b0431e1 to master...


fix authenticate bug for INSECURE servers

Prefect-email is not supporting authentication on INSECURE mail servers. This PR will add that feature.
Closes
80
Checklist

[x] References any related issue by including "Closes #" or "Closes ".

If no issue exists and your change is not a small fix, please create an issue first.

[ ] Includes tests or only affects documentation.
[x] Passes pre-commit checks.

Run pre-commit install && pre-commit run --all locally for formatting and linting.

[ ] Includes screenshots of documentation updates.

Run mkdocs serve view documentation locally.

Thank you for your willingness to contribute to prefect-email! The code for this library has been moved to https://github.com/PrefectHQ/prefect/tree/main/src/integrations/prefect-email. Please reopen this PR there if this functionality is still needed!


Dark Theme for App

There should be an option to toggle the app to use
a) Light Theme
b) Dark Theme
c) System Default
The CSS classes should be adjusted accordingly

fulfilled by PR


v0.14.x: CoreDNS prometheus metric annotations exposed at pod level

These annotations would previously never be rendered because they
were added under the kube-dns section (rather than CoreDNS's).
Additionally, the annotations are now added to the Pods themselves
rather than the Deployment.
Fixes #1768

Codecov Report

Merging #1771 into v0.14.x will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           v0.14.x    #1771   +/-   ##
========================================
  Coverage    24.93%   24.93%
========================================
  Files           98       98
  Lines         5078     5078
========================================
  Hits          1266     1266
  Misses        3673     3673
  Partials       139      139

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 fd0bdbe...917d490. Read the comment docs.

/lgtm


[Feature] 希望可以支持内阴影

What problem does this feature solve?
饼图，柱状图等都支持内阴影
What does the proposed API look like?
inset

canvas 目前没有特别方便的方式支持内阴影


Update README.md heading markdown

:+1:
reference:
https://github.github.com/gfm/

The 3.05 README.md also 'suffer' from this wrong syntax.

Done

Another link:
https://githubengineering.com/a-formal-spec-for-github-markdown/


2023-3.2: pin sqlalchemy to >=2.0.20

Per report in NSLS2 Slack.
Closes #21

I added one commit to match the version of pdfstream ==0.5.2 used in the 2022-2.0-py37 conda environment (see  https://zenodo.org/records/6462525/files/2022-2.0-py37.yml for details). I'll merge the PR once the CI passes.
The edrixs exclusion was due to some conflicts with numexpr (cc @mpmdean) - we'll have to rebuild the new, cmake-based version in conda-forge, and then we'll add it back, hopefully, the conflicts will be resolved.

Thanks for the note @mrakitin
What do you think about making a new release out of the current edrixs code? And leaving creating a pyproject.toml for later?

@mpmdean, let's chat later this week to plan the release.


Expression package refactoring

A lot of code has changed, but most of it is cleaning up things.
The main real changes are in variable expressions, in the use of functions from the environment and the addition of 'Holes' for open inputs.

Other than the noted nitpicks, this looks great :+1:

The caching logic has moved to a central place.
I renamed getType to findType because it's not a simple getter.
Some of the early tests use hacky ways to do things, I would prefer refactoring these tests over adding special testing classes.
And the rest are trivial oversights on my part.


20221005 BeamSolver retains global state

beam_solver_test.py doesn't pass, because there's global state held in BeamSolver.  The individual cases pass, but something in the library holds state that it shouldn't.

run as separate tests.

This is a different bug.

Fix 36e11c83875140d453083126a193e06a7c656c96

This is really still a problem if you are using BeamSolver more than once in a program. Generally not what we do in the agent, but still is a bug.

This is consistent with my experience from using Hellweg as compiled for windows. You don't execute the solver more than once -- you have to exit the application and restart.

Closing here. I'll create a separate issue to address this bug in the future.


Further KU/EKU fixes.

Related to #2459.
The matching KUs for EKU "TLS Web Server Authentication" are Digital Signature AND (Key Encipherment OR Key Agreement). Added for compatibility with externally-generated certificates.
Removed the nsComment extension from all cert profiles. It's deprecated like nsCertType is, though nsCertType was retained in the server profile for backwards compatibility with ancient OpenVPN clients using the ns-cert-type configuration parameter.
Tested by porting modified code to a running OPNsense firewall and generating a bunch of certificates, all of which function properly.

I had originally intended to remove the nsCertType extension in server cert generation, but I decided that leaving it there for now didn't cause any problems. It's worth noting that OpenSSL 1.1 and later do away with nsCertType and nsComment entirely (they show up as unknown extensions), so it may in fact be worth removing completely. Thoughts?

Can you split this into two separate requests? opnsense.cnf should be modified in one go later on.
You can also read about style at https://www.php-fig.org/psr/psr-2/

Closing to split.

Rolled back the opnsense.cnf change.

Merged, thanks!


Update for py37

Small changes to dependencies to update for Python 3.7. PyYAML specifically doesn't compile under 3.7, although it does in 3.6. I think ultimately we should add e.g. tox.ini and do multi-version testing, but for now this unblocks me. :-)

LGTM


Correction

Under step 4 of enabling with GPO , Shouldn't the sentence read:
Enabled with UEFI lock to ensure HVCI cannot be DISABLED remotely.....

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

ID: 1526c4cb-4584-7fc6-e633-a48e13dad7e8
Version Independent ID: 13a88ed8-f43d-f658-cbe4-d148d5ffaa12
Content: Enable virtualization-based protection of code integrity
Content Source: windows/security/threat-protection/windows-defender-exploit-guard/enable-virtualization-based-protection-of-code-integrity.md
Product: w10
GitHub Login: @brianlic-msft
Microsoft Alias: justinha

@danjpadgett Thanks for the correction, it's fixed now.


Update Pydantic models

Need to update the pydantic models to match the recent changes to data catalog schema specification requirements..

This has been implemented.


Feature Request: Turn OFF WiFi&Cell Data in iOS App Preferences

The FMA100 USB device and app are very useful for bridging data over bluetooth between a fully-connected iOS device and a semi-isolated Linux/Windows computer. In that context security is critical. Unlike Android, iOS doesn't allow WiFi data to be turned-off on a per application basis at the OS layer (that feature is only available on iPhones sold in China: screenshot). So it'd be great if you added the option to turn off all internet connectivity in the app preference pane similar to example linked above. The feature would add assurance that the data being bridged over Bluetooth is staying local only and not leaking to 3rd party servers.

The iOS app "FlooPaste" doesn't have a setting to turn off Wifi access only because it won't/cannot access the networks for privacy concerns. iOS doesn't bother to show such an option to switch on/off a feature that doesn't exist for the App. So it's guaranteed that data being shared via the App is staying local only and not leaking to 3rd party servers.

Thank you for correcting my misunderstanding on this. I've tested more carefully with a few apps and see that the setting options grow as apps ask for more permissions. This feature request was a mistake! Appreciate it.


Deprecate config.utils

Deprecate functions from config.utils and use dictionary and vocabulary modules directly.

Partially solves #284 .


enforce immutability on data doc type

This could be done by dissalowing it in upsert and only allowing it in update

please see 3d0da77
for one strategy on how to do this


Update 2FA test and remove unused package from repo

Found in the frontend tests that I can just use speakeasy rather than otpauth for the tests, which is the only reason it was installed. So have updated the tests here and removed the package.

@znarf Ok to merge?


Add user search to checkout/checkin confirmation page [v5.5]

From BMEC:

I’m entering all the reservation transactions we had today, and I discovered that the “Find User” box isn’t available on the “Check-Out/In Receipt for ___” page. Once I’ve checked out/in a patron, I was usually able to immediately search for another user. Now I have to navigate back to the Catalog in order to use the Find User function. This is a minor inconvenience, but it would be nice for that function to be restored.

This was removed in #776, it should be a pretty straightforward tweak.

On second thought, this is a bit tricky since those views no longer have a sidebar to include this box on... @AlanLiu96, can you take this and brainstorm a clean way to add this box to all views (for checkout persons and above) without the cart? Thanks!

Sure, I'll take a look at it tonight!
On Jan 19, 2016 2:24 PM, "Oren Kanner"<EMAIL_ADDRESS>wrote:

Assigned #1420
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_YaleSTC_reservations_issues_1420&d=AwMCaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=fGUlyXMXUllcq1Lzipj1Qfu_NL-lk9lC6GgNV_p2VOg&m=fSe1kLw6d0sTPCARJS1TdK1JnxPKIL4dghW_C43FJgc&s=fdC1YipCJAiE2r5pgt-c4p_9D1Z-CaXu8Qja-LEIB_A&e=
to @AlanLiu96
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_AlanLiu96&d=AwMCaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=fGUlyXMXUllcq1Lzipj1Qfu_NL-lk9lC6GgNV_p2VOg&m=fSe1kLw6d0sTPCARJS1TdK1JnxPKIL4dghW_C43FJgc&s=kPISGN0nWFHE_83vfAp3Fj-9kiECQ44mXllMZI_7Lsk&e=
.
—
Reply to this email directly or view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_YaleSTC_reservations_issues_1420-23event-2D519501806&d=AwMCaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=fGUlyXMXUllcq1Lzipj1Qfu_NL-lk9lC6GgNV_p2VOg&m=fSe1kLw6d0sTPCARJS1TdK1JnxPKIL4dghW_C43FJgc&s=45xCFnM8A85cMZeXx8GnFFmmLFy1icvASIqOqabA-48&e=
.

Ok, just for the records, this is what the current page looks like now.

One way to solve this issue would be to reintroduce the box separately as a different partial using the code from the sidebar.
Pros: reusing code, satisfies client's requests
Cons: It adds a bit of clutter both visually and code wise as the page is setup without a sidebar right now
Another way, which I personally like better, but I'm not 100% sure how to implement is to reuse the catalog search box. If there are no results for equipment models, perhaps we could also search for users and redirect the search to the users's page using that search box.
Pros: Extending functionality of existing code, potentially useful for other cases?, no need for extra UI elements
Cons: a bit more complicated logic in the search, potentially (trivially?) increasing time to process searches

Hmm I hear what you're saying about option 2; one thing to note is that the search box is in the navbar partial which is shared across all the views, so we'd have to add more logic to choose which search box to add. Also, it might confuse users who (rightly) would expect that UI element to perform a single task, regardless of the view.
This view is completely empty on the right side (since it was originally designed to include the entire sidebar), so why don't we just re-add the top part of the sidebar for the moment and we can (eventually) try to overhaul the UI in #1042? What do you think?

Oh I meant that the UI element would stay the same, the search logic would just include both users as well as items so like a universal search across all views similar to how github does its searching. I do agree though that this would require a larger overhaul over the UI, so for now, its probably better just to put the user search back where it was previously

Oh that makes much more sense to me, sorry for misunderstanding. That's definitely a larger-scope item, but I'll add an issue for it if we don't have one already.

so I played with the divs a bit and I just put the search box back in. I figured that since the only people that would access that page are the ones that can checkout/checkin, it would be fine to just include the box back in at the side

Should I make one for master and one for release 5.5 as well?


Remove overly tight spec from client cert; cut commercial CAs some slack

Closes issue #20 and #21

Replaced by #23


(refactor) Move out metadata and hint provider impls to 'streamline-cluster' module

They're not used from 'streamline-catalog' and actually not related to.
I'm planning to work on STREAMLINE-545 on top of this branch, but if someone would like to keep as it is, we can discuss and STREAMLINE-545 may be rebased.

@HeartSaVioR can you upmerge .

@harshach
#504 contains this. Could we close this, or do you want to apply this PR before applying #504?


[GR Phase 2] Step 5 Director information screen (without API calls) - implementation

Details

This PR contains implementation of step 5 (Director information screen) - GR phase 2.
Design doc section: https://docs.google.com/document/d/1Y4P7G9h0Easjcea7wyk52gKrNB9o1yTjpmJFYkrHDW4/edit?tab=t.0#bookmark=id.damtu6jbu35v
Fixed Issues

$ https://github.com/Expensify/App/issues/50901
PROPOSAL: n/a
Tests

Log in to the app
Open Workspace with Workflows feature enabled
Tap on "Connect bank account" inside the "Make or track payments" section
Go to the 5th step of the flow
Test the flow

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

Offline tests

Same as above.
QA Steps

Same as above.

[x] 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/user-attachments/assets/65d9010b-8dc7-4b19-8475-d47d16c01985

Android: mWeb Chrome
https://github.com/user-attachments/assets/69f28901-1988-4339-8e07-786fdf956617

iOS: Native
https://github.com/user-attachments/assets/e39dc2df-d2a1-44d7-a4da-3c395d808e37

iOS: mWeb Safari
https://github.com/user-attachments/assets/f181922e-4206-440e-bab7-b38c0b42cc51

MacOS: Chrome / Safari
https://github.com/user-attachments/assets/de4e379f-40a1-4888-a870-ae15e0e781d1

MacOS: Desktop
https://github.com/user-attachments/assets/00d3e745-1397-4f36-b0d2-a6c0ff154271

I wasn't super involved with this, so we should probably wait for the other members of @Expensify/design to weigh in here, but generally this looks pretty good. A few questions/comments:

What size are the radio check circles? They look a little small to me? In Figma they're 28x28px
Seems like there's some weirdness going on with the attachment selector on iOS—any idea what's going on there?
The attachment preview looks pretty borked when the file name is really long (icon gets pushed out of the container, the file name doesn't truncate, etc)

Is that something we need to handle here or is that being dealt with elsewhere?

I think all the single input screens (legal name, job title) need to autofocus the input when you get to them (for the first time or any subsequent time)—that's how we typically handle inputs like that

Feeling good! I have the same feedback as Danny above regarding the checkbox size.
Then for this screen, the blue link looks like it's not left-aligned the same way the others are:

Then for this screen, it feels like the input could be a bit closer to the headline?

Then for this screen, it feels like the input could be a bit closer to the headline?

This goes for the legal name too

@burczu would you mind addressing these advices from design team above? ty

@hungvu193 yes, on it!

Error message is to close to the Upload file component.

Infinite loop when pressing back between LegalName and Email page.
https://github.com/user-attachments/assets/e395993e-2b70-4cee-a108-5d6c3336d77b

On Native platform, the attachment icon is out of the border.

@burczu  Little bump for these comments above 👀

Error message is too close to the Upload file component.

fixed

Infinite loop when pressing back between LegalName and Email page.

fixed

On Native platform, the attachment icon is out of the border.

fixed

Nice. I'll verify it shortly

@burczu Can you also update the screenshots/videos so Design team can review the UI?

@burczu Can you also update the screenshots/videos so Design team can review the UI?

I will, but still I have few things here to address, so I'll do it once its all done. I think you can wait till then with verification - I'll post a separate comment that's it ready to re-review.

@burczu Can you also update the screenshots/videos so Design team can review the UI?

I will, but still I have few things here to address, so I'll do it once its all done. I think you can wait till then with verification - I'll post a separate comment that's it ready to re-review.

Cool. Let me know when it's ready for another review. Ty

@dannymcclain Answering your comments:

I wasn't super involved with this, so we should probably wait for the other members of @Expensify/design to weigh in here, but generally this looks pretty good. A few questions/comments:

What size are the radio check circles? They look a little small to me? In Figma they're 28x28px

Good point - fixed.

Seems like there's some weirdness going on with the attachment selector on iOS—any idea what's going on there?

I think this is because of the simulator, I believe this will work correctly on real device.

The attachment preview looks pretty borked when the file name is really long (icon gets pushed out of the container, the file name doesn't truncate, etc)

Is that something we need to handle here or is that being dealt with elsewhere?

This is related to what @hungvu193 pointed out here too - fixed.

I think all the single input screens (legal name, job title) need to autofocus the input when you get to them (for the first time or any subsequent time)—that's how we typically handle inputs like that

Added autofocus to sile input screens.

@shawnborton Answering your comments:

Feeling good! I have the same feedback as Danny above regarding the checkbox size.
Then for this screen, the blue link looks like it's not left-aligned the same way the others are:

Good point. Fixed.

Then for this screen, it feels like the input could be a bit closer to the headline?

Yes. Fixed

@hungvu193 I think I've addressed all the comments - you can now re-review the PR. Videos also are updated now.

Reviewer Checklist

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

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] 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)
[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 checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

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

[x] 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
[x] I verified proper code patterns were followed (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] 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 verified that this PR follows the guidelines as stated in the Review Guidelines
[x] 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)
[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] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] 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)
[x] 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)
[x] All JSX used for rendering exists in the render method
[x] 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

[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.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

https://github.com/user-attachments/assets/b235b38b-56d0-47f6-a823-da98ce17a2f9

Android: mWeb Chrome

https://github.com/user-attachments/assets/a828bd0f-5926-4c68-bdcf-6b325d7ecdc5

iOS: Native

https://github.com/user-attachments/assets/5805ff5c-e795-4a4f-bd27-6e52579c793d

iOS: mWeb Safari

https://github.com/user-attachments/assets/b9f803c4-e7f4-4721-aec5-2e6e270625ab

MacOS: Chrome / Safari

https://github.com/user-attachments/assets/dabf071e-70fb-4ede-9ae9-ca414dfde927

MacOS: Desktop

https://github.com/user-attachments/assets/c5ba5b58-ba6e-4368-a465-fd3f36b9e920

@burczu  LGTM. I think we only have translations left

@hungvu193 asked for confirmation on translations here: https://callstack-hq.slack.com/archives/C01GTK53T8Q/p1731572554005439

@hungvu193 spanish translations reviewed and updated

@burczu @hungvu193 @madmax330, can someone test if this works as intended. QA mentioned there are unable to see director information screen - Issue
I'm going to check this off the QA checklist to not block deploy because it looks like worst case the screen doesn't show up which is the same as production.

@burczu @hungvu193 @madmax330, can someone test if this works as intended on staging. QA mentioned they are unable to see director information screen - Issue
I'm going to check this off the QA checklist to not block deploy because it looks like worst case the screen doesn't show up which is the same as production.

Sorry for this inconvenience. We have a plan to support this feature in Debug mode. However, we missed that case when we implemented it on https://github.com/Expensify/App/pull/51667.
So we decided to implement it in our next PR (which is in progress here).
So I can say https://github.com/Expensify/App/issues/52631 will be fixed once https://github.com/Expensify/App/pull/52384 is merged.


externalize traefik container and config management

Issue
The traefik's charm code is somewhat outdated and needed some freshening up.
Adopting some more modern charming patterns is the start of that process.
Solution
In this PR we add a Traefik class that takes care of all pebble interactions and all traefik-workload-specific configuration tasks.
This way the charm can be unaware of:

the yaml config file structure traefik wants
the locations at which the traefik files need to be
how to manage the traefik process (start it, restart it...)

The charm remains responsible for:

juju event handling
status management
relation interface bookkeeping

Context

A next PR will add a manifest-driven filesystem manager, to prevent unnecessary pushes/restarts unless the backing juju state 'really' has changed.
Testing Instructions

We're going to need careful testing especially in combination with the TLS bundle to catch regressions.
Release Notes

Two yamls for the same app, one with http (relation was previously removed), one with https:
juju run external-ca/0 get-ca-certificate --format json | jq -r '."external-ca/0".results."ca-certificate"' > external.cert

$ curl --cacert external.cert https://<IP_ADDRESS>/pt-prom-0/-/ready
Client sent an HTTP request to an HTTPS server.

$ jsshc traefik trfk/0 ls /opt/traefik/juju
certificates.yaml			  server.cert
juju_ingress_ingress-per-unit_2_prom.yaml  server.key
juju_ingress_ingress-per-unit_3_prom.yaml  # <--- TWO YAMLS FOR THE SAME APP

Bundle:
bundle: kubernetes
applications:
  ca:
    charm: self-signed-certificates
    channel: edge
    revision: 40
    scale: 1
    constraints: arch=amd64
  external-ca:
    charm: self-signed-certificates
    channel: edge
    revision: 40
    scale: 1
    constraints: arch=amd64
  prom:
    charm: prometheus-k8s
    channel: edge
    revision: 152
    series: focal
    resources:
      prometheus-image: 130
    scale: 1
    constraints: arch=amd64
    storage:
      database: kubernetes,1,1024M
    trust: true
  trfk:
    charm: local:traefik-k8s-0
    series: focal
    scale: 1
    constraints: arch=amd64
    storage:
      configurations: kubernetes,1,1024M
    trust: true
relations:
- - prom:ingress
  - trfk:ingress-per-unit
- - trfk:certificates
  - external-ca:certificates
- - prom:certificates
  - ca:certificates

The bug you found is real, but I don't think that's a regression. I've seen that in the past. I think it's because the ipa requirer misses an observer for relation-departed. Adding that to the mix, and let's see if we can make this pass

I think it's because the ipa requirer misses an observer for relation-departed.

I think that in this context, a bug in the requirer side of things shouldn't matter to the provider side: the provider gets a relation event from juju that should have resulted in deleting the stale file. I'm guessing it's 888's fault.


Fix leak of normalized value in early return

This leak can be reproduced with:
    libpostal_address_parser_options_t options = { .country = "US", .language = "en"};
    libpostal_address_parser_response_t *parsed = libpostal_parse_address("foo", options);
    libpostal_address_parser_response_destroy(parsed);

The normalized value was not freed before an early return.
Here was the relevant output from Valgrind before the fix:
==17267== 4 bytes in 1 blocks are definitely lost in loss record 1 of 279
==17267==    at 0x4C31D2F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17267==    by 0x146897: utf8proc_map (utf8proc.c:608)
==17267==    by 0x146B3D: normalize_string_utf8_languages (normalize.c:69)
==17267==    by 0x146D4C: normalize_string_latin_languages (normalize.c:128)
==17267==    by 0x14FD8A: address_parser_normalize_string (address_parser.c:355)
==17267==    by 0x14FD8A: address_parser_parse (address_parser.c:1665)
==17267==    by 0x132BB5: libpostal_parse_address (libpostal.c:1065)

Good catch, thanks!


[FEATURE] Implement egui-dock

Problem
We need to implement egui-dock for the Editor, without it we can't start developing the required tools.

I actually gor it working, didn't document the process because it was too easy to bother writting something about it, but I don't really remember how I did it. But it is possible, and not hard, with a little effort we can do a good implementation for this one.


Fix issue with inserting documents in Milvus with autoId enabled

Summary:

Fixed issue with inserting into Milvus with autoId enabled
When autoId is enabled, the insert method is used
When autoId is not enabled, the upsert method is used
Added test from issue

Fixes #5813

Makes sense, thank you!


Significant Build Size Increase with @nuxt/icon and Deprecation Warnings from @iconify

After integrating @nuxt/icon into my project, I noticed a significant increase in the build size from approximately 2MB to 14MB. This issue persists even though I am not using any <Icon /> elements in my components. Additionally, I am encountering numerous deprecation warnings related to @iconify.
It appears that @nuxt/icon is downloading all icon collections instead of only the icons being used, leading to the substantial increase in build size.

Before adding @nuxt/icon

After adding @nuxt/icon, @iconify-json/heroicons and @iconify-json/tabler

The build size should not increase significantly, especially when no <Icon /> elements are used.
If relevant, here are the versions I am using:
Nuxt Version: 3.12.3
@nuxt/icon Version: ^1.0.0
@iconify-json/heroicons: ^1.1.21
@iconify-json/tabler: ^1.1.116
Node.js Version: v20.13.1

A ton of deprecation warnings like these
(node:23176) [DEP0166] DeprecationWarning: Use of deprecated double slash resolving ".//index.cjs" for module request ".//index.cjs" matched to "./*" in the "exports" field module resolution of the package at<EMAIL_ADDRESS>imported from ...\node_modules\nuxt-og-image\dist\node_modules\_index.js.
Thank you in advance for your help in fixing this issue! :)

Related #184.

Try setting serverBundle: false in the configuration. This will prevent loading the collections used by nuxt-dev-kit.


Portability fix. Change #include order

This file doesn't compile on FreeBSD nor OS X because icmp6.h needs definitions from sys/types.h.
On Linux icmp6.h includes sys/types.h itself but it's not a good idea to assume that everyone does. Besides, I think it's much more clear to put it before the netinet stuff so that more "fundamental" definitions are included first.

Ugh, another place that FreeBSD makes builds gratuitously fail.
Thanks, I applied this to master.


[Backend System] Shared Environment Definitions

Discussion
We likely want the ability to define some form of common backend environments in the form of an internal package used to configure a common baseline for all Backstage services deployed within an organization. This could carry things like service implementations and default options. i.e. @internal/backend-common
Context
#13082

Should this get closed by #15743?

Yep!


Model.find and Model.fetch with done & fail options

Maybe there is a better way of handling my case, but I'm finding myself wanting to be able to use the done and fail options with fetch and/or find on a model like I can on save.
e.g.
MyModel.fetch({
    id: 1234
}, {
    done: function() { alert('done'); },
    fail: function() { alert('fail'); }
});

Right now if a fetch fails I need to listen for the ajaxError event and handle it there. But this gets messy b/c in another part of my code I need to handle the case when an instance of a model is destroyed, trying to use the fail option to catch the error, but it's hitting my ajaxError handler first.
How would you feel about adding support for done and fail options to find and/or fetch or is there something I'm missing here?

I really like returning a promise so that chaining can be used.  Example:
model.fetch().done(-> console.log(arguments)).fail(-> console.error(arguments))

jQuery.Deferred pattern seems like the most standard option for client-side promises, IMO.

@thesmart there's been a bunch of discussion about promises over in #532. I don't think we want to use jQuery.Deferred because that API isn't compatible with native ES6 promises that are going to become the standard.
Really looking forward to having promise support in Spine though!

what about using the new fetch apis that browsers are starting to implement?


Nuxt generate programmatic usage

What problem does this feature solve?
I need nuxt.generate method simillar to nuxt.build, so I could start generator programmatically in cloud function with no-build option.
I doing this not for a specific project, but to make PoC of fully generated nuxt site with lots of dymanic routes that are regenerated when API data is changed.
Ideally it would be awesome to have an ability to choose what routes should be regenerated, but a simple method is fine by now.

This feature request is available on Nuxt community (#c7627)

hory shet. Thank you so much!
I've been looking for this method in /dist/nuxt-start but should have loooking in /dist/nuxt
init: false - found out that if it's false, there will be only html files in dist, and when it's true, there will be _nuxt dir and static files as well
And I found two buggs, but I don't whant to make an issue, release is comming =), Maybe later

With --no-build option (via nuxt generate or nuxt.generate()), only paths declared in nuxt.config.js are generated.
With nuxt.generate method, it only works if dist dir is clean. If I generated dist and trying to generate second time, it removes dist dir but crashes with Error: EPERM: operation not permitted. I'm not sure, maybe it somehow related with my enviroment...

You mean it doesn't generate static .vue files' paths?
That's just how it is sometimes in life. Maybe make a minimum repro gist and I'll poke it with a stick.

windows 10 but it occured on production ubuntu server
I see. Well, I can live without that...

in case someont interested, here is a code for google cloud function nuxt generator
`
let { Nuxt, Generator } = require('nuxt-edge/dist/nuxt')
let storage = require('@google-cloud/storage')()
let walker = require('klaw-sync')
const bucketName = 'site bucket' //change it
const dir = '/tmp/dist'
let config = require('./nuxt.config.js')
config.generate.dir = dir
let nuxt = new Nuxt(config)
let generator = new Generator(nuxt)
exports.generate = async function(req, res){
if(req.method !== 'POST') throw new Error('wrong method')
await generator.generate({build: false, init: true})

let files = walker(dir, {nodir: true})

await Promise.all(files.map(
file => storage
.bucket(bucketName)
.upload(file.path, {
destination: file.path.split(dir).pop()
})
.then(console.log(file.path))
))
res.status(201).send('generated')
}
`

How is that .then(console.log(file.path))? Shouldn't that have at least a ()=>?

@DreaMinder besides that, never leave performance on the table, or the communists win.
Premature optimisation is the only way!
const { Nuxt, Generator } = require('nuxt-edge/dist/nuxt')
const storage = require('@google-cloud/storage')()
const { resolve } = require('path')
const walk = require('klaw')

const bucketName = 'site bucket' //change it
const dir = resolve('/tmp/dist')
const dirLen = dir.length

const config = require('./nuxt.config.js')
config.generate.dir = dir

const nuxt = new Nuxt(config)
const generator = new Generator(nuxt)

exports.generate = async function(req, res) {
  if (req.method !== 'POST') throw new Error('wrong method')

  await generator.generate({ build: false, init: true })

  await new Promise((resolve, reject) => {
    const promises = []
    const bucket = storage.bucket(bucketName)

    walk(dir, { nodir: true })
      .on('data', file => {
        const newPromise = bucket.upload(file.path, {
          gzip: true,
          destination: file.path.slice(dirLen)
        })
        promises.push(newPromise)
        newPromise.then(() => console.log(file.path), reject)
      })
      .on('end', () => {
        resolve(Promise.all(promises))
      })
      .on('error', reject)
  })

  res.status(201).send('generated')
}

Shouldn't that have at least a ()=>?
actually no

Premature optimisation is the only way!
Nice try =). It would be an optimization if /tmp dir was on physical HDD drive. But its in-memory dir, it has zero cost of reading, especially comparring to generator delay.
If generator had .on('data' method, it would be really usefull that way.

@DreaMinder how does .then(console.log(file.path)) work?
console.log() returns undefined, not a function?
Are you using it in the sense of
  await Promise.all(files.map(
    file => (
      console.log(file.path),
      storage
        .bucket(bucketName)
        .upload(file.path, {
          destination: file.path.split(dir).pop()
        })
      )
  ))

aka in the sense of
  await Promise.all(files.map(
    file => {
      console.log(file.path)
      return storage
        .bucket(bucketName)
        .upload(file.path, {
          destination: file.path.split(dir).pop()
        })
    }
  ))

(with the exception that the console.log will not be shown in case of synchronous errors in the chained calls?)

Just run this:
const sleep = (ms, ...args) => new Promise(r => setInterval(r, ms, args))

Promise.all([1,2,3].map(n=>sleep(n,'badWhatever').then(console.log('bad',n))))

Promise.all([1,2,3].map(n=>sleep(n,'goodWhatever').then(()=>console.log('good',n))))

console.log('synchronous')

If generator had .on('data' method, it would be really usefull that way.

Here are your small potatoes
const { Nuxt, Generator } = require('nuxt-edge/dist/nuxt')
const storage = require('@google-cloud/storage')()
const { resolve } = require('path')
const { watch } = require('chokidar')

const bucketName = 'site bucket' //change it
const dir = resolve('/tmp/dist')
const dirLen = dir.length

const config = require('./nuxt.config.js')
config.generate.dir = dir

const nuxt = new Nuxt(config)
const generator = new Generator(nuxt)

exports.generate = async function(req, res) {
  if (req.method !== 'POST') throw new Error('wrong method')

  const promises = []
  const bucket = storage.bucket(bucketName)
  let aborted = false

  const abort = err => {
    if (!aborted) aborted = err
  }
  let i = 0
  const upload = path => {
    if (aborted) return
    const dest = path.slice(dirLen)
    console.log('gonna upload', dest)
    promises.push(
      bucket
        .upload(path, {
          gzip: true,
          destination: dest
        })
        .then(() => console.log('uploaded', dest), abort)
    )
  }

  const watcher = await new Promise(resolve => {
    const watcher = watch(dir)
      .on('ready', () => {
        resolve(watcher)
      })
      .on('add', upload)
      .on('change', upload)
      .on('error', abort)
  })

  await generator.generate({ build: false, init: true })

  await Promise.all(promises)

  watcher.close()

  if (aborted) throw aborted

  res.status(201).send('generated')
}

Hory shet, you right. But it somehow worked for me.
.then(console.log)
is the right way I usually do, but it doesn't suit this case

In case someone want to try this trick, I'll tell what caveats I've experienced:

if you want to map your domain to google bucket to serve static data, you should use load balancer, which costs 30$/month.
google CDN is not much faster then bucket itself, it just has consistent speed across the world.
google static server software is good to serve bundles, images but bad to serve html. It has strange behaviour with trailing slash redirects, it doesn't work well with nuxt because of that.

You can put free Cloudflare in front, that can rewrite the trailing slashes among other things afaik.
But why not host your static site on Firebase Hosting instead? (Or even netlify)?

I just tried the simplest way. And yes, there are lots of things which will solve my issues, but I didn't make any experiments with them yet.

This can only be done on your machine, and cannot be done within Cloud Functions.

That's a really weird limitation, I'm surprised.


check numerus format in check-translations.py

I know we're two hours out from the 1.14.7 PR deadline but I made a quick PR for https://github.com/dogecoin/dogecoin/issues/3445. If this is merged now, we can have better translation linting for 1.15.
Alternatively, feel free to push this back to the next release.

Let's do it for next release; there's 1h30m left on the translation deadline.

With the currently merged translation files:
Checking all translations...
No errors detected.

When I manually remove a numerusform element:
Checking all translations...
Numerus message without numerusform translations, needs fix.

When I manually add extra text to a numerusform element:
Checking all translations...
Numerus message contains extra text
        正在处理数据块..., needs fix.

I was thinking that we should also check a couple more things while we're at it - the stricter the linter is, the better we protect the build (and testers):
<translation> elements must have:

no other child elements other than <numerusform> when there is numerus="yes"
no child elements at all when numerus!="yes"

Would it be possible to add double tags to this check too?
As in , << or >> would throw an error.

I believe the XML parser already does that, when I add an extra bracket it goes
Traceback (most recent call last):
  File "/home/anthony/Programming/GitHub/dogecoin/contrib/devtools/check-translations.py", line 164, in <module>
    errors_detected = check_all_translations()
  File "/home/anthony/Programming/GitHub/dogecoin/contrib/devtools/check-translations.py", line 121, in check_all_translations
    tree = ET.parse(io.BytesIO(data), parser=parser)
  File "/usr/lib/python3.10/xml/etree/ElementTree.py", line 1222, in parse
    tree.parse(source, parser)
  File "/usr/lib/python3.10/xml/etree/ElementTree.py", line 586, in parse
    parser.feed(data)
xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 477, column 9

Would it be possible to add double tags to this check too?

It does this during parsing - do you have an example run where this wasn't detected?

The double brackets were fixed in the final commit "small fix 2".

Analyzed the issue, I think I know how to fix it. Will propose on the new branch.

@patricklodder I implemented the suggestions, is there anything else you can think of?

Fixed and tested with Patrick's input
Checking all translations...
Numerus message without numerusform translations, needs fix. Only text in numerus
Numerus message contains extra text Thisfails, needs fix.
 Numerusform with extra child element
Non-numerus message contains child node in translation, needs fix. Numerusform without numerus attr
Non-numerus message contains child node in translation, needs fix. Random additional element

Works for me now. Could use a rebase & squash.

Squashed, thanks!


Wrapping of Playwright into FastAPI for Gradio compatibility

@mbrunel / @shubhamofbce : I think Playwright might be a better default solution as it is faster / easier to install, more performant and also has built-in wait mechanisms.
As Gradio is our most popular interface today, and given Playwright's popularity, I thought it could be good to solve that issue.
From our last discussions, I think there is some async issue when using Gradio.
Would it technically work to wrap the Playwright Driver and/or the Action Engine inside a FastAPI and call it from the Gradio?

@dhuynh95 I can give it a try, will let you all know my findings.

I created a very simple gradio app, just to goto the link mentioned in the input box in the same browser.
I found that the exact same code is working on gradio Interace but not on Gradio blocks.
With gradio block - which we are using at lavague, it throws error:  It looks like you are using Playwright Sync API inside the asyncio loop
import gradio as gr

global_page = None

def get_page():
    global global_page
    if global_page is None:
        from playwright.sync_api import sync_playwright
        p = sync_playwright().__enter__()
        browser = p.chromium.launch(headless=False)
        page = browser.new_page()
        global_page = page
    return global_page

def goto_link(url):
    page = get_page()
    page.goto(url)

# Uncomment this to try using Gradio blocks
# with gr.Blocks() as demo:
#     gr.Markdown("Start typing below and then click **Run** to see the output.")
#     with gr.Row():
#         inp = gr.Textbox(placeholder="Enter your link?")
#     btn = gr.Button("Run")
#     btn.click(fn=goto_link, inputs=inp, outputs=[])

demo = gr.Interface(
    fn=goto_link,
    inputs=["text"],
    outputs=["text"],
)

demo.launch(debug=True)

The funny part is, Interface extends Blocks class.

Interesting!
I guess blocks is more useful for us.
Can you explain to me what are the issues we currently face?
To my understanding there is some issue in using Gradio and Playwright due to sync/async

@dhuynh95
The current issue with using sync playwright api with gradio is:
Gradio tries to open this in a new thread and playwright sync implementation doesn't allows that:
When you run
!lavague -c examples/configurations/api/openai_api_playwright.py launch
Error:
/playwright/_impl/_sync_base.py", line 111, in _sync
    self._dispatcher_fiber.switch()
greenlet.error: cannot switch to a different thread

We don't see this thread issue if we async playwright api but a different error later, but i am currently looking at if we can stop gradio from opening it in a new thread, that will allow us to use just sync api everywhere. I think that is possible.

Thanks @shubhamofbce ! I guess the question now is:

Should we modify Gradio not to open a thread? -> Seems complicated, as for instance we have streaming outputs of the Action Engine.
Should we run the Driver handler / Action Engine in a separate thread / process and call it as if it were an API call? -> Seems more amenable, as we would not touch Gradio or Playwright too much

What do you think?

Hey @dhuynh95 Its not that complicated, I have found the solution. It is hardly a few lines change in our approach to call the gradio demo not in gradio.
You will see lavague working with Gradio very soon. 🎈 🥳

@shubhamofbce Super! Also, don't bother with streaming if it blocks you. It's a small cost to pay to have Playwright compatibility quickly

I have posted an issue on discord #support. That is blocking me right now from testing the solution. Can you take the latest pull on your machine and try
!lavague launch and confirm if it is working.

Done


[utils] add OTBR_DISALLOW_COPY_AND_ASSIGN

This commit uses OTBR_DISALLOW_COPY_AND_ASSIGN to make sure certain objects are never copied.
Should choose the preferred one of https://github.com/openthread/ot-br-posix/pull/1177 and this PR.

LGTM overall with a question: Why not follow the pattern in third_party/openthread/repo/src/core/common/non_copyable.hpp??

Tried that way, but didn't work out well.

close in favor of https://github.com/openthread/ot-br-posix/pull/1177


[models] Add static method to create an instance from JSON

I added a proxy static method to create an instance of Formidable more easily from a JSON definition:
>>> form = Formidable.from_json(json_definition)
>>> form.save()

This implements an alternative constructor, using FormidableSerializer.
This is just a suggestion @moumoutte · Feel free to reject the PR! :wink:

Hmm, my bad. This doesn't work. I will re-work on the PR.

Tests passed perfectly on my machine.

I don't get what's wrong with CircleCI. :unamused:

OK, the issue w/ CircleCI was the version number. :relieved: Fixed in 57d3792.


Add graph paths

Goal
Implement a Graph::Path class and a few algorithms making use of it: shortest path, MST, cycles.

Current coverage is 95.87% (diff: 51.85%)

Merging #6 into master will decrease coverage by 4.12%

@@           master         #6   diff @@
========================================
  Files           8          9     +1
  Lines         294        315    +21
  Methods         0          0
  Messages        0          0
  Branches        0          0
========================================
+ Hits          294        302     +8
- Misses          0         13    +13
  Partials        0          0

Powered by Codecov. Last update d5afa24...2b9ff25


create users from existing entities

[ ] fetch all entities with userId and appId (articles, replyrequests, articlereplyfeedbacks, etc...) and create users for each unique (appId, userId) pair, where the new user id is appId_sha(userId)
[ ] update userId for entities mentioned above
[ ] analytics only has docUserId and no appId, need to refetch all data from replies
[ ] unit tests

[ ] design collision handling -> lowered priority and tracked in https://github.com/cofacts/rumors-api/issues/222

https://github.com/cofacts/rumors-api/pull/226


Dark theme: Palette issue

System information:

win 10 x64
DBeaver version 5.3.3

Describe the problem you're observing:
Dark theme isn't applied for Palette panel

still reproducible against 21.0.3


9311 DEV Update dashboardCtrl.js to include amazonIamRole in $scope.vm.addonsForm and dashboard.html to have checkbox for amazonIamRole

https://github.com/Shippable/pm/issues/9311

This is complete.
Closing.


rebuild! on a scoped collection empties the entire table

It would appear that executing rebuild! on a scoped collection empties the whole table before rebuilding the few selected elements.
In our case, the model is called BusinessUnit.

We unfortunately experienced this problem in production, but were quickly able to recover by doing a full BusinessUnit.rebuild!. However, I think it would be nice to fix this, to avoid the same situation from happening to another unfortunate soul.

Ugh, that's rough, and I'm glad you thought to rebuild the full table. (I'd also suggest taking backups before launching a prod console as a standard operating procedure, speaking from prior scarring production emergencies).
I hate to say it, but the ActiveRecord API is so expansive that documenting every way not to use every function is simply not tenable.
I'd be happy to accept a PR that can detect when rebuild! is being called from a scoped collection, and either raise an error, or remove the table truncation. Either way, at least we avoid your pain.
Thanks for taking the time to report the issue.

What’s the point of the table truncation in the rebuild! class method? The only thing I can think of is to remove hierarchy elements that are not in the main table anymore. I changed the code to only remove those elements, but it seems useless since we had foreign_keys which restricted us from removing those elements (you too in your spec).

@kazalt perhaps I'm misunderstanding you, but the tests don't truncate the hierarchies table to get around FK constraints. In other words, there aren't FK constraints to the _hierarchies tables, which would prevent rows being deleted from _hierarchies tables.
The class-level .rebuild! is to rebuild the hierarchies table from a "clean slate."  If you don't start from an empty table, you can't make assertions against the contents.

@mceachen the delete_hierarchy_references should be enough ? I mean, if i rebuild the whole table, each row will delete their own references before adding them back.
for the foreign keys, i'm talking about those :
add_foreign_key(:tag_hierarchies, :tags, :column => 'ancestor_id')
add_foreign_key(:tag_hierarchies, :tags, :column => 'descendant_id')
I can't delete an instance without deleting their hierarchies, so the truncation seems useless. I talk about that truncation :  hierarchy_class.delete_all # not destroy_all -- we just want a simple truncate.

@kazalt yes, if your FK constraints are all valid, the truncation shouldn't be necessary, but realize when I wrote this gem, rails 2 didn't even support foreign keys. Perhaps the truncate could be an option?
.delete_all doesn't call any callbacks, which is why I used it instead of destroy_all.
If you have time, please read, comment, and vote on #277 !

I have the same problem with STI. Given the example from the README, if I do
class Tag < ActiveRecord::Base
  has_closure_tree
end
class WhenTag < Tag ; end
class WhereTag < Tag ; end
class WhatTag < Tag ; end

and call WhatTag.rebuild!, it will first empty the hierarchy table, thus taking all the Tag hierarchies with it.
For the moment, I worked around it by overloading the rebuild! class methods in all subclasses like this:
class WhatTag < Tag
  def self.rebuild!
    Tag.rebuild!
  end
end

@gr8bit thanks! I think that would be great to add to the docs. If you have time, I'd be happy to take a pr!

PR #287
Thank you for your great work! 👍

Perfect, thanks!


AppContainer and App (component) to be renamed

For two reasons:

Conflict with react-hot-loader's.
Component group may use that name. e.g. components/app/DefinitionList, components/app/UserLogin...

Done by #62


[crypto] Make some small adjustments to the asymmetric cryptolib API.

Two relatively small changes to the top-level API for asymmetric routines in the cryptolib:

Replace verification_result_t with hardened_bool_t, since the hardened_bool_t type already appears in e.g. key configurations.
Pass some additional information to certain ECC async routines.

The information passed to ECC async routines is:

key-generation start() routines now get the private key configuration; without this the implementations can't know e.g. whether the key should be a sideloaded key or not
all ECDSA/ECDH finalize() routines now get information about what curve in particular is being used; without this the implementations can't know which OTBN program is loaded and therefore where they should look for the results in OTBN's memory.

This introduces some consistency requirements for the caller; they might get a silently wrong answer if, for instance, they pass a different curve to finalize() than they passed to the previous start(). We could theoretically change that by adding something to the OTBN programs that e.g. writes some magic value specific to that OTBN binary or even that specific mode of the binary at a fixed memory address that is the same across all programs, and having the Ibex-side code return an error if the curve/sideloading combination if the number isn't the expected value. However, I think this might be overkill; the library already expects the caller to ensure that start() and finalize() calls always match, so this doesn't seem to me like a large escalation.

Merging this so that I can build ECDSA on top of it, but happy to adjust if anyone has post-merge comments.

LTGM, Jade. Added the changes to the crypto spec, to keep it in sync.


Create resource section

Used links from government websites, articles and news websites.

@MUDITJAINN could you please review this PR? Let me know if any changes are needed to be done!

Ok will work on this and update!

Whats the update?

Yes, updated the PR. Here is how the page looks:
[https://drive.google.com/file/d/1KtzlIS1RzyLdCgeTt_kJ7zV4w-WIAV6C/view?usp=sharing](screen recording of the page)


oracledb recursive CTE

Environment
Knex version: 0.20.10
Database + version: oracle xe 18.4.0
OS: Windows / linux docker dbs
Feature discussion / request
I understand that recursive CTE in oracledb have to include the columns as in
WITH alias (column1, ...) AS (...)
The column information currently can't be provided to .with() or .withRecursive(), is it?
Can alias be raw as well? What would be the best way to include the columns so that it also works with other dbs?
Could with() / withRecursive() get a third parameter that is added to with-statements to be honored by oracle compiler? @atiertant

Please add code examples here too.

knex.schema.createTable('treenode', function(table) {
  table.uuid('id').notNullable().primary();
  table.uuid('parentId');
  table.foreign('parentId').references('id').inTable('treenode').onDelete('CASCADE');
});
...
await knex
  .select('*')
  .from('descendants')
  .with('descendants', (qb1) =>
    qb1
      .select('treenode.id')
      .from('treenode')
      .where({ id: 'root' })
      .unionAll((qb2) => qb2
        .select('treenode.id`)
        .from('treenode')
        .join('descendants', 'descendants.id', 'treenode.parentId')
      ));


Link to GitHub contribute page

This is a Feature Request

What would you like to be added
Change Start Contributing to add a hyperlink to https://github.com/kubernetes/website/contribute
Why is this needed
This change will help recruit new contributors
Comments
/language en
/good-first-issue
:smiley:

You can add the link anywhere that makes sense. If you're not sure, I suggest somewhere in the section https://kubernetes.io/docs/contribute/start/#improve-existing-content

/assign


Niloofar Sadeghi / Convert live chat components to typescript

Changes:

...

Type of change

[ ] Bug fix
[ ] New feature
[ ] Update feature
[x] Refactor code
[ ] Translation to code
[ ] Translation to crowdin
[ ] Script configuration
[ ] Improve performance
[ ] Style only
[ ] Dependency update
[ ] Documentation update
[ ] Release

Could you please fix the code smells as well?

Conflicts 🙏  @niloo-fs


'Pause on Hover'?

Hi I am wondering if there is a "pause on hover" option. I am guessing this might be a feature request. Right now I have:
play: 5000
... set to auto advance the slides and that works nicely but the pause on hover function would also be nice.
Thanks.

This is my solution to @nicinabox code to prevent instant slide change on mouseleave. Plugin's start method needs to be altered as follows
start: function() {
    var that = this;
    if (that.options.hashchange) {
      $(window).trigger('hashchange');
    } else if (!this.inited) {
      this.animate();
      this.inited = true;
    }
    ...
    ...
}

This is my working solution:
var $slides = $('#slides');

$slides.superslides({
   animation: 'fade',
   animation_speed: 350,
   play: 5000
});

// Pause Slider on Mouseover
var sliderTimeout;

$slides.on('mouseenter', function() {
   clearTimeout(sliderTimeout);
   $(this).superslides('stop');
});
$slides.on('mouseleave', function() {
   sliderTimeout = setTimeout(function() { $slides.superslides('start'); }, 5000);
});