plan for 1.5

Goals for 1.5

[x] binding for servo to atlas (probably in servo repo)
zero to cloud example setup

[x] cloudwatch backend
[ ] cloudtrail backend
[ ] mirrored in-memory backend
[ ] all apps (eureka/edda/etc) publish to memory backend
[ ] regional aggregation cluster combining memory and cloudwatch backends
[ ] enable dynamic props (archaius) via dynamo for controlling atlas
[ ] system metric polling

[x] experimental implementation of percentile db

Tentative date end of Q1.

Will cast my vote for mirrored in-memory back end. When chatting up atlas I find myself often saying "this thing is amazing but you lose the data when you restart" :)
If cloudwatch backend supported all the basic publish/query operations that'd probably be viable too. Basically anything to ensure metrics stick around after loss/restart.

There are a few of those that are getting close to being merged in. I would be interested in learning a little more about how you are trying to use it and the ideal deployment model. For our typical setup we have 6+ clusters:
https://github.com/Netflix/atlas/wiki/Overview#resilience
But it was primarily setup that way to support the scale we needed for our largest deployments and there is quite a bit of configuration involved. Since we were the only ones operating it for a long time and we rarely do a clean install, ease of use for the operator wasn't a big concern. With the OSS setup we want to minimize the effort to get started where possible.
Also, one of the things I found when experimenting with the zero to cloud example is that it is extremely painful to operate without the automation we have internally. So I think at least some basic automation is needed to make that part viable and easier to test, but I haven't had time to look at it and I'm not really sure when or if the internal tools we're using would be an option externally.

So far my usage has taken two forms, both of which use https://github.com/stellar/docker-atlas for both and https://github.com/stellar/docker-stellar-core/blob/master/heka/stellar_core_metrics_filter.lua to pull data from the application.

One-off containers used to collect metric data during acceptance testing. Obviously no need for persistence there.

As a more-easily-explorable way to access app telemetry in production. For this I also use a single atlas instance, but the container generally sticks around and doesn't get restarted very often.

For the second case, heka pulls data from the app, publishes it into both atlas & influx. Then I get dashboards from influx+grafana but still use atlas since it offers easier ways to explore the data and also easier sharing of pngs.
I use this atlas to power a basic alert system similar to the earlier one at Netflix (just alerts on any line > 0 that starts with "alert: ").
The data volume is still quite low so it's just one host running both influx and atlas and that's been fine. But some option around persisting data across reboots would make it easier to drop influx. Though I'd need to pick my atlas grafana plugin back up probably to provide something more approachable to folks not yet familiar with ASL.

As for deployment automation, I'm not too concerned with an answer to that as the places I'd look at deploying it probably already have some chef, puppet or ansible base to work from.
Would be curious to hear what in particular was painful to operate. I've found atlas very straight forward when compared with graphite or even influx.
Wonder if some of your pain might stem from how much better the netflix deployment tools are then most of what everyone else is doing.

@brharrington so it just dawned on me, when you roll out a new build of atlas do you just let the new instances sit for 4 hours (or whatever the first mirror retention is) before putting it in service?
The diagram also shows an arrow from M1->persistence. Is that somewhere in the current OSS distribution?

when you roll out a new build of atlas do you just let the new instances sit for 4 hours (or whatever the first mirror retention is) before putting it in service?

Yes. I put up an old presentation that shows a little more about how we run it:
http://netflix.github.io/atlas/atlas_overview.pdf#page=39
We will spin up a new instance and let it fill for the window for the short-term storage. This also lets us vet out the new version before we rely on it. When we're confident we'll terminate the old cluster.

The diagram also shows an arrow from M1->persistence. Is that somewhere in the current OSS distribution?

There are a few parts to the persistence most aren't in the open repo yet, but enough to be generally functional will be for 1.5.

Copying to storage layer from the backend. We use an intermediate cluster that then proxies it to S3. This is mostly for historical reasons prior to S3 being the main storage, but we kept it because the proxy is then a simple stateless cluster that we can rev faster. The stateful deployments take longer. To simplify for the zero to cloud example I'm planning to have an option that will just write to an S3 bucket directly to reduce the number of moving parts. You could plug in some other storage if needed.
Storage layer. We currently use S3 for this as it is convenient and we also do a lot of processing on the data using EMR for data correction across mirrors, computing rollups, usage reports, etc. For example, for longer historical we run a 4d and 2w cluster (overview diagram). The main reason for having two is that we drop the node dimension and do some other rollups to reduce the cost for the longer 2w cluster (metric counts by index). The rollups are computed in EMR. The EMR jobs and associated management tools are pretty tied into internal stuff right now so there are no immediate plans to open source that other than a high level goal to move as much as possible to the open repo over time.
Loading and serving from the storage layer. This should also be doable in 1.5, but there are a few caveats we have to figure out. In the EMR we also generate the output so we'll have an optimal number of files for the instance sharding we use on the historical. Not yet sure how that will work if we are directly using files produced from the mirrors to load.

Thanks for the overview. We could also probably add some sort of simple file store that could back simple uses.

Would be curious to hear what in particular was painful to operate.

Just a lot of manual steps and also I think some of it is the bootstrapping which was already done by others for the internal deployments. I've gotten used to just adding a small amount of config and checking in, then the deployment automation will deal with creating the images, asgs, elbs, dns names, security groups, etc.
@copperlight on our team is experimenting with some options. Mainly what I want is an easy way to take a clean account and get a full stack running in a manner similar to how we run internally. This will give me a better way to vet stuff works and notice where we might be depending on internal assumptions. It should also make it easier for others get started or at least see a more concrete example.

Yeah, I miss a lot of that tooling on a daily basis. Brent's tooling especially :)
At least for testing atlas in a "clean" environment I suspect you could get by with just minimal scripts that set-up/tear-down the whole thing (clusters, EMR, etc).
Some sort of simple file storage would be a great start though. I was imagining something where memory is still where all the action happens, but there are periodic syncs to disk.
At least that way for small scale cases, I can recommend use of a single-instance atlas deployment with the file storage on a mounted EBS.
It wouldn't be HA, but it'd be easy to start and you could still repair a failure without losing the entire data set.

In other news, is atlas->cloudwatch planned for the OSS repo any time soon?
If it'd an avenue to do things like sum cloudwatch metrics across multiple dimensions I'd have a use for that as well.

That should be straightforward, just need to find a bit of time to move it over. I'll try to get to it this week.

sweet! no big rush. I'll also need to polish my grafana->atlas plugin to make the best use of it

Version 1.5 anywhere near to be open-sourced? Or is this abandoned? Thanks.

It's not abandoned, but I don't have a precise timeline right now. There are a lot of internal projects competing for time.

Anything new about this please? We see so many interesting things (dashboards, query builder, etc) in Netflix presentations, but we cannot get our hands on them!

The current goal is to finish up 1.5 by end of April.

Any insight on whether you are going to open source the resilience-related features?

I would like to, it is mostly a question of time. There may be some help coming on that front, but not sure yet.


Execution context was destroyed, most likely because of a navigation

That you for releasing this awesome library!
One issue that I get occasionally is the following:
[ERROR] 🚫 arun(): Failed to crawl https://piworks.net/, error: [ERROR] 🚫 crawl(): Failed to crawl https://piworks.net/: Page.evaluate: Execution context was destroyed, most likely because of a navigation
I am struggling to diagnose the exact route cause of the problem. I was wondering if you had any ideas? Here is my code, thank you.
async def scrape_landing_page(url: str) -> str:
    async with AsyncWebCrawler(verbose=False) as crawler:
        result = await crawler.arun(
            url=url,
            magic=True,
            wait_until='networkidle0',
            remove_overlay_elements=True,
            js_code=[
                "document.querySelector('.cookie-accept')?.click();",
                "window.scrollTo(0, document.body.scrollHeight);",
                """
                var loadMoreButton = document.querySelector('.load-more');
                if (loadMoreButton) {
                    loadMoreButton.click();
                }
                """
            ]
        )
        return result

@Olliejp Thanks for using our library. Please try the new version, which I'm going to release today or tomorrow, 0.3.74, because when I tried the link that you gave me, everything works well. And as a side note, by default, the library will scroll to the bottom of the page so you don't need to do that. And another thing that we are working on is handling cookies and banners intelligently in the library. I will update more about it.
async def main():
    async with AsyncWebCrawler(
            headless=True,  # Set to False to see what is happening
            verbose=True,
            sleep_on_close = True,
    ) as crawler:
        result = await crawler.arun(
            url="https://piworks.net/",
            cache_mode=CacheMode.BYPASS,
            remove_overlay_elements=True,
        )
        print(len(result.markdown))

if __name__ == "__main__":
    asyncio.run(main())

Output:
[INIT].... → Crawl4AI 0.3.74
[FETCH]... ↓ https://piworks.net/... | Status: True | Time: 4.38s
[SCRAPE].. ◆ Processed https://piworks.net/... | Time: 158ms
[COMPLETE] ● https://piworks.net/... | Status: True | Total: 4.60s
18657


[Fix] retain HealthyPanicThreshold even if it's set to 0 for disabling Envoy's panic mode (#13682)

Please provide a description for what this PR is for.
Fixes #13682

By the Envoy's change #7478, we will be abel to disable panic mode by setting CommonLbConfig.HealthyPanicThreshold to 0.
However, the pilot doesn't generate the HealthyPanicThreshold field if its value is 0.
In this case, Envoy interprets that the field value is the default value (50).

when DestinationRule with outlierDetection.minHealthPercent = 0 created

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  annotations:
    name: orders
    namespace: sock-shop
spec:
  host: orders
  trafficPolicy:
    outlierDetection:
      minHealthPercent: 0

a releated sidecar got configuration without "common_lb_config.healthy_panic_threshold

{
  "cluster": {
    "common_lb_config": {
      "locality_weighted_lb_config": {}
    }

pilot should generate healthy_panic_threshold with Percent type value.

{
  "cluster": {
    "common_lb_config": {
      "healthy_panic_threshold": {},
      "locality_weighted_lb_config": {}
    }

And to help us figure out who should review this PR, please
put an X in all the areas that this PR affects.
[X ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: mnktsts2, rshriram
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/pkg/networking/OWNERS [rshriram]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@mnktsts2: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio-codecov-master
14f5dcc2332d7c4ec26febdac03b844eaafd73fa
link
/test istio-codecov-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@mnktsts2: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio-codecov-master
14f5dcc2332d7c4ec26febdac03b844eaafd73fa
link
/test istio-codecov-master

integ-pilot-k8s-presubmit-tests-master
14f5dcc2332d7c4ec26febdac03b844eaafd73fa
link
/test integ-pilot-k8s-presubmit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@mnktsts2: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio-codecov-master
14f5dcc2332d7c4ec26febdac03b844eaafd73fa
link
/test istio-codecov-master

integ-pilot-k8s-presubmit-tests-master
14f5dcc2332d7c4ec26febdac03b844eaafd73fa
link
/test integ-pilot-k8s-presubmit-tests-master

integ-istioctl-k8s-presubmit-tests-master
14f5dcc2332d7c4ec26febdac03b844eaafd73fa
link
/test integ-istioctl-k8s-presubmit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@mnktsts2: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio-codecov-master
14f5dcc2332d7c4ec26febdac03b844eaafd73fa
link
/test istio-codecov-master

integ-pilot-k8s-presubmit-tests-master
14f5dcc2332d7c4ec26febdac03b844eaafd73fa
link
/test integ-pilot-k8s-presubmit-tests-master

integ-istioctl-k8s-presubmit-tests-master
14f5dcc2332d7c4ec26febdac03b844eaafd73fa
link
/test integ-istioctl-k8s-presubmit-tests-master

integ-mixer-k8s-presubmit-tests-master
14f5dcc2332d7c4ec26febdac03b844eaafd73fa
link
/test integ-mixer-k8s-presubmit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@mnktsts2: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

doesn't this make the default disabled now? I think we have a problem that we can't distinguish between it being unset or being explicitly set to 0

doesn't this make the default disabled now?

No.
The default value of outlierDetection.minHealthPercent is 50[%].
So Envoy's panic mode is disabled only when users explicitly set outlierDetection.minHealthPercent to 0[%].

I think we have a problem that we can't distinguish between it being unset or being explicitly set to 0

Yes, I think so.
Especially, in the case that the default value isn't 0, it's difficult to set the Envoy's config field to 0 via gRPC (protoc).

@howardjohn Sorry, I mistaken the meaning of "the default value" between the doc and protoc.
minHealthPercent is a just int32 type field.
As you said, this change make the default disabled. umm...
https://github.com/istio/api/blob/99722f53e70c724a43544b1c685b1dcb8a6eef4e/networking/v1alpha3/destination_rule.pb.go#L1529-L1534

fix the comment. Its okay to disable panic threshold by default as its not typically applicable in k8s environments with few pods per service

New changes are detected. LGTM label has been removed.

@rshriram I've fixed it for trial.
But...

it need to fix some comments in istio.io/api/networking/v1alpha3/destination_rule.proto too.
it might be a high-risk to change the default behavior.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: mnktsts2, rshriram
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/pkg/networking/OWNERS [rshriram]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@mnktsts2: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-mixer-k8s-presubmit-tests-master
f3508ce7230f61a74dc03f3a7f0f7de15cbdc004
link
/test integ-mixer-k8s-presubmit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@mnktsts2: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-mixer-k8s-presubmit-tests-master
f3508ce7230f61a74dc03f3a7f0f7de15cbdc004
link
/test integ-mixer-k8s-presubmit-tests-master

istio-racetest-master
f3508ce7230f61a74dc03f3a7f0f7de15cbdc004
link
/test istio-racetest-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@mnktsts2: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-mixer-k8s-presubmit-tests-master
f3508ce7230f61a74dc03f3a7f0f7de15cbdc004
link
/test integ-mixer-k8s-presubmit-tests-master

istio-racetest-master
f3508ce7230f61a74dc03f3a7f0f7de15cbdc004
link
/test istio-racetest-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

test failure is related to #15769 .. ?

/retest

@mnktsts2: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

istio-racetest-master
f3508ce7230f61a74dc03f3a7f0f7de15cbdc004
link
/test istio-racetest-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest


Supported for cilium

Hi there, is there any plan for cilium supporting?

There are a lot of nice features in 1.6 release of cilium. It would be nice if cilium support would be integrated to rancher.
https://cilium.io/blog/2019/08/20/cilium-16/

Guys, what is the progress on this (would be great to have this as standard set AirGapped pull)
https://cilium.io/blog/2020/02/18/cilium-17/
(from article above)
Hubble: We've heard lots of positive feedback on Hubble since the announcement. To make cluster connectivity easier to visualize and debug, we've released a new Hubble UI as open source so you can tweak and extend it too! We've also been working on various improvements to the core Hubble implementation, including better correlation between network flow data and Kubernetes resources. (More details)
Cilium Cluster-wide Network Policies: The 1.7 release brings the much-anticipated Cluster-wide CNP feature. This allows users to apply baseline network policies which apply to pods across the cluster, regardless of the namespace that the pod resides in. (More details)
Kube-proxy replacement with Direct Server Return: As presented at Kubecon US 2019 and FOSDEM 2020, this release rounds out the full service feature set for replacing kube-proxy and additionally adds support for Direct Server Return (DSR). This further improves the latency and performance of the kube-proxy replacement in Cilium. Moreover, our kube-proxy replacement comes out of beta and is automatically enabled in environments with newer kernels. (More details)
Extending L7 policies with TLS introspection: We've added support to Cilium to configure Envoy TLS certificates via Kubernetes resources or local files. This allows Cilium to transparently observe HTTP calls and enforce API-aware policies on TLS-encrypted sessions. (More details)
L7 visibility annotations for pods: Previously, to gain L7 visibility into traffic in the cluster, users would need to write network policies that put pods into a default deny posture. Visibility annotations now allow users to gain L7 visibility into network traffic first, then subsequently craft full network policies using these insights. (More details)
Pure Go eBPF library: This is the first Cilium release to begin using the pure Go eBPF library co-written between the Cilium community and CloudFlare. This streamlined library already allowed Cilium to jettison CGo, improving performance and reducing binary sizes. (More details)
Improvements to scalability through Kubernetes EndpointSlice support and Cilium agent improvements, development on upstream Linux, running our testing environment on managed Kubernetes, distributing Cilium via Helm repositories... and much more! For more highlights, see the 1.7 Release Highlights.

Guys please consider adding cilium. My dream setup would be k8s 1.18 with dual stack and no kube-proxy. Cilium doing all the stuff... The cilium hubble visibility into the network is still unbeaten.

The install is pretty easy and is doable via addon_includes:
rancher_kubernetes_engine_config:
  addons_include:
    - https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml

The main rub I see is the bpf mount for production clusters, but perhaps that can be done via a "cni install" init container or similar.

This will be coming as part of v2.6 with RKE2 provisioning and we will track support of this issue: https://github.com/rancher/rancher/issues/32381


Add support to extract archived files entirely

Updated 02-02-22
When bin finds an archive type as a source, it currently lists the files inside and prompts the user which file to extract.
There are several projects like https://github.com/kubernetes-sigs/kui which requires extracting the complete archive and then add a specific binary to the PATH variable. It'd be great if bin could help with this workflow. i.e
$ bin install <some_package.zip>

some_package has been installed in $PATH/.some_package (hidden folder maybe?), executable selection:
[1] some_package/packagebin
[2] some_package/packagebin2
[*] All executables
Select option: 1   # This could be 1,2 (list) 1-n (range) or * for all?

# After this selection, `bin` would make a symbolic link of the selected executables in the `default` config path.

some_package has been installed successfully.

What things should bin do to provide this experience?

Check if the root file of the archive file is a folder so it creates a hidden(?) directory in case it's not the case to avoid extracting files spread all over the bin default path.
After extracting, bin should scan all files and folders that contain binaries and display them for the user to select
bin should create symbolic links of the selected files in the default_path config dir.
We need to implement symlink creation in all platforms

note: This feature is breaking UX compatibility since the default way of installing archive files would be through the experience highlighted here instead the current one (selecting one single file). I'm personally ok with that since I believe this new experience is way better for this use case.

Alternatively, could we just have bin symlink each of the binaries into ~/bin?
This would be similar to brew link
containerd/nerdctl is another great example of a multi-binary package with other important assets:
bin install github.com/containerd/nerdctl
   • Getting latest release for containerd/nerdctl

Multiple matches found, please select one:

 [1] nerdctl-0.16.1-linux-arm64.tar.gz
 [2] nerdctl-full-0.16.1-linux-arm64.tar.gz
 Select an option:

Alternatively, could we just have bin symlink each of the binaries into ~/bin?

I like this approach as well. What I like about this is that we don't need mess with the user's PATH or instruct them to do any further step after extracting.
I'll update my 1st post with the new proposal

Funny enough, I created a brew formula for nerdctl because I didn't like having to do the extraction/linking every time https://github.com/rothgar/homebrew-tap/blob/master/Formula/nerdctl.rb
I think symlinking all the binaries sounds fine (so long as a file doesn't already exist). Only thing I'm not sure about is if we need the extracted folders to be hidden. I'd be fine with a regular folder since that's where the symlink will be pointed anyway.

I realize this is a niche use case, but I use Syncthing to synchronize my bin directory, and this flow would kind of break some stuff. I can switch away from Syncthing for bin-handled files, since I already sync the config file and it has bin ensure, so that's not a big issue. However, I think it would be cleaner if it used a temporary directory (ie with mktemp) to store the files before copying the final output to the path.
This avoids storing the entire contents of the archive when all I want is a single binary. However, I do recognize that this more general method gets basically every case and works well both with programs that require the extra files and those that don't.
I just want to request that the symlinks are relative, and not absolute, so syncing programs can sync the symlinks properly.

Does syncthing have a way to follow symlinks for a directory to the actual files so you can keep syncing just the ./bin directory?
Alternatively, could you create an archive that follows the links and sync that with a Makefile or something?

I'm not sure about is if we need the extracted folders to be hidden.

Agreed. I would think we would not change any folder names.
We could store them in a hidden folder underneath the binary dir: ~/bin/.lib/
Or create another location under: "${XDG_DATA_HOME:-"$HOME/.local/share"}" ?
Unrelated, but what about ~/.local/bin ?
ref: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
(I feel like this spec is missing some important things, but it's better than nothing)

Synching can sync symlinks as long as they're relative inside the synced directory

What about following/resolving the symlinks so synching would sync the file it points to?
I was thinking that an option like that would let you keep your "only copy the binaries" use-case if the bin library folder was outside the bin directory or you ignored the library.
+1 though relative symlinks is the way to go so that the bin folder and any other dependent folders are portable.

it doesn't make sense to put them all on the PATH.

Does having a hidden ~/bin/.lib/ folder solve this? PATH would ignore it, and it's just a single inode so it won't affect path lookups negatively. This would make the ~/bin/ directory completely self-contained -- all the symlinks would be valid, even if you moved the directory.

I haven't mentioned this, but one of the other reasons I want the folders to be saved is so that I can symlink to the other files.
For instance, if a project ships shell completions, I want to be able to source those files in my .bashrc or zsh ${fpath}.
Same thing for manual entries.
Maybe there are even things bin could do to heuristically point these sorts of files out at install/upgrade time, but that's a different feature.

I was thinking that an option like that would let you keep your "only copy the binaries" use-case if the bin library folder was outside the bin directory or you ignored the library.

That's fine, since I sync the bin config file, so I don't have to sync the binaries themselves as well, I guess.

+1 though relative symlinks is the way to go so that the bin folder and any other dependent folders are portable.

Agreed, not sure what other setups as weird as mine exist, but this seems like a sensible thing to do in general.

Does having a hidden ~/bin/.lib/ folder solve this? PATH would ignore it, and it's just a single inode so it won't affect path lookups negatively. This would make the ~/bin/ directory completely self-contained -- all the symlinks would be valid, even if you moved the directory.

I think it would, though I wouldn't call the main directory ~/bin/, probably something like $XDG_CONFIG_HOME/bin/ might be more appropriate, but many people use bin as a directory to store binaries, so you may want to call the directory something like bin-project to make it less conflicty.

For instance, if a project ships shell completions, I want to be able to source those files in my .bashrc or zsh ${fpath} -- same thing for manual entries.

Yeah, I've definitely needed this, and the more I think about this feature, the more I like it. I think that just claiming a directory somewhere under $XDG_CONFIG_HOME and symlinking that to ~/.local/bin/ or somewhere in the PATH (as you described) would be best.


Is this checkout SDK will still use a WebView on the long-term ?

Hey guys 👋🏼
I have implemented your SDK and may contribute to it at some point. I have noticed that the SDK displays the checkout experience through a WebView. Which is fine but not ideal from a user perspective.
While I appreciate your efforts in customizing the WebView, it still does not have the same effect as a fully native SDK. I am curious about the long-term plan for the SDK and would like to understand Shopify's strategy behind it.

Hey @anthlasserre,
We have plans to improve the experience of the webview, to make it feel more native and idiomatic but have no plans right now to make the library entirely native. This may change in future.
We will happily accept contributions 👍
Thanks


[Proposal] snarkOS probably shouldn't count provers when trying to maintain peer connections

💥 Proposal

Currently, the network has more provers than clients / validators. As provers don't sync with the network, it makes bootstraping and syncing hard for nodes:

Most of the peers of bootstrap nodes are provers, and as bootstrap nodes currently are the only canonical block source, sometimes new blocks can't promptly propagate to other network nodes [1];
If client nodes has most of their peers as provers, it will limit their view into the network and can't have fewer peers to sync from.

Also, as the bootstrap nodes has the same max peers as normal clients, a new node will have difficulties connecting to any one of them to do the "bootstrap" (discovering nodes). Moreover, it seems some peers of the bootstrap nodes are hardcoded internal nodes (presumably the validators run by the Aleo team),
the actual max peers for them are actually smaller than normal client nodes.
The proposal is:

Don't count provers when counting the connected peers, or count them separately so nodes could connect to more clients / validators - provers don't sync so their connections should use less resources than other peers;
Increase the max peers of bootstrap nodes for now to allow more nodes to connect to them.

[1] This is also partly because we only rely on polling to sync blocks instead of broadcasting new blocks, but there are still syncing issues if a node is behind the network and need to catch up

this is nice

We now have significantly more provers than clients, so probably we should do something about this soon?


rename subcommand_union_from_mapping to subcommand_type_from_defaults

Copied the example, did not work, thus, updating the readme :)
Also it was indentation was only 7 characters?
Cheers

Thanks Nick!! Hope Freiburg has been treating you ok :slightly_smiling_face:


Restrict the URL used to do delegated authorization

This issue is imported from pivotal - Originaly created at Oct 23, 2023 by Bart Geesink
We currently support a "request_uri" to be added to an authorization request. It allows someone to host a JWT containing request parameters (when doing a request using a signed jwt).
The URL (the request_uri) where this JWT is located is currently not restricted. That means that you can use any request_uri possible  which leads to two security problems:

You can use it to let the server download a very large file
you can use it to discover local open ports (bij using eg http://localhost:25, the returned error gives you the http client library response).

My proposed solution is is to add a configuration option to manage (oidc:request_uri) to restrict the URI that can be used.

https://github.com/OpenConext/OpenConext-oidcng/commit/7bd8ad4a3a75b0843f268624a27117a7a3d29550 (Okke Harsta - Oct 23, 2023)

https://github.com/OpenConext/OpenConext-deploy/commit/d57b5b2fd85d187a790c1b339b7991955d37df7c (Okke Harsta - Oct 23, 2023)


feat(carousel): Count slides by custom tag name

Enable components to extend slide. Carousel considers child components slides if component name matches tagName.
Description
Add tagName property to carousel. Defaults to "slide", which is currently used. Counts child slide components by matching whole tag name (regex ^vue-component-\\d+-${this.tagName}$ used). Added test.
Motivation and Context
When wrapping slides, the wrapping components tag name (not necessarily "slide") prevents it from being considered a slide within a carousel. This results in 0 extended slides showing in carousel. This circumvents requiring extending components to have the name "slide" (of particular annoyance if using ESLint's default preference of PascalCase component names).
If the carousel is intended to have similarly structured slides, there is a lot of boilerplate required. This change allows structuring a component that wraps slide. A simple title or body property could then be supplied to each extended slide.
How Has This Been Tested?
Added test to carousel.spec.js. Test adds three slides to a carousel, two of which are extend slide. The carousel is set to match the tag names of the extended slides. It should only count extended slides.
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.

[x] I have updated the documentation accordingly.

[ ] I have included a vue-play example (if this is a new feature)

@ashtonmeuser This would be great!
@quinnlangille Do you have any issues with merging this?

@quinnlangille Bump. Is there anything you'd like me to add to encourage this to be merged?

Hey @ashtonmeuser, sorry for the delay on this one! We've been crazy busy at the office with year end wrap-up and I've been delinquent on PR reviews. This is a brilliant feature! We had something similar planned internally, but this will meet the needs for sure. I'll merge this into our working branch for next release, it should be out late this week or early next! 🚀
Thanks for the contribution, and again sorry for the delay on review! We'll be more on-top of things going forward :octocat:

^ just resolved some small merge conflicts in the build files.

Coverage increased (+0.3%) to 67.593% when pulling 062d593a1dc98574786f7feeda2b459a72514545 on ashtonmeuser:feat/slide-component-extension-support into 7d5cb5c05006797ab2440ca60c3de57e3576a5c3 on SSENSE:v0.17.0.

Will do. I must have fallen behind.

Yeah we merged a few other PRs into the working branch since, so will just need to catch up with those. It's a few commits ahead of master

@quinnlangille Turned out to be the migration to Vue Test Utils. Fixed.

Ahhh perfect @ashtonmeuser, thanks for branch update 👍 Will merge now :octocat:


Fix rpc-url for Futurenet deployment

Fix rpc-url for Futurenet deployment. It currently has standalone deployment rpc url.

Preview is available here:http://soroban-docs-pr383.previews.kube001.services.stellar-ops.com/


Markdown error in README.md

The README.md file has an error in the markdown, so one of the headers appears as a line plain text instead of an emboldened header.

Already fixed on dev branch.


response errorBody

According to their account information configured local.properties, while the error reported after the ChatGPTService Headers modified the user-agent, but still keep returning errorBody

Hey @gunjianpanxdd, please run with the new release. Thanks!


fixed month-off-by-one error and removed circle on line chart

Minor fixes in preparation to showcase the sample dapp.

LGTM.  Thanks @r-birkner !


Set connect/read timeout when calling the metadata service

Otherwise callers of these methods can be waiting indefinitely.
Fixes #4398

@ajaaym can you take a look at this pls?

@dmichel1, can you please run mvn com.coveo:fmt-maven-plugin:format so that your code complies with our code formatting rule?

@sduskis i rebased and pushed my code again - build should be passing.

Unrelated IT tests are failing for this PR now.

I'll try to run the tests again, just to be sure.

@sduskis yaya they are passing now. thanks


bug: Simple chat is missing telemetry

Version
latest
Describe the bug
no telemetry on submitting chat message
Expected behavior
telemetry on submitting chat message
Additional context
No response

Fixed


added STACKIT quote for Gardener

What this PR does / why we need it:
Added STACKIT quote for Gardener adoption page
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer: pull should be merged later with start of STACKIT beta
Release note:

 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.Timo Lakner seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Fix the relationship between :restorescreen and !cmd

Use alt-screen correctly.
I use a more appropriate method.
Exits correctly after using :!cmd.
I noticed that the display at https://github.com/mattn/longcat could not be saved with my previous patch.
The state of the screen which ended after starting Vim.
Above is a failure example before patch application.
Below is a successful example after applying the patch.

Codecov Report

Merging #5909 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5909      +/-   ##
==========================================
- Coverage   86.03%   86.01%   -0.03%
==========================================
  Files         140      140
  Lines      155627   155627
==========================================
- Hits       133894   133858      -36
- Misses      21733    21769      +36

Impacted Files
Coverage Δ

src/diff.c
85.03% <0.00%> (-0.75%)
:arrow_down:

src/gui.c
63.28% <0.00%> (-0.61%)
:arrow_down:

src/profiler.c
92.47% <0.00%> (-0.56%)
:arrow_down:

src/move.c
87.44% <0.00%> (-0.26%)
:arrow_down:

src/sign.c
94.43% <0.00%> (-0.18%)
:arrow_down:

src/drawscreen.c
83.33% <0.00%> (-0.16%)
:arrow_down:

src/gui_gtk_x11.c
57.44% <0.00%> (-0.15%)
:arrow_down:

src/channel.c
89.19% <0.00%> (-0.07%)
:arrow_down:

src/if_xcmdsrv.c
88.90% <0.00%> (+0.17%)
:arrow_up:

Continue to review full report at Codecov.

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


What's the difference between LBRY and bittorrent?

Can you explain a bit why is it different than using bittorent to share content?
They are both uncensorable and decentralized and there're react front end through webtorrents that lets you watch videos online.
If you have to build lbry on a block chain, what value does using block chain provide us (even it's one sided & only benefitting people who are running it like is it more secure),  if it's just simply tracking who paid for what content people can also use any other coins and sell their content in any way and there's nothing stopping people for re-sharing content through bt just like lbry can't prevent someone re-upload purchased content

https://lbry.com/faq/different-ipfs

Lack of discovery. BitTorrent and IPFS provide decentralized ways to access a unique piece of data or information, but they do not provide a way to discover or find what is available.

The usefulness of the blockchain is that the database of content is distributed among all people who install the blockchain node lbrycrd. With BitTorrent, you don't know what is available, unless you join a website that lists their torrents, there is no central database of all content.

Thank you @belikor !
Another good resource is: https://lbry.tech for tech details


Dev env and Github actions

Since we're planning on modifying more than a few small things in this fork, we should:

Enable local and CI environments using nix
Plug the tests into a Github action

QA steps
Since you already have nix and direnv installed, all you need to install now is devenv as a standalone tool:
nix profile install nixpkgs#devenv

After that all you need to do is run direnv allow in the path for this project.

@davidmh you mentioned in standup that this diff allows developers to not have to worry about the java dependencies on their system, but where is that defined? I don't see a JDK version being referenced anywhere

Is set here: https://github.com/remix/OpenRailRouting/blob/166d3f9fa069c938cfe66a1b2fa79b83c4df10e4/devenv.nix#L4-L5
Since we're not specifying a jdk version, it goes with the default for the current release of devenv:
https://github.com/cachix/devenv/blob/main/src/modules/languages/java.nix#L17-L26
It installs java 21.0.2:

Do we need a specific version?


Can't build -- SDL2 headers not found though installed?

I installed the SDL2 minGW devel packages (manually from .tgz, not using msys2).. but I get this when trying to 'go get -v github.com/veandco/go-sdl2/sdl' as instructed.
See below for error messages and my MinGW-64 and Go env. I'm probably doing something very dumb but I'm a bit new at Go.. tips appreciated, thanks.

russtopia@JUNK /c/Users/Public/Documents/Go/src/github.com/veandco/go-sdl2/sdl (master)
$ go get github.com/veandco/go-sdl2/sdl
# github.com/veandco/go-sdl2/sdl
In file included from C:\Users\Public\Documents\Go\src\github.com\veandco\go-sdl2\sdl\audio.go:3:0:
sdl_wrapper.h:2:23: fatal error: SDL2/SDL.h: No such file or directory
  #include
                       ^
compilation terminated.

russtopia@JUNK /c/Users/Public/Documents/Go/src/github.com/veandco/go-sdl2/sdl (master)
$ echo $GOPATH
C:\Users\Public\Documents\Go\

russtopia@JUNK /c/Users/Public/Documents/Go/src/github.com/veandco/go-sdl2/sdl (master)
$ echo $GOBIN
C:\Users\Public\Documents\Go\/bin

russtopia@JUNK /c/Users/Public/Documents/Go/src/github.com/veandco/go-sdl2/sdl (master)
$ ls /include
SDL2

russtopia@JUNK /c/Users/Public/Documents/Go/src/github.com/veandco/go-sdl2/sdl (master)
$ ls /include/SDL2
SDL.h            SDL_error.h           SDL_loadso.h      SDL_pixels.h    SDL_stdinc.h        SDL_test_fuzzer.h   SDL_version.h
SDL_assert.h     SDL_events.h          SDL_log.h         SDL_platform.h  SDL_surface.h       SDL_test_harness.h  SDL_video.h
SDL_atomic.h     SDL_filesystem.h      SDL_main.h        SDL_power.h     SDL_system.h        SDL_test_images.h   begin_code.h
SDL_audio.h      SDL_gamecontroller.h  SDL_messagebox.h  SDL_quit.h      SDL_syswm.h         SDL_test_log.h      close_code.h
SDL_bits.h       SDL_gesture.h         SDL_mouse.h       SDL_rect.h      SDL_test.h          SDL_test_md5.h
SDL_blendmode.h  SDL_haptic.h          SDL_mutex.h       SDL_render.h    SDL_test_assert.h   SDL_test_random.h
SDL_clipboard.h  SDL_hints.h           SDL_name.h        SDL_revision.h  SDL_test_common.h   SDL_thread.h
SDL_config.h     SDL_joystick.h        SDL_opengl.h      SDL_rwops.h     SDL_test_compare.h  SDL_timer.h
SDL_cpuinfo.h    SDL_keyboard.h        SDL_opengles.h    SDL_scancode.h  SDL_test_crc32.h    SDL_touch.h
SDL_endian.h     SDL_keycode.h         SDL_opengles2.h   SDL_shape.h     SDL_test_font.h     SDL_types.h

russtopia@JUNK /c/Users/Public/Documents/Go/src/github.com/veandco/go-sdl2/sdl (master)
$ go version
go version go1.5 windows/amd64

Sorry for the late response, had to find a Windows machine. I'm not familiar with Windows either but I managed to get it working by installing both MinGW (just for make) and MinGW64. I ran make native at the SDL2-2.0.3 folder and copied the resulting C:\MinGW\msys\1.0\include\SDL2 folder and libSDL2.* files at C:\MinGW\msys\1.0\lib folder into C:\Program Files\mingw-w64\x86_64-5.2.0-posix-seh-rt_v4-rev0\mingw64\x86_64-w64-mingw32\lib. Your paths might be slightly different.

Thanks, I will try it out!
On October 10, 2015 12:36:01 AM PDT, Jacky Boen<EMAIL_ADDRESS>wrote:

Sorry for the late response, had to find a Windows machine. I'm not
familiar with Windows either but I managed to get it working by
installing both MinGW (just for make) and MinGW64. I ran make native at the SDL2-2.0.3 folder and copied the resulting
C:\MinGW\msys\1.0\include\SDL2 folder and libSDL2.* files at
C:\MinGW\msys\1.0\lib folder into C:\Program Files\mingw-w64\x86_64-5.2.0-posix-seh-rt_v4-rev0\mingw64\x86_64-w64-mingw32\lib.
Your paths might be slightly different.

Reply to this email directly or view it on GitHub:
https://github.com/veandco/go-sdl2/issues/160#issuecomment-147049186

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


[quotemark: backtick] Incorrectly flags string literals in export line

Bug Report

TSLint version: 5.14.0
TypeScript version: Version 3.3.3333
Running TSLint via: Atom
Related issues: #4514

TypeScript code being linted
export * from "./some-module"

with tslint.json configuration:
{
    "rules": {
        "quotemark": "backtick"
    }
}

Actual behavior
The quotes get flagged (and changed to backticks if fix is enabled).
Expected behavior
The quotes should remain as double/single quotes, as typescript/ecma doesn't allow backticks here.

Here's another example:
Code being linted
const array: SomeType<string, "hello"> = []
const obj: {
	"kebab-case": string
} = {
	"kebab-case": "value"
}

Expected result of fix
const array: SomeType<string, "hello"> = []
const obj: {
	"kebab-case": string
} = {
	"kebab-case": `value`
//                    ~~~~~~~ [" should be `]
}

Actual result of fix
const array: SomeType<string, `hello`> = []
//                            ~~~~~~~ [" should be `]
const obj: {
	`kebab-case`: string
//      ~~~~~~~~~~~~ [" should be `]
} = {
	"kebab-case": "value"
//                    ~~~~~~~ This one is ignored, but should be flagged
}

Problem summary

The fixing/flagging here flags some things that when changed breaks typescript syntax and doesn't flag other instances where it should be flagged.
Typescript required that the string literal type passed to the generic type be single/double, but the implementation of the backtick rule does not make that distinction. Seems that node doesn't have a clear-cut type though to exclude it.
For the type definition, the kebab case property name has to remain single/double quotes, or typescript breaks as well. What is the associated node type there? Mucking in the code trying to PR for this, seems that the type definition property name here doesn't have a clean-cut node type either.
The string literal in the property value assignment is not flagged, but it should. Seems that looking at the parent node ("kebab-case": "value") gives you "PropertyAssignment" for both the property key and the property value, while the key should be ignored in this case, the value should not. How would one implement this part when they don't have their own node types?

Actually, I think I got something. PR soon.


show-whitespace isn't wrapped to next line properly

https://github.com/discord/discord-api-docs/pull/1396/files#diff-99b76a48d014c043f2f8804f6653ed82

There's also a little different problem happening when GitHub Dark is enabled but I'm not sure if this is something you want to fix as well:

This one is though. There's no easy way to show the whitespace without compromising the copy-paste.
Currently we just overlay the •→ symbols via :before pseudo-element with position: absolute; this can't support the regular inline line breaking.

A solution could be wrapping each whitespace in its own element. This feature is already set up to only act on the visible lines so it might handle the extra operations without slowing down (except when the user scrolls past a lot of files very quickly)

I'm trying this out now, I can't replicate that wrapping behavior at all in both Chrome and Firefox. The spaces never wrap:
With RG

Without RG

cc @notlmn


Suggestion: add Nostr URLs section and https redirects

You could add a Nostr URLs section in which you give a brief explanation of what nostr: handle is (NIP-05) and how to do https redirects.
I have a guide/tool here you can use if you want https://nostredirect.davidcoen.it.
Here the result:
https://snort.social/e/note1as34wa4h7q36can2lvsh5q898z0xgsc24up8yst8u9c9zw47avkswz530f and https://snort.social/e/note1wmzkd08jjlw62trxtctxelrueu82e5cvkfk04tyyga9kz8fp7c6qxhgruv

Will do! Thanks for the suggestion! 💜


Not compatible with Py3 or updated Quippy

glosim2 is not currently compatible with Python 3 or the most up-to-date version of Quippy. It would be helpful, at the minimum, to know what version of Quippy glosim2 has been tested for.

We can't get the GAP and GAP-filler packages now. The link "http://www.libatoms.org/gap/gap_download.html" missed.


Network usage is prohibited for themes

It appears that your theme uses network connections to load assets (e.g. fonts, icons, or images). This is prohibited by the official Obsidian developer policies because themes should function completely locally.
You can bundle an asset for local use by using data URLs. See this guide.
Please let us know if you have any questions. Any themes that use network connections will be removed from the official directory in the first week of January 2024.

The Obsidian team.

Hi @7368697661
We have noticed that you have not fixed this issue yet.
We have extended the deadline up to the 30th of february.
After that point, we will remove the theme from the community themes, if this issue is not fixed by then.


Consolidate lib/translations/fa_IR.js and fa_ir.js

Looks like you've got two translation files for the same language:

lib/translations/fa_IR.js
lib/translations/fa_ir.js

I'm using pickadate via ember-cli and bower/broccoli build system which gives me the following error on the latest pickadate version.
pickadate/lib/translations/fa_IR.js in <path>/tmp/funnel-dest_CDIUjl.tmp
pickadate/lib/translations/fa_ir.js in <path>/tmp/funnel-dest_CDIUjl.tmp
Remove one of the files and re-add it with matching capitalization.
We are strict about this to avoid divergent behavior between case-insensitive Mac/Windows and case-sensitive Linux.```

It looks like two identical commits in source history just different file casing https://github.com/amsul/pickadate.js/commit/8bf81ac381457fa13a214e063e2b8dd9ea0b1c13 https://github.com/amsul/pickadate.js/commit/3193dbf49783e7275aa077ca289323aed39e34d5

they are definitely the same, do you plan to fix this soon by removing one so that builds can run normally again?


Fix/27544 Incorrect Old Dot comment formatting when viewed on New Dot

Details

When viewing a report approved/submitted on Old Dot in New Dot, it was incorrectly formatted i.e. bolded, white, and separated on different lines.
This PR restores the grey color and regular font weight similar to other types of report actions and shows the approved/submitted report on one line.
Fixed Issues

$ https://github.com/Expensify/App/issues/27544
PROPOSAL: https://github.com/Expensify/App/issues/27544#issuecomment-1752142100
Tests

Go to www.expensify.com on either Mac Chrome or Mac Safari.
Select the email option and log into a test account as User A.
Hover over "Settings" in the left sidebar and then click on "Workspaces" (formerly policies).
Click on the green pill button at the top right that says "New Workspace".
Click on the button in the "Collect" card (middle option). A workspace/policy is now created.
Hover over "Settings" in the left sidebar, click on "Workspaces in the pop-up, and then scroll down to the workspace card with a green outline which should be the one you just created. If you don't have any other workspaces from before, there's no need to scroll down - you should see it right away.
Click on the workspace. Rename it to something like "Workspace from Old Dot", if you like, for better separation between it and workspaces created in New Dot.
Right next to the left sidebar should be a list of options. Click on "Members".
Click on the green pill button that says "Invite". Enter the email of another user (a separate test account you have access to i.e. User B) in the card that pops up and set their role to "Employee". A personal message isn't necessary, but you can add it if you wish. Click the green pill button that says "Invite" at the bottom right of the card when done. The other user's name and avatar should now show under "Workspace Members".
Right below the "Workspace Members" section is the "Approval Mode" section. Leave this as "Submit and Approve".
In an incognito browser, go to www.expensify.com and log in as User B using their email like in Step 2.
Hover over "Settings" in the left sidebar and then click on "Workspaces" in the options that appear. Click on the grey pill button that says "Make default" on the workspace you were just invited to as User B.
Click on "Reports" in the left sidebar and then click on the green pill button at the top right of the screen that says "New report".
Type a message in the composer at the bottom of the card that appears e.g. "Hello from the Old Dot workspace" and press Enter to send it.
In the browser Url, you'll see an object like {"pageReportID":8096248714236998,"keepCollection":true}. Copy the number after pageReportID.
Open a new browser window and go to www.staging.new.expensify.com if this PR has made it to staging or localhost:8082 for DEV if it hasn't (8082 is the currently used port number).
Log into an account as User A in New Dot.
In the browser Url, paste the number you just copied from Old Dot to navigate to the report. It should look something like this: staging.new.expensify.com/r/[the long number you copied goes here not surrounded by brackets].
Verify the message sent from Old Dot (www.expensify.com) by User B is present and formatted correctly e.g. like a regular chat message - white in color and regular font weight. If you're not sure what this looks like, click on the large green button on the bottom left of the screen -> start chat -> enter an email or select from list -> type something in the composer and then send.
Go back to the browser window where you're logged in as User B on Old Dot.
Click on the green pill button at the top left of the screen that says "Add Expenses" and then click on the next green pill button that says "New expense".
Enter any merchant and any amount in "Total" and then click on the green pill button that says "Save" on the card's bottom right area.
Click on the green pill button at the top left that says "Submit".  In the "To" section of the card that shows up, User A should be automatically selected. Select them from the dropdown list if it's available otherwise. Click on the green pill button that says "Send" at the bottom of the small card that popped up.
Verify that the text "You submitted this report to User A" shows above the composer in the card at the centre of the screen right after your first message as User B.
Go back to the New Dot (www.staging.new.expensify.com or localhost for DEV) window where you're logged in as User A viewing the report from Old Dot. You may need to refresh the page for the report to update.
Verify the text "User B submitted this report to you" is shown after the first message User B sent and is greyed out, has a regular font weight, and is all on one line.
Go back to Old Dot where you're logged in as User A and click on "Reports" in the left side bar.
Scroll down to the report created by User B and click on it. It's usually the last one and has the same workspace name as the one created in step 5. If you don't have any prior reports, it should show up as the first and only one.
Verify the chat history in the card is the same as the one you saw as User A in New Dot.
Click on the green pill button at the top left that says "Approve".
Verify the text "You final approved this report" appears just above the composer as the most recent message in the large card at the center of the screen.
Go back to New Dot where you logged in as User A viewing the report of the workspace created in Old Dot. You might need to refresh the page.
Verify the message "You final approved this report" is shown as the most recent message just above the composer and is greyed out, has a regular font weight, and is all in one line.
Send a message in the report while on New Dot as User A e.g. "This is a message from New Dot".
Verify the message you just sent is formatted correctly like in Step 19.
Click on the "+" sign next to the composer and then choose "Add attachment". Select an image from your device and upload it.
Verify the image you uploaded shows up.
If you don't see the conversation in the LHN in New Dot while on mobile devices or the desktop app, with the native app/browser open on mobile or the desktop app open, send a message in the workspace in New Dot from Mac Chrome.  You should see the conversation with the most recent message in the LHN (might need to scroll a bit if you have many previous chats/pinned chats).
Click on the conversation in the LHN and verify the messages are formatted appropriately.
On Mac Chrome, Mac Safari, and Mac Desktop, resize the browser to different sizes. On Android Chrome and iOS Safari, switch between portrait mode and landscape mode.
Verify all messages are formatted correctly as you've seen so thus far.

Please note:
If you hover anywhere over the messages "You final approved this report" or "User B submitted this report to you" in the Old Dot workspace while on New Dot, a tooltip with no Avatar is displayed. I believe this is a bug, and I can currently reproduce it in staging v1.3.90-0 and production. I'm yet to raise the bug in Slack.
You'll also notice that the copy to clipboard icon appears on hover, however, clicking it doesn't copy anything to the clipboard. Try doing so and pasting what you "copied" in the composer. This is also a potential bug I haven't raised in Slack yet.
In addition, trying to pay the expense using the "Pay elsewhere" option resulted in an error, although I believe this might be because I haven't set any payment methods on Old Dot.

Screenshot of payment error & bug

If in Android Web DEV (connected using your Mac's IP address and port number) you try long-pressing a message (in other chats too other than the workspace here), choose "Copy to clipboard" , and then try pasting the text in the composer, what you tried copying isn't pasted. I believe this is a bug. I haven't raised it in Slack yet.

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

Offline tests

After repeating the steps in "Tests" above, turn off your wifi or go to your avatar in the top left -> preferences -> toggle force offline.
Verify the text "You final approved this report" and "User B submitted this report to you" is greyed out, has a regular font weight, and is all in one line.
QA Steps

Same as above in Tests section.
Additional Steps (after performing steps in Tests section)

While on New Dot, send a message with a link included in the workspace created on Old Dot e.g. "Hello www.google.com".
Verify the link is blue and underlined.
Send a message in the same workspace formatted to use markdown e.g. bold, italic, strikethrough, a mix of markdown styles, etc.
Verify the appropriate markdown style is applied.
Hover over the messages you sent in Step 1 and 3, click on the pencil icon, and edit the message. Press "Enter" when done.
Verify the edited text is what you edited the message to, and the small "edited" label is applied.
Hover over the "You final approved this report" and "User B submitted this report to you" messages and click on one of the emojis.
Verify the emojis are shown below the messages.
Copy the link in the Url, sign out of New Dot, paste it in the browser, and then press Enter.
Log into your account.
Verify you're directed to the Old Dot workspace page, and everything looks the way you left it, including the "You final approved this report" and "User B submitted this report to you" messages being greyed out, having a regular font weight, and appearing on one line.

[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 approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[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 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] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[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(themeColors.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 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 author checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

~Caught this little bug currently on the latest main that would've literally rendered 'props.fragment.text' instead of the actual text.~
Found this piece of code that looked a bit suspicious on latest main. With the current implementation, it would literally render 'props.fragment.text`
https://github.com/Expensify/App/blob/d28247332f58bb0d4296b0eab49527771c03464c/src/pages/home/report/ReportActionItemFragment.js#L185
~I've fixed it like so in the PR.~
I've changed it to the following in my PR.
<Text>{props.fragment.text}</Text>

Seeing how the other cases are handled, it's possible this may have been intentional.
https://github.com/Expensify/App/blob/60576fe3d3a4c91cc33192c01ef213b59a336441/src/pages/home/report/ReportActionItemFragment.js#L170-L183
If at all any of you, @jjcoffee or @lakchote, feel this change isn't needed, I can just revert it. It could also save on some testing.

Just Android Native testing left to go, and the PR should be ready for review. Saved it for last because it can take a while to build.

Tried building from Android Studio, but that took a long time to even import the files, so I switched back to using VS Code.
Still waiting on the app to build on Android Native.

Android Native has built, but the font is still bolded, for some reason. The color is grey as expected.
Investigating.

It seems that's just how afontWeight: 'normal' looks on Android because when I tried changing it to fontWeight: 'bold', the text got bigger.

The styling guide says inline styles are forbidden, but I was a bit hesitant to create a helper method in styles.ts to add just two styles ReportActionItemFragment, so I figured I'd ask first.
An inline style has been applied over here, so I thought maybe things could work as is.
https://github.com/Expensify/App/blob/3380266055d37f7cc4521cf31649170597fc5fc0/src/components/MentionSuggestions.js#L107
In any case, should we go with the helper method, I could add this in the styles variable of styles.ts.
getMutedColorAndNormalFontWeight: (isApprovedOrSubmittedReportActionType: Boolean) => (isApprovedOrSubmittedReportActionType ? {color: theme.textSupporting, fontWeight: 'normal'} : {}),

And then replace the added style in ReportActionItemFragment with this:
style={[
    styles.chatItemMessageHeaderSender,
    props.isSingleLine ? styles.pre : styles.preWrap,
    styles.getMutedColorAndNormalFontWeight(_.contains([CONST.REPORT.ACTIONS.TYPE.APPROVED, CONST.REPORT.ACTIONS.TYPE.SUBMITTED], props.actionName)),
]}

If you hover anywhere over the messages "You final approved this report" or "User B submitted this report to you" in the Old Dot workspace while on New Dot, a tooltip with no Avatar is displayed.

@Victor-Nyagudi Regarding the above, to keep things consistent with other system messages, I actually think we don't want tooltips to display here. Is it an easy fix? I think technically it's out of scope for this issue, but it might as well be fixed if it's not too big a deal!

@jjcoffee The fragments we get from Old Dot are wrapped in UserDetailsTooltip.
I suspect this could be why the tooltip is shown on hover, though I haven't dived too deep into it.
https://github.com/Expensify/App/blob/e6af6e9df42b1394747cdd30c31085e65bdaa243/src/pages/home/report/ReportActionItemFragment.js#L155-L169
It's EOD for me (I can still reply on mobile), so I'll take a deeper look first thing tomorrow to try figure out why the tooltip is there in the first place and what we can potentially do about it.

Regarding the above, to keep things consistent with other system messages, I actually think we don't want tooltips to display here. Is it an easy fix? I think technically it's out of scope for this issue, but it might as well be fixed if it's not too big a deal!

@jjcoffee The tooltip was introduced to ReportActionItemFragment on March 4th, 2021 in this PR by @parasharrajat.

https://github.com/Expensify/App/pull/1632

The Expensify app looked very different back then, as you can see from the video in the attached PR, and a lot has happened since.
It's also possible the databases weren't synced or were separate at the time, so reports from Old Dot weren't making it to New Dot.
That being said, the tooltip appearing on messages from Old Dot could be a regression from the mentioned PR, unless maybe @parasharrajat could provide us with some more context on why this change was made.
In any case, I came up with two solutions - one a bit riskier than the other.

Option 1 (riskier)

Remove the UserDetailsTooltip wrapper so just the text is rendered.
// ...
case 'TEXT':
    return (
        <Text
            numberOfLines={props.isSingleLine ? 1 : undefined}
            style={[
                styles.chatItemMessageHeaderSender,
                props.isSingleLine ? styles.pre : styles.preWrap,
                props.isApprovedOrSubmittedReportActionType && {color: styles.colorMuted.color, fontWeight: 'normal'},
            ]}
        >
             {props.fragment.text}
        </Text>
);
// ...

Option 2

Conditionally render the tooltip based on whether the report action's type is APPROVED or SUBMITTED.
We'll do so by first passing a isApprovedOrSubmittedReportActionType prop to UserDetailsTooltip.
// ...
<UserDetailsTooltip
    accountID={props.accountID}
    delegateAccountID={props.delegateAccountID}
    icon={props.actorIcon}
    isApprovedOrSubmittedReportActionType={props.isApprovedOrSubmittedReportActionType} // <- Added
>
//...

We'll then use this prop in BaseUserDetailsTooltip.web.js to decide whether or not to surround UserDetailsTooltip's children with Toolitp.
// ...
return props.isApprovedOrSubmittedReportActionType ? (
    props.children
) : (
    <Tooltip
        shiftHorizontal={props.shiftHorizontal}
        renderTooltipContent={renderTooltipContent}
        renderTooltipContentKey={[userDisplayName, userLogin]}
        shouldHandleScroll
    >
        {props.children}
    </Tooltip>
);
// ...

Short demo after implementing option 2
https://github.com/Expensify/App/assets/79470910/f0d2c565-4ca4-4fc5-a20f-2e5a563b880b

Hi, @parasharrajat
When you approve or submit a report in a workspace in Old Dot and then view the report in New Dot, a tooltip with no avatar is shown when hovering over the message.
The message is also broken up into fragments, so a tooltip is shown when hovering over each fragment.
We were curious why reports of case: TEXT in ReportActionItemFragment were wrapped in UserDetailsTooltip in the first place.

@Victor-Nyagudi Usernames are displayed as a TEXT type fragment, that's why they're wrapped in the UserDetailsTooltip. I think we just want to conditionally wrap for anything that's not isApprovedOrSubmittedReportActionType.

@Victor-Nyagudi Whilst I appreciate the level of detail in your testing steps, I think it's a bit overkill. Can you try and reduce the number of steps so that it's closer to the original issue? The QA team will know how to do basic things like creating expense reports in oldDot, so it's not necessary to explain in so much detail.

Whilst I appreciate the level of detail in your testing steps, I think it's a bit overkill. Can you try and reduce the number of steps so that it's closer to the original https://github.com/Expensify/App/issues/27544?

@jjcoffee I've reduced the number of steps as much as possible without losing any clarity.
The original issue may have had fewer steps, but it wasn't very clear. It doesn't state anywhere that User B needs to submit a report while on Old Dot instead of New Dot. I only knew this was the case when someone asked for clarity in this Slack thread you created.
The issue also says to change the workspace approval mode to "Submit and close" while in order to approve a message, the approval mode needs to be "Submit and approve".
I wasn't the only one having trouble reproducing this issue, as you can see from the Slack thread, so I decided not to leave anything to chance with the QA team.
I hope this works.

I'm getting conflicting approaches to handling the tooltip issue.
@jjcoffee says:

I don't think it makes much sense to pass a flag to UserDetailsTooltip when we can just not wrap with it.

@parasharrajat says:

Now, that we are rendering more things with this fragment, let's move the tooltips to another place where are only rendering the actor name.

Which approach should I go with?
I also don't get you quite clearly, @parasharrajat. Where exactly should we move the tooltip to? Who is the actor?

@jjcoffee With regard to your comment on using !props.isHIdden conditional in ReportActionItemMessage, we could, in addition, also use isApprovedOrSubmittedReportAction to conditionally wrap the fragments in Text.
We'll need to reintroduce the renderReportActionItemFragment() method and store the fragments in a variable. Here's what the code will look like after the changes.
// ...
/**
    * Get a ReportActionItemFragment
    * @param {Object} fragment the current message fragment
    * @param {Number} index the current message fragment's index
    * @returns {Object} report action item fragment
*/
const renderReportActionItemFragment = (fragment, index) => (
    <ReportActionItemFragment
        key={`actionFragment-${props.action.reportActionID}-${index}`}
        fragment={fragment}
        iouMessage={iouMessage}
        isThreadParentMessage={ReportActionsUtils.isThreadParentMessage(props.action, props.reportID)}
        attachmentInfo={props.action.attachmentInfo}
        pendingAction={props.action.pendingAction}
        source={lodashGet(props.action, 'originalMessage.source')}
        accountID={props.action.actorAccountID}
        style={props.style}
        displayAsGroup={props.displayAsGroup}
        isApprovedOrSubmittedReportAction={isApprovedOrSubmittedReportAction}
    />
);

const reportActionItemFragments = _.map(messages, (fragment, index) => renderReportActionItemFragment(fragment, index));

return (
    <View style={[styles.chatItemMessage, !props.displayAsGroup && isAttachment ? styles.mt2 : {}, ...props.style]}>
        {!props.isHidden ? (
            // Approving or submitting reports in oldDot results in system messages made up of multiple fragments of `TEXT` type
            // which we need to wrap in `<Text>` to prevent them rendering on separate lines.

            isApprovedOrSubmittedReportAction ? (
                <Text>{reportActionItemFragments}</Text>
            ) : (
                 <>{reportActionItemFragments}</>
            )
       ) : (
           <Text style={[styles.textLabelSupporting, styles.lh20]}>{props.translate('moderation.flaggedContent')}</Text>
       )}
    </View>
);
// ...

Let me know if these changes work for you.

I think we just want to conditionally wrap for anything that's not isApprovedOrSubmittedReportActionType.

@jjcoffee This is what the code could look like with this approach.
// ...
case 'TEXT': {
    const messageFragment = (
        <Text
            numberOfLines={props.isSingleLine ? 1 : undefined}
            style={[styles.chatItemMessageHeaderSender, props.isSingleLine ? styles.pre : styles.preWrap, styles.approvedOrSubmittedMessage(props.isApprovedOrSubmittedReportAction)]}
        >
            {props.fragment.text}
        </Text>
    );

    return props.isApprovedOrSubmittedReportAction ? (
        messageFragment
    ) : (
        <UserDetailsTooltip
            accountID={props.accountID}
            delegateAccountID={props.delegateAccountID}
            icon={props.actorIcon}
        >
            {messageFragment}
       </UserDetailsTooltip>
    );
}
// ...

This also tests well.
Let me know if these changes work for you so we can keep this PR moving forward.

I wasn't quite satisfied with how things looked on Android Native, so I did some more digging to see if I could make some improvements.
I discovered the chatItemMessageHeader style gives the fragment text a fontFamily: font Family.EXP_NEUE_BOLD.
This is what caused the text to still appear in bold on Android.
I changed it to fontFamily: fontFamily.EXP_NEUE in this commit, , in addition to the font weight change for other platforms, and it tested well.
Here's how it looks on Android Native now.

I've also updated the screenshot in the PR checklist to reflect these changes.

@jjcoffee  With the changes I've made so far, the following should be addressed by now:

Reports from Old Dot not formatted properly
Tooltip appearing on Old Dot fragments
Text still appearing in bold on Android native

I think we're in a good spot right now, and all the tests still pass.
The only thing I see left is your opinion on this comment, but otherwise, I think we should be good to go.

@Victor-Nyagudi Sorry for the delay, I got swamped! In response to your question, it sounds safest to add the isApprovedOrSubmittedReportAction conditional so let's go with that.

@jjcoffee It appears the linter doesn't like nested ternary expressions as I suggested, but the docs also advise against storing the result of a ternary operation in a variable.
I'm open to suggestions on how we can implement the optional wrapping in Text using isApprovedOrSubmittedReportAction, but I'm also curious why you feel the current implementation isn't as safe.
Since ReportActionItemFragment always renders a Text component, it should be valid React syntax, and the child Text components will still align for the OD system messages.

Also, let me know what times/if you're available to collaborate in real-time on this PR so we can get it across the finish line.
I think we're close.

I'm open to suggestions on how we can implement the optional wrapping

Hmm did you consider just adding flex-direction: row conditionally on the parent View?
https://github.com/Expensify/App/blob/3db5ff4a1924156c748291d25eb9d774d82f879e/src/pages/home/report/ReportActionItemMessage.js#L51
I think it's just a bit messy to unnecessarily wrap with a <Text> when we don't need to, but if there's no other way we can stick to it, I guess!

Yes, I did explore styling the View with flexDirection: 'row' in my proposal, but this caused issues when the screen was  resized.

@Victor-Nyagudi Ah sorry, forgot about that! What about just display: inline then? The RTL issue seems to be present when using a <Text> wrapper (even if setting LTR styles on the children).

No worries.
Did you notice any issues when the fragments aren't wrapped in a <Text> component?
I'm investigating as we speak.

Looks like one of the checks failed.
I'll investigate first thing in the morning.

It appears the performance test started failing after I merged main here 8afe93c58094d548e2639276d723e961a80d789a before my most recent changes.
These tests also seem to be fairly new. Could we try running them again to see if they're still failing?
@jjcoffee We're also approaching the 9 business days mark, so this PR is now my top priority so we can get it merged before that point is reached.

@Victor-Nyagudi Just a heads up that it's about 3 hours until my EOD.

Got it, @jjcoffee . I'm available for all 3.

@Victor-Nyagudi Any luck with this?

Checkign right now.

@jjcoffee Aside from the shouldConvertToLTR bit, is there anything else that requires my attention?

@Victor-Nyagudi Nope happy with everything else!

Thank you for your patience and sticking with me through this one, @jjcoffee.

Great work and collaboration both of you @Victor-Nyagudi @jjcoffee  👍

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

🚀 Deployed to staging by https://github.com/lakchote in version: 1.3.96-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/puneetlath in version: 1.3.96-15 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/puneetlath in version: 1.3.97-7 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Need to get definition type

I am parsing a yaml file and trying to get definition type, but dont see a method retrieve the field:
Map<String, Model> definitions = swagger.getDefinitions();
I thought Model object has a method to return 'type' of the definition, but dont see a method.
Is there a way to retrieve this?
thanks,
amar

Hi, If I understand correctly you could use instance of in a conditional, once you know which instance I believe there is a type. https://github.com/swagger-api/swagger-core/blob/1.5/modules/swagger-models/src/main/java/io/swagger/models/ModelImpl.java

Thanks Grace! with the usage of ModelImpl, I can get type info


upgrade embeddings api to version 2 for  volcengine

https://www.volcengine.com/docs/82379/1263482
用户前往火山方舟的模型推理页面建立Endpoint，Endpoint为请求接入的入口，绑定接入方身份，限流，计费以及模型编排等信息，不再支持通过模型名+版本访问。
Thank you for contributing to LangChain!

[ ] PR title: "package: description"

Where "package" is whichever of langchain, community, core, experimental, etc. is being modified. Use "docs: ..."  for template changes, "infra: ..." for CI changes.
Example: "community: add foobar LLM"

[ ] PR message: Delete this entire checklist and replace with

Description: a description of the change
Issue: the issue # it fixes, if applicable
Dependencies: any dependencies required for this change
Twitter handle: if your PR gets announced, and you'd like a mention, we'll gladly shout you out!

[ ] Add tests and docs: If you're adding a new integration, please include

a test for the integration, preferably unit tests that do not rely on network access,
an example notebook showing its use. It lives in docs/docs/integrations directory.

[ ] Lint and test: Run make format, make lint and make test from the root of the package(s) you've modified. See contribution guidelines for more: https://python.langchain.com/docs/contributing/

Additional guidelines:

Make sure optional dependencies are imported within a function.
Please do not add dependencies to pyproject.toml files (even optional ones) unless they are required for unit tests.
Most PRs should not touch more than one package.
Changes should be backwards compatible.
If you are adding something to community, do not re-import it in langchain.

If no one reviews your PR within a few days, please @-mention one of baskaryan, efriis, eyurtsev, ccurme, vbarda, hwchase17.

Hi @mrichie, can you comment on the breaking change here and whether support for users on v1 is a concern?

closing for no response - let us know on the above and we can reopen!


Fails on Raspberry Pi (go1.5 linux/arm).

go get github.com/goxjs/gl
github.com/goxjs/gl
code/go/src/github.com/goxjs/gl/gl_opengles.go:24: ContextWatcher redeclared in this block
previous declaration at code/go/src/github.com/goxjs/gl/gl_opengl.go:17
code/go/src/github.com/goxjs/gl/gl_opengles.go:26: contextWatcher redeclared in this block
previous declaration at code/go/src/github.com/goxjs/gl/gl_opengl.go:19
code/go/src/github.com/goxjs/gl/gl_opengles.go:29: contextWatcher.OnDetach redeclared in this block
previous declaration at code/go/src/github.com/goxjs/gl/gl_opengl.go:33
code/go/src/github.com/goxjs/gl/gl_opengles.go:31: ActiveTexture redeclared in this block
previous declaration at code/go/src/github.com/goxjs/gl/gl_opengl.go:38
code/go/src/github.com/goxjs/gl/gl_opengles.go:35: AttachShader redeclared in this block
previous declaration at code/go/src/github.com/goxjs/gl/gl_opengl.go:45
code/go/src/github.com/goxjs/gl/gl_opengles.go:39: BindAttribLocation redeclared in this block
previous declaration at code/go/src/github.com/goxjs/gl/gl_opengl.go:53
code/go/src/github.com/goxjs/gl/gl_opengles.go:45: BindBuffer redeclared in this block
previous declaration at code/go/src/github.com/goxjs/gl/gl_opengl.go:60
code/go/src/github.com/goxjs/gl/gl_opengles.go:49: BindFramebuffer redeclared in this block
previous declaration at code/go/src/github.com/goxjs/gl/gl_opengl.go:67
code/go/src/github.com/goxjs/gl/gl_opengles.go:53: BindRenderbuffer redeclared in this block
previous declaration at code/go/src/github.com/goxjs/gl/gl_opengl.go:74
code/go/src/github.com/goxjs/gl/gl_opengles.go:57: BindTexture redeclared in this block
previous declaration at code/go/src/github.com/goxjs/gl/gl_opengl.go:81
code/go/src/github.com/goxjs/gl/gl_opengles.go:57: too many errors`

I just tested it, and I'm not seeing any problems with Go 1.5.1.
~ $ go get -u github.com/goxjs/gl
~ $

You should use -u flag to avoid stale dependencies causing trouble.
If that doesn't help, can you post more information about your system? What operating system, version? What does go version print? If you're on OS X, what version of Xcode or command line utilities do you have?

I’m using Go compiled from source on a raspberry pi.
go version output:
go version go1.5 linux/arm
uname -a output:
Linux raspberrypi 4.1.7-v7+ #817 SMP PREEMPT Sat Sep 19 15:32:00 BST 2015 armv7l GNU/Linux
From: Dmitri Shuralyov<EMAIL_ADDRESS>Sent: Monday, 16 November 2015 2:27 p.m.
To: goxjs/gl
Cc: Carl Menezes
Subject: Re: [gl] Go get fails on go 1.5 (#13)
I just tested it, and I'm not seeing any problems with Go 1.5.1.
~ $ go get -u github.com/goxjs/gl
~ $
You should use -u flag to avoid stale dependencies causing trouble.
If that doesn't help, can you post more information about your system? What operating system, version? What does go version print? If you're on OS X, what version of Xcode or command line utilities do you have?
—
Reply to this email directly or view it on GitHubhttps://github.com/goxjs/gl/issues/13#issuecomment-156886074.

I see. Raspberry Pi is the problem, not Go 1.5.
I don't think Raspberry Pi is supported at this time. It only supports OpenGL ES, not OpenGL like most normal Linux systems.
It should be possible to get it to work, but it'll take some work.
What would you like to use this package for? Have you already explored and compared alternatives?

I have my pi hooked up to a capacitive touch screen and am putting together a prototype UI using gxui, which pulls in a few packages from goxjs.
From: Dmitri Shuralyov<EMAIL_ADDRESS>Sent: Monday, 16 November 2015 2:37 p.m.
To: goxjs/gl
Cc: Carl Menezes
Subject: Re: [gl] Fails on Raspberry Pi (go1.5 linux/arm). (#13)
I see. Raspberry Pi is the problem, not Go 1.5.
I don't think Raspberry Pi is supported at this time. It only supports OpenGL ES, not OpenGL like most normal Linux systems.
It should be possible to get it to work, but it'll take some work.
What would you like to use this package for? Have you already explored and compared alternatives?
—
Reply to this email directly or view it on GitHubhttps://github.com/goxjs/gl/issues/13#issuecomment-156887162.

I see.
If you want gxui to work on Raspberry Pi, both this package and goxjs/glfw will need to support Raspberry Pi.
If another OpenGL bindings package supported Raspberry Pi, you could change gxui to use it for its rendering. However, I'm not aware of anything that supports Raspberry Pi. I haven't done the research though.
So the best way to make this work would be to add Raspberry Pi here, I think. Unless other people have better suggestions. Let me know if you're interested in doing this work; I can help with review.

Don't know anything about OpenGL ES so I won't volunteer just yet.

@carlTLR: could you solve your problem by any means? From what you know or read about goxjs/gl do you think it's worth to still put some effort in this project? Let me know why you think it's the perfect solution for the Pi and I will take a look into.
I don't know  goxjs/gl yet nor do I know OpenGL ES, but I have successfully ported or simply cross-compiled some projects to Raspian Jessie for the Raspberry Pi 2 Model B (ARMv7) inclusive Go 1.6 (standard binary download is ARMv6).
I could probably help to solve the issue, but I will only spend some time into this project if I can see a gain for the Raspberry Pi / Go community. I'm more interested in golang.org/x/mobile/gl.

Thanks for your potential interest here @petergloor.
I'll share about a relevant development since this issue was last updated. By now, there exist generated bindings for OpenGL ES in the go-gl/gl repo:
https://godoc.org/github.com/go-gl/gl/v3.1/gles2
They are bindings for OpenGL ES 3.1. I am not sure what version of OpenGL ES the Raspberry Pis support, but it might be a lower version. Still, it's possible to generate lower versions of OpenGL ES bindings via glow. See https://github.com/go-gl/gl/commit/d8e753c9b3953285d8ea142ca4e5dfea03ee760e for example.
The OpenGL ES bindings are a part of the equation, you'd still need GLFW support for Raspberry Pi, or something else that can create a window, OpenGL ES context, and take care of input, etc.

Hi, I have same problem with go version 1.6 linux arm on my Raspberry Pi.
I'd love to be able to use gxui on raspberry, it seems to be the best solution for my purposses. I don't know anything about Opengle ES, but I can help with testing.

Hi @Drahoslav7,

I'd love to be able to use gxui on raspberry

Unfortunately, that is not currently implemented. I'm not actively working on this because it's not a priority for me (and I don't have a Raspberry Pi), and I know the gxui project is not actively developed anymore either. I just want to help set your expectations right. Getting this issue resolved will require some work and testing, but I don't know of anyone actively working on this at this time, unfortunately.

Hi Peter,
No, I had other projects on my plate, so I proceeded with a platform that it worked with.
I think it is worth putting some effort into it because it enables a UI that looks the same on all platforms, but at a slightly higher level.
It would use OpenGL ES to do the heavy lifting anyway, so I think it would fit nicely with the work you’re doing on golang.org/x/mobile/gl.
Cheers,
Carl
From: Peter Gloor<EMAIL_ADDRESS>Sent: Thursday, 10 March 2016 3:00 a.m.
To: goxjs/gl
Cc: Carl Menezes
Subject: Re: [gl] Fails on Raspberry Pi (go1.5 linux/arm). (#13)
@carlTLRhttps://github.com/carlTLR: could you solve your problem by any means? From what you know or read about goxjs/gl do you think it's worth to still put some effort in this project? Let me know why you think it's the perfect solution for the Pi and I will take a look into.
I don't know goxjs/gl yet nor do I know OpenGL ES, but I have successfully ported or simply cross-compiled some projects to Raspian Jessie for the Raspberry Pi 2 Model B (ARMv7) inclusive Go 1.6 (standard binary download is ARMv6).
I could probably help to solve the issue, but I will only spend some time into this project if I can see a gain for the Raspberry Pi / Go community. I'm more interested in golang.org/x/mobile/gl.
—
Reply to this email directly or view it on GitHubhttps://github.com/goxjs/gl/issues/13#issuecomment-194308023.