Csrf state storage in session does not currently allow for more than one client of the same type

The session key variable needs to be namespaced by client name.
In our app we allow the user to configure any number of clients and there could for instance be 2 oidc clients displaying href links. When link is generated state gets stored so it can be checked when the redirect occurs back to app. Currently one state is clobbering the other and then only one link works.

Indeed, it's done properly for the OAuth protocol, but not for the OpenID Connect protocol. Would you mind submitting a PR for that? Thanks

@garpinc See: https://github.com/pac4j/pac4j/pull/1440

Awesome.. Unfortunately I didn’t have the time to create a PR but thanks.. What version will that hit? Guess it will be time for another  upgrade.. Hope it won’t be as painful this time.. 😊

From: LELEU Jérôme<EMAIL_ADDRESS>Sent: Wednesday, November 6, 2019 3:52:57 AM
To: pac4j/pac4j<EMAIL_ADDRESS>Cc: garpinc<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [pac4j/pac4j] Csrf state storage in session does not currently allow for more than one client of the same type (#1424)
@garpinchttps://github.com/garpinc See: #1440https://github.com/pac4j/pac4j/pull/1440
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/pac4j/pac4j/issues/1424?email_source=notifications&email_token=AAOW7RATQDWQCRC7AJGMQNLQSKAWTA5CNFSM4JBSVZSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDFYQ3Y#issuecomment-550209647, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAOW7RDY663MRPDQ73ZI3ATQSKAWTANCNFSM4JBSVZSA.

It will go in the future v4 release


fix key warnings for TabList, remove extranous id attributes

Coverage increased (+0.06%) to 44.478% when pulling a8892915312099afe012db6c4a7ea05a4574c9e0 on fix-key-warnings into 97938a61d3804d4dc9105319a89fe0e3f9f095dd on master.


One drive link for GQA200 split is dead!

Dear author, thank you for this very meaningful work! I want to reproduce this paper on GQA200 recently. However, It is a pity that the GQA200 link does not work anymore. I hope you can upload the three files of GQA200 again.  Please help me, thank you very much! I wish you success in your work and research!

You can check the GQA200 dataset here https://github.com/jkli1998/DRM/blob/main/DATASET.md.


login error

Description
not able to authenticate using GitHub login
Python, Logfire & OS Versions, related packages (not required)
Error
Whoops, something went wrong!

If the error persists, please contact us.

Logfire needs a primary verified email address from your GitHub.  Could you please check that in your GitHub profile?

We should improve the error message here.

This should be closed by platform#2421, I'll close this issue once that is merged.


Do not apply environment maps to unlit models. Fixes #374

Currently with a default env map, image env map, and PMREM'd env map currently:

With this patch:

Note that UnlitTest.glb is included (4kb) -- can reference the Khronos models if/when they land. The Astronaut is not unlit AFAICT (or, does not use the unlit extension), maybe should change the background-image demo describing it as such.

@jsantell since we have merged #375 , would you be willing to update this change to use the unlit sample from the Khronos samples so that we don't have to check the model into our repo?

@cdata

since we have merged #375 , would you be willing to update this change to use the unlit sample from the Khronos samples so that we don't have to check the model into our repo?

wouldn't that require needing to fetch all the models before being able to run tests? UnlitTest.glb is 4kb as well.
@donmccurdy

For some edge cases, obj.material could be an array of materials. We should probably avoid creating those in GLTFLoader at some point, but for now it's worth handling.

Any models that you know that do this to test?

since we have merged #375 , would you be willing to update this change to use the unlit sample from the Khronos samples so that we don't have to check the model into our repo?
wouldn't that require needing to fetch all the models before being able to run tests? UnlitTest.glb is 4kb as well.

Yes, and we do this (models are fetched as part of npm prepare, so they happen after npm install and npm ci).
In practice this is probably fine. We have set up Travis to cache the directory they are checked out to, and it doesn't seem to take much time. We also update in place if we detect that the models are already fetched.

FYI looks like UnlitTest.glb is still checked in

Using the Khronos sample models now, and handle when material is an array

It's a bit contrived, but here's an example that will result in mesh.material being an array. The model contains a single mesh with two primitives, and the primitives are identical except for using different materials.
Triangle.gltf.zip

Fixed the material array logic
Added Triangle.gltf for test case (added PBR values to see envmap), shook out some issues in our GLTFLoader wrapper
Remove UnlitTest.glb


As a property agent, I can add new listing with data

e.g. price, top, dates consolidate information for my clients
... so that I can consolidate information for my clients

Closed by https://github.com/AY2223S1-CS2103-W14-1/tp/pull/57


fix(types): adds queryKey generic to queryClient functions

This PR fixes the issue outlined in #2099.
I noticed that prefetchInfiniteQuery did not have any generic types. Was this done on purpose, and if not, need they be added?

Before I implement the rest of the tests, I just quickly wanted to check whether this is what you're looking for:
test('should not type-error with strict query key', async () => {
  type StrictQueryKey = ['strict', string];
  const key: StrictQueryKey = ['strict', queryKey()];

  const fetchFn: QueryFunction<'data', StrictQueryKey> = () => (
    Promise.resolve('data')
  );

  await expect(
    queryClient.fetchQuery(
      key,
      fetchFn,
    )
  ).resolves.toEqual('data');
})

yes, that looks good 👍

Alright, I've updated the PR. Note that I force pushed a commit over the first one. This one contains generic types for prefetchInfiniteQuery too.
The tests for the four functions have been added too.

:tada: This PR is included in version 3.13.5 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


flutter-actions/setup-flutter@v3 will attempt to install flutter_macos_arm64_3.27.0 on macos-13 (x86_64) runner when requested 3.27.0 flutter version

See details in my run: https://github.com/TarasMazepa/stax/actions/runs/12302169227/job/34334404957

Please temporary switch to uses: flutter-actions/setup-flutter@main, while i'm working on this issue.

Fixed, will schedule for release in v4.

Thanks for speedy reaction!


[Provisioner] Incorrect Azure shoot specification in networking section - NAT-Gateway public IPs got replaced

Description
The Provisioner duplicates Shoot spec structs here and this very old, outdated, invalid infrastructure config is used for serializing API response from Gardener cluster
Slack thread linked with this issue
Expected result
NAT-Gateway public IPs have not got replaced (static public IPs won't change after node pool change)
Actual result
NAT-Gateway public IPs got replaced
shoot--[name-for-shoot]-nat-gateway-2 -> shoot--[name-for-shoot]-nat-gateway-z2-ip
Possible way to reproduce

scaling up a shoot on Azure with public ip having to name similar to shoot--[name-for-shoot]-nat-gateway-2
NAT Gateway updates in Azure will be triggered
Observe the outcome, new public ip with naming like shoot--kyma--[name-for-shoot]-nat-gateway-z2-ip could have been created and associated with NAT Gateway (instead of the existing IP).

Troubleshooting
We need information about what is needed to change, and what is the new correct network infrastructure specification. Maybe @ebensom and SRE team have this information and could help here.

I would rather tríy to fix this and any possible future bugs similar like this by

either refactor the code to use Patch() on Shoot instead of Update() (which eliminates many potential problems)
or else rely on Gardener shoot API package instead of copied structs, so you get the API model updates by updating the gardener dependency.

The problem was resolved by merging the #2920 fix. If the problem occurs in the future feel free to reopen this issue.


add dependabot config to automate creating PRs for dependencies

Thanks, but I'm not sure I want automated PRs for dependencies bumps for the moment. I'm ok manually checking and bumping those on my own from time to time instead of getting regular notifications, and since I try to keep as few dependencies as possible, this is quite manageable by hand.


refactor(discord-utilities): switch to jdecked twemoji fork

Discord has switched to using Justine De Caires' (jdecked) Twemoji fork. Justine is an ex-Twitter employee who off the top of my head, used to work on Twemoji but got laid off the layoffs after Elon bought Twitter/X. Therefore, I thought it would be better suited to switch Sapphire's regex to using said fork.
Benefits of this change:

Adds support for Twemoji v15
Uses the same version as Discord
More updated than the original Twitter repo

Sources:

https://x.com/DiscordPreviews/status/1640809457423732763
Discord Previews mentioned the switch back on the 28th of March 2023.
https://github.com/discord/twemoji
Discord's Twemoji repo is a fork of Justine's fork.

Thank you for your review Vlad! The script was the first thing that I changed and ran it afterwards to update the actual code, since it gets overridden anyway.
https://github.com/sapphiredev/utilities/pull/797/files/8f4b64fe0bbd4194159acc88f0889f6141ce32e2#diff-ea04fd7ec7f44a64238cca194037a694d90415d43bb2f5a871379f49544fd852


--[Bugfix/Refactor]-PBR Skin Rendering Prep/Bugfixes.

Motivation and Context
This PR addresses the following issues/refactors :

Some common Drawable functionality shared between GenericDrawables (Phong/Flat) and PBRDrawables was promoted to the base Drawable class. This includes management for lights, shader keys, and skin data and handling, in order to reduce needless code duplication and also as pre-requisite work for the upcoming PBR Skin rendering support.
The PBR shaders were originally implemented to perform calculations in model space, while the Phong and Flat shaders work in Camera space (ModelView transform). This caused the PBR shader to perform many redundant matrix multiplications unnecessarily.  This distinction has been removed, and now PBR operates in Camera space, just like Phong and Flat shaders. This change is temporarily reverted until a reasonable solution to calculating IBL properly in camera space can be derived.
The PBR shaders were originally able to handle double-sided textures but this was disabled due to an issue with rendering artifacts being produced at edges. Since the PBR rewrite, this issue seems to have been addressed, and so this PR reactivates the ability to disable backface culling for double-sided textures.

How Has This Been Tested
All c++ and python tests pass locally

Types of changes

[x] Docs change / refactoring / dependency upgrade
[x] 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 change)

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.
[x] I have read the CONTRIBUTING document.
[x] I have completed my CLA (see CONTRIBUTING)
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

As discussed, there is a transform issue when projecting the environment map.
For reference, see the mirror in this video.
pbr_test-2023-10-02_11.50.20.mp4

I'm reverting the changes to the PBR shader using camera space vs world space until this issue with IBl being calculated in camera space can be addressed properly.


Allow optional file watcher (use gaze or chokidar)

This looks a bit crazy, but hear me out:

Every time you install chokidar, it rebuilds fsevents with node-gyp, it's a headache on windows and support for iojs is currently missing.

I know chokidar is fast on OS X, but gaze made some trade-off to achieve better compatibility across platforms, which I am fine with.

Hopefully when sane proves itself to be stable, we can use it as well (does look pretty promising.)

Decision is yours, I am using my branch at the moment because of iojs and I really don't want to touch node-gyp just for a file watcher...

I'd rather not deal with peer dependency situations. It's too easy for the user to miss the extra step.
Also, this was tested and working on io.js 1.3.0. The fsevents dependency is optional, so it should work fine even if that fails to build.

@Qard node-gyp step does not fail for me on iojs 1.4, it stuck forever, had to ctrl+c. You are right that it will work without fsevents, that put it back to gaze performance level (probably worse).
Either way, your call, I have no objection. If there is a way to mark fsevents as optional, even better.

Chokiday already marks fsevents as optional. If the install is stuck, there may be some other issue. I'll give it a try tomorrow and see if I can reproduce it.

I'm unable to reproduce a stuck install with any 1.4.x or 1.5.x version of io.js.


test(storage): add emulator README.md and add rest_only for bucket

This PR:

adds README.md for the new emulator.
adds rest_only for Bucket in order to support issue like #5491 .
refactor rest_only of Object and DataHolder, after this PR, if we have new REST only fields, we could add it to rest_only_fields and the emulator will extract that field automatically.
I accidentally call blob.patch in object_update ( which is fine because patch and update work similarly ). I change to blob.update in this PR. I also add tests for object'supdate and patch.
media_headers's in parse_multipart should be converted to lower.

Close #1037 ( It could be closed before but this PR is fine )
Part of #4751

This change is

Before fixing README.md, I think it is a good idea to implement the idea of #5462 . However, I find that sha256 is a little bit slow.
I am thinking of something like git diff current-commit master-branch-commit google/cloud/storage/emulator and if the diff isn't empty, we could use --cache_test_results=no.
It will also ensure that everytime we kick off a CI in a PR with the change in emulator, the tests caches will be invalidated ( with sha256, they will be invalidated only once ). But I can not find a way to get the master-branch-commit ( or current-destination-branch-commit ). WDYT ?

Before fixing README.md, I think it is a good idea to implement the idea of #5462 . However, I find that sha256 is a little bit slow.

How slow is slow?  Seconds, minutes?

I am thinking of something like git diff current-commit master-branch-commit google/cloud/storage/emulator and if the diff isn't empty, we could use --cache_test_results=no.

Where would you do that?  In storage/ci/run*?  Just confirming we would not be affecting any other cached result (say the Pub/Sub or Spanner integration tests).  Having said that, it seems like this would have some downsides:

It does not work if the target branch is not master
consider a PR that has changes in storage/emulator and outside it, the first build should get an uncached build, after a review, if the changes to do not affect the emulator, maybe we should not?

It will also ensure that everytime we kick off a CI in a PR with the change in emulator, the tests caches will be invalidated ( with sha256, they will be invalidated only once ).

That is a win for the sha256 approach in my book.  Do you see it as a downside?  Can you explain why?

But I can not find a way to get the master-branch-commit ( or current-destination-branch-commit ).

There is some code in ci/kokoro/docker/build-in-docker-cmake.sh that figures out what files changed in a PR.

WDYT ?

The code to figure PR changes is less robust than sha256 and has some downsides too.

The code to figure PR changes is less robust than sha256 and has some downsides too.

I am overthinking it. Let's go with the sha256.

s/gRPC API, JSON API/JSON API (both over REST and gRPC)/ we (Google) think of both as the same APIs, with different protocols, but the same APIs.

It is a little weird to me, because gRPC uses Protobuf. There 's nothing to do with JSON in gRPC. Maybe Protobuf API ?


how to set transparent proxy

i set ENV http_proxy and https_proxy of dockerfile. the docker can download , but there are also something wrong while build the nauta.
i can successfully run go build in another dockerfile . i have no idea why this one is failed . i am looking forward your reply
Step 31/33 : RUN  go build -o /loader main.go
---> Running in 003b4d5cae2e
github.com/NervanaSystems/carbon/applications/loader/vendor/github.com/docker/go-connections/sockets
vendor/github.com/docker/go-connections/sockets/sockets.go:35:26: dialer.DialContext undefined (type proxy.Dialer has no field or method DialContext)
vendor/github.com/docker/go-connections/sockets/sockets_unix.go:24:28: undefined: context

Hi @shixinlishixinli,
Yesterday we fixed this problem by https://github.com/IntelAI/nauta/commit/aa39db264985b21378856a8cd3fdbdf2654f904b
Please pull new changes from develop branch and try again.

thank you for your relpy . this bug is solved . but there are another bug while building the nauta.
fatal: [local]: FAILED! => {"changed": false, "msg": "Failed to connect to storage.googleapis.com at port 443: [Errno 101] Network is unreachable"}

i have successful build nauta.
firstly ,set" ENV https_proxy=https://<IP_ADDRESS>:912""ENV http_proxy=http://<IP_ADDRESS>:911" in all Dockerfile .
secondly,set "npm config set proxy http://username:password@server:port""npm config set https-proxy http://username:pawword@server:port"
then, set "RUN curl -s -x <IP_ADDRESS>:911 https://packages.cloud.google.com/apt/doc/apt-key.gpg | ap
t-key add -"
finally, try to download helm.tar.gz by myself and move it into correct path.


Adding dummy property in Account model for increase payload size in decryption - updating redisson version

Adding a property for using the dummy text
Dummy text added in resources/static/lorem.text -> only read once
Dummy text initially with 20 000 bytes

Changing redisson version to  3.15.0
Changing file size to 300K

Looks good.  We saw a 3 ms penalty for 300 KB cache entries, and a 9 ms penalty for 1 MB, in Azure Cache with our Gatling run simulating 200 concurrent users for an hour for each test run.  Thanks Cristhian for making these updates so we could gather this data quickly of the customer!


Bump version for publishing

Forgot to bump the version for hex

Hey @relistan, I need to merge this and release a new version because we need this in services that moved to Elixir 1.9 releases (which use the 0.5.x versions of env_var_provider). I changed it to 0.5.1 (instead of 0.6.0) so that we can have a simple mix deps.update in those services instead of doing a full dep update, hope that's fine!

Hey @relistan, I need to merge this and release a new version because we need this in services that moved to Elixir 1.9 releases (which use the 0.5.x versions of env_var_provider). I changed it to 0.5.1 (instead of 0.6.0) so that we can have a simple mix deps.update in those services instead of doing a full dep update, hope that's fine!

Sorry! Lost track of this PR. I had published from this branch apparently so this was released on hex already. :(


feat(form):  add warningOnly support for validation rule.

Some form item values may be considered abnormal but acceptable, for example, when an body height field has a value greater than 220cm. We want to mark this fields as warning fields. In this PR, add the warningOnly property to the validation rule will work.
The warningOnly property will display a warning feedback when the rule is unmatched, but calling the validate method will not throw an exception or resolve errors.
BTW, I'm not sure if ‘warningOnly’ is a good property name,  I am open to any other ideas and suggestions.
rules: {
  count: [
    {
      trigger: ["input", "blur"],
     // show warning while submit but `validate` method will not throw exception nor resolve errors.
      warningOnly: true,
      validator(_rule: FormItemRule, value: number) {
        if (value >= 220) {
          return new Error("Really?");
        }
        return true;
      },
    },
  ];
}

Codecov Report
Patch coverage: 81.13% and project coverage change: +0.26 :tada:

Comparison is base (2141156) 62.39% compared to head (521b138) 62.66%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #5020      +/-   ##
==========================================
+ Coverage   62.39%   62.66%   +0.26%
==========================================
  Files        1074     1074
  Lines       22586    22607      +21
  Branches     5928     5934       +6
==========================================
+ Hits        14093    14166      +73
+ Misses       6952     6890      -62
- Partials     1541     1551      +10

Impacted Files
Coverage Δ

src/form/src/FormItem.tsx
54.90% <79.48%> (+21.39%)
:arrow_up:

src/form/src/Form.tsx
76.00% <83.33%> (+35.57%)
:arrow_up:

src/form/src/utils.ts
68.36% <100.00%> (+1.70%)
:arrow_up:

... and 3 files with indirect coverage changes

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

这样 throw?: boolean = true ，仅提示时 throw: false ？

感觉还说得过去吧，那就合并了，没想到改动还不小


Add t_data_slice for data output

This PR begins to abstract the process of getting data out of perspective for use in visualizations/serialization. Right now, we create an intermediate array inside emscripten.cpp that contains the data extracted from the context. The end goal of the PR is to eliminate that intermediate structure—and the logic surrounding it—so as to make the data output API portable and trivial to implement in binding languages.
t_data_slice is a class that contains the underlying slice of data and associated metadata, which allows us to eventually remove the intermediate logic of get_data in emscripten.cpp.
Changes

Adds t_data_slice class
Adds is_column_only to context construction
Moves get_column_extent to independent class

Making the PR so we can discuss and get these changes into mainline before the branch gets too big; I've tried to benchmark these changes but the script seems to be broken on my machine and isn't benching properly.

Thanks for the PR!
This looks great!  I added one small fix for the windows build due to missing std::min on Windows.  Benchmarks show a ~10% improvement in JSON generation, which is quite a nice bonus!


Remove package to Microsoft.VCRedist.2015+

null
Microsoft Reviewers: Open in CodeFlow

Blocked by -

#81836
#81837
#81838
#81839
#81840
#81841
#81843


Use Machine Learning to Extract Information from Documents with Document Information Extraction Trial UI - Screenshot update for Account explorer

Tutorials: https://developers.sap.com/tutorials/cp-aibus-dox-booster-app.html
Hello,
Step 4.2
https://developers.sap.com/tutorials/cp-aibus-dox-booster-app.html#:~:text=From your global account page%2C choose the trial tile to access your subaccount.
-> From your global account page, choose the trial tile to access your subaccount.
Issue: the Account explorer screenshot has to be changed with the latest one. now the subaccount are listed in a different way.

Please update the same to avoid confusion.
Thanks,
Shubham
labels to be added:
prio - Mid-prio
Sprint Label: SCPTest-2204A
Landscape: trial2 (US)
Scenario label: SCPTest-docinfo

Image updated and PR sent (https://github.com/sap-tutorials/Tutorials/pull/18340).


[BUG] Not running

All it does is write changes to the rar file If I try to run it as admin or without the rar file with it, it still doesnt run

You have to extract the contents of the rar file.

Thanks


Typeahead functinality not found

I'm trying to implement typeahead over an xeditable input control following the docs, but I can't. It looks like the properties for the typeahead plugin are not present.
However, searching the code in the path angular-xeditable, I only find a few references to the word typeahead:
node-modules/angular-xeditable$ grep typeahead * -R
CHANGELOG.txt:[enh] add typeahead control (vitalets)
dist/css/xeditable.css:/* fix padding issue on typeahead */

I have installed xeditable via npm like this:
npm install angular-xeditable
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

+<EMAIL_ADDRESS>added 115 packages and updated 1 package in 20.458s

Do I need to install any other package?

Did you include angular-ui-bootstrap as specified by the documentation?

I didn't, but I have done now and still I can't find any references to e-uib-typeahead. Is it possible that the 'e-' prefix is added by the xeditable extension?

Can you post your code you are having an issue with or make a plunkr/jsfiddle so that I can better understand what your issue is?
To run typeahead, you have to include angular-ui-bootstrap and any properties of the bootstrap typeahead should be prefaced with e-.


About the quality

Thanks for your great repo!
I have tried this repo and the shape is well learnt, while the texture is not satisfactory, e.g. the ripe strawberry looks green. I am curious that is this method also about luck? Or something I have not set right?

@garychan22 Hi, I guess you can try longer epochs? Or you can wait for the official release.

Hi, you can try
"FLAGS.directional_text=True"
although the author mentions that it is not added when generating objects without directionality

@ashawkey i have tried larger epochs and the texture is better learnt but still looks far from the example provided in this repo.
@ChengYuhang99 thanks for your valuable suggestion! now the learnt textures are more like the examples provided in this repo!


improvements to the error handling when the Agent encounters errors

We show the Error lens group more often now, rather than hiding the error. We also automatically restart now if we discover that the Agent is down; there was a code path where the Agent wouldn't restart and Cody would just hang.
Test plan
We don't have an effective way to test generating errors until integration testing lands. For now, manual testing.

I've just done a pretty big merge with main, lots of conflicts. I'm going to close the PR and reopen it after I've tested a bit more.


Add type-checking for the throws type

This doesn't currently work. I don't know at the moment, how to
constrain the throws type to Swift.Error properly
As @dfsweeney said, this does not compile as of now.

Until this point it does compile and build the stdlib successfully

Although this commit technically compiles, it is not building the stdlib, as I'm getting lots of these failed assertions:
Assertion failed: (repr && "Cannot validate null TypeReprs!"), function resolveType, file lib/Sema/TypeCheckType.cpp, line 1872.

I suspect, that these errors are coming from a mistake, I made in the serialization or deserialization of function types and/or declarations.


feat: Add an anchor link to headings

Description
This pull request will add an anchor link to headings, it's a follow up of https://github.com/yearn/yearn-comms/pull/1511 to make it easier to grab the urls that point to a specific heading.
Now you can just a) hover the heading and "Copy Link Address";

or b) click on the header and copy the link from the address bar:

Fixed issue
Fixes https://github.com/yearn/yearn-comms/issues/1512
Type of change

[x] Feature

The build failing should be fixed with this https://github.com/yearn/yearn-comms/pull/1518, it would be good to get that merged first so that we can rebase it here @Majorfi


False positive: "Some branches listed in machete file do not exist: ..."

Reproduce steps:

create branch A
add branch A to the machete file
remove branch A locally with git branch -d A in the terminal / command line
open IntelliJ IDEA
remove branch A from the machete file
open the Git Machete window in IntelliJ ...
The "Some branches listed in machete file do not exist: ..." warning is displayed (which is a false positive)

However, after some time the warning does not appear anymore. It looks like the update in IDE is delayed.

numbered list would be more useful while describing steps 😉
step remove branch A from the machete file - you mean remove it from outside (terminal, not from IDE)?

step remove branch A from the machete file - you mean remove it from outside (terminal, not from IDE)?

I removed it using the IDE editor.

oh, interesting. and did you save the file (cmd+s/smth)? b/c if you didnt it can still be the same case (vfs)

No, I did not save it additionally. But it has been changed without saving in IDE from my side (checked using cat on this file from terminal).

ok, can it be saved on the computer file system but remain not saved in ide vfs? 😆 does the issue occur when you save the file from ide?

ok, can it be saved on the computer file system but remain not saved in ide vfs? 😆 does the issue occur when you save the file from ide?

Looks like a volatile bug. I tried to reproduce it now, but this time no false warning was displayed. 🤔

Ok, maybe this was a one-time error not worth working on.

Huh sounds like a race condition ☹ let's keep the issue around, but probably not worth starting work on immediately

Rel: https://github.com/VirtusLab/git-machete-intellij-plugin/issues/1227, this might be a proper fix, actually

Probably permanently solved by #1292 anyway... closing, to be reopened if ever re-occurs (doubtful)


Unable to use non-Gemini models through ChatVertexAI

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangChain.js documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I am sure that this is a bug in LangChain.js rather than my code.
[X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

Example Code

import { ChatVertexAI } from '@langchain/google-vertexai'

const chat = new ChatVertexAI({
    model: 'claude-3-opus@20240229',
    temperature: 0.0,
    maxOutputTokens: 1200,
})

const result = await chat.invoke('Tell me a story')

console.log(result)

Error Message and Stack Trace (if applicable)
Error: Unable to verify model params: {"lc":1,"type":"constructor","id":["langchain","chat_models","chat_integration","ChatVertexAI"],"kwargs":{"model":"claude-3-opus","temperature":0,"max_output_tokens":1200,"platform_type":"gcp"}}
    at validateModelParams (file:///Users/redacted/src/langchain-repro/node_modules/@langchain/google-common/dist/utils/common.js:100:19)
    at copyAndValidateModelParamsInto (file:///Users/redacted/src/langchain-repro/node_modules/@langchain/google-common/dist/utils/common.js:105:5)
    at new ChatGoogleBase (file:///Users/redacted/src/langchain-repro/node_modules/@langchain/google-common/dist/chat_models.js:191:9)
    at new ChatGoogle (file:///Users/redacted/src/langchain-repro/node_modules/@langchain/google-gauth/dist/chat_models.js:12:9)
    at new ChatVertexAI (file:///Users/redacted/src/langchain-repro/node_modules/@langchain/google-vertexai/dist/chat_models.js:10:9)
    at main (file:///Users/redacted/src/langchain-repro/test.js:5:22)
    at file:///Users/redacted/src/langchain-repro/test.js:22:1
    at ModuleJob.run (node:internal/modules/esm/module_job:218:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:329:24)
    at async loadESM (node:internal/process/esm_loader:28:7)

Description
I am trying to use ChatVertexAI with Anthropic Claude 3, but it seems this class only supports Gemini models and returns the above error message.
This appears to be a deliberate choice in the code:
https://github.com/langchain-ai/langchainjs/blob/b9d86b16bd0788144f8f27cf5d18960c43da49af/libs/langchain-google-common/src/utils/common.ts#L125-L132
I've verified that using Claude and Vertex AI and Anthropics Vertex SDK works fine:
import { AnthropicVertex } from '@anthropic-ai/vertex-sdk'

const projectId = 'my-project-id'
const region = 'us-east5'

// Goes through the standard `google-auth-library` flow.
const client = new AnthropicVertex({
    projectId,
    region,
})

async function main() {
    const result = await client.messages.create({
        model: 'claude-3-opus@20240229',
        max_tokens: 100,
        messages: [
            {
                role: 'user',
                content: 'Hey Claude!',
            },
        ],
    })
    console.log(JSON.stringify(result, null, 2))
}

main()

Output:
{
  "id": "msg_vrtx_01M1yGR5LiteHznRmyK2MaPG",
  "type": "message",
  "role": "assistant",
  "model": "claude-3-opus-20240229",
  "stop_sequence": null,
  "usage": {
    "input_tokens": 10,
    "output_tokens": 12
  },
  "content": [
    {
      "type": "text",
      "text": "Hello! How can I assist you today?"
    }
  ],
  "stop_reason": "end_turn"
}

System Info
    "@anthropic-ai/vertex-sdk": "^0.3.5",
    "@google-cloud/vertexai": "^1.1.0",
    "@langchain/google-vertexai": "^0.0.11",
    "langchain": "^0.1.35"

Platform: Mac
Node: 20.11.0

Similar to #2562
The issue is that Claude in Vertex AI is neither the same protocol as Gemini, nor quite the same as what is offered through Anthropic. So we need something that combines the two.
Do-able, but hasn't risen in priority.
My general thoughts about how to do this would be

The Anthropic library (and possibly the the @langchain/anthropic library) would be a build dependency and optional dependency to use it. Probably use this for the types, mostly, and parsing the results.
Add a utility class for anthropic.

The things that call baseMessageToContent, safeResponseToChatGeneration, and safeResponseToChatResult need to call their equivalents in this class

Changes in GoogleAIConnection

modelFamily() should add "claude" or something along those lines. And GoogleLLMModelFamily should be adjusted as well (probably).
buildUrlVertex() needs a change to handle non-Google models (possibly determine that based on the model family?)

Probably make a subclass of GoogleAIConnection or AbstractGoogleLLMConnection to handle the Claude layout.
But I haven't dug into the details.

The good news is that the authentication part is handled by default with the Connection classes.

+1, would be a very useful capability. Seems like it's already supported in BedrockChat, which is great.

+1, especially given the renewed interest in Claude 3.5 Sonnet

+1 for Claude 3.5 Sonnet

+1 another vote - Claude 3.5 support through Vertex AI is a key integration for companies on GCP to adopt Langchain.

I see the +1s - this is now next on my priority list!
I'm aiming to get #5835 into a stable state ASAP so it can be merged, since it contains some updates that would be useful for this effort as well. The approach I outlined above still mostly holds.
Sorry I couldn't get this in place for I/O Connect, but hope to have good news soon!.

Could you extend to other LLMs in the model garden such as Llama 3?

Yes... but...
In the Vertex AI Model Garden, Llama 3 requires you to deploy the model to an endpoint you control. And the details of the API are poorly documented. Claude has more full API support with "model-as-a-service" and a standard endpoint.
My current thinking is that I'll be able to provide direct support  through the current classes we have (ie - you'll just be able to specify a claude model and it will work), while you may need to do some work for other models in the Model Garden, including deploying an endpoint.

Hi @afirstenberg, Any update on the progress?  Do you have an ETA.
Many thanks!!

+1 is there any updates for this inquiry?

+1 to Claude 3.5 Sonnet via Vertex

It is still next on my list and in progress - but no updates to share.

Looks like I'll be adding this for Mistral at the same time.
https://cloud.google.com/blog/products/ai-machine-learning/codestral-and-mistral-large-v2-on-vertex-ai

Also Llama 3.1
https://console.cloud.google.com/vertex-ai/publishers/meta/model-garden/llama3-405b-instruct-maas

Also Llama 3.1
https://console.cloud.google.com/vertex-ai/publishers/meta/model-garden/llama3-405b-instruct-maas

FYI: For Llama 3.1 it works if you specify the endpoint
this.llm_meta = new ChatVertexAI({
      location: "us-central1",
      maxOutputTokens: 8192,
      endpoint: "us-central1-aiplatform.googleapis.com",
      temperature: 0,
      authOptions: {
        credentials: google_credentials,
        projectId: google_credentials.project_id,
      },
    });

Here's a temporary solution for using Anthropic with Vertex AI and LangChain.
You need to install the following additional packages:

google-auth-library
@anthropic-ai/vertex-sdk

Your usage should look like this:
import { GoogleAuth } from "google-auth-library";
import { ChatVertexAntropicAI } from "./ChatVertexAntropicAI";

const llm = new ChatVertexAntropicAI({
  googleAuth: new GoogleAuth({
    scopes: "https://www.googleapis.com/auth/cloud-platform",
    // your credentials
  }),
  region: <region>,
  projectId: <project_id>,
  model: "claude-3-5-sonnet@20240620",
});

// Streaming
const response = await llm
  .pipe(new StringOutputParser())
  .stream([["human", "Hi, who are you?"]]);
for await (const chunk of response) {
  console.log(chunk);
}

// None streaming
const response = await llm.invoke("Hi, who are you?");

And here is the implementation for ChatVertexAntropicAI.ts:
import {
  SimpleChatModel,
  type BaseChatModelParams,
} from "@langchain/core/language_models/chat_models";
import { CallbackManagerForLLMRun } from "@langchain/core/callbacks/manager";
import { AIMessageChunk, type BaseMessage } from "@langchain/core/messages";
import { ChatGenerationChunk } from "@langchain/core/outputs";
import { AnthropicVertex } from "@anthropic-ai/vertex-sdk";
import { GoogleAuth } from "google-auth-library";

export interface ChatVertexAntropicAIInput extends BaseChatModelParams {
  googleAuth: GoogleAuth;
  projectId: string;
  region: string;
  model: string;
  maxTokens?: number;
  temperature?: number;
}

export class ChatVertexAntropicAI extends SimpleChatModel {
  client: AnthropicVertex;
  model: string;
  maxTokens: number;
  temperature: number;

  constructor(fields: ChatVertexAntropicAIInput) {
    super(fields);
    this.model = fields.model;
    this.maxTokens = fields.maxTokens ?? 1000;
    this.temperature = fields.temperature ?? 0;
    this.client = new AnthropicVertex({
      googleAuth: fields.googleAuth,
      projectId: fields.projectId,
      region: fields.region,
    });
  }

  _llmType() {
    return "vertex-ai-custom";
  }

  lg_to_anthropic(messages: BaseMessage[]) {
    return messages.map((message) => {
      const isUser = message.lc_id.pop() === "HumanMessage";
      return {
        role: isUser ? "user" : "assistant",
        content: [
          {
            type: "text",
            text: message.content,
          },
        ],
      };
    }) as any;
  }

  async invoke_llm(messages: BaseMessage[]) {
    const response = await this.client.messages.create({
      model: this.model,
      max_tokens: this.maxTokens,
      temperature: this.temperature,
      messages: this.lg_to_anthropic(messages),
    });
    return response.content[0].type === "text" ? response.content[0].text : "";
  }

  async stream_llm(messages: BaseMessage[]) {
    const response = this.client.messages.stream({
      model: this.model,
      max_tokens: this.maxTokens,
      temperature: this.temperature,
      messages: this.lg_to_anthropic(messages),
    });
    return response;
  }

  async _call(
    messages: BaseMessage[],
    options: this["ParsedCallOptions"],
    runManager?: CallbackManagerForLLMRun
  ): Promise<string> {
    if (!messages.length) {
      throw new Error("No messages provided.");
    }
    // Pass `runManager?.getChild()` when invoking internal runnables to enable tracing
    // await subRunnable.invoke(params, runManager?.getChild());
    if (typeof messages[0].content !== "string") {
      throw new Error("Multimodal messages are not supported.");
    }

    return await this.invoke_llm(messages);
  }

  async *_streamResponseChunks(
    messages: BaseMessage[],
    options: this["ParsedCallOptions"],
    runManager?: CallbackManagerForLLMRun
  ): AsyncGenerator<ChatGenerationChunk> {
    if (!messages.length) {
      throw new Error("No messages provided.");
    }
    if (typeof messages[0].content !== "string") {
      throw new Error("Multimodal messages are not supported.");
    }
    // Pass `runManager?.getChild()` when invoking internal runnables to enable tracing
    // await subRunnable.invoke(params, runManager?.getChild());
    const response = await this.stream_llm(messages);
    for await (const chunk of response) {
      if (chunk.type === "content_block_delta") {
        const delta = chunk.delta.type === "text_delta" ? chunk.delta.text : "";
        yield new ChatGenerationChunk({
          message: new AIMessageChunk({
            content: delta,
          }),
          text: delta,
        });
        // Trigger the appropriate callback for new chunks
        await runManager?.handleLLMNewToken(delta);
      }
    }
  }
}

Important Note
This implementation is currently limited to handling text-only input and output. Other modalities and tool calling are not implemented.

@d-liya -- Nice approach, here is a more general one (should with tools, only tested with react):
import {BaseChatModel, type BaseChatModelParams, BindToolsInput} from "@langchain/core/language_models/chat_models";
import {AnthropicVertex} from "@anthropic-ai/vertex-sdk";
import {AIMessage, BaseMessage, BaseMessageChunk} from "@langchain/core/messages";
import {CallbackManagerForLLMRun} from "@langchain/core/callbacks/manager";
import {Runnable} from "@langchain/core/runnables";
import {BaseLanguageModelInput} from "@langchain/core/language_models/base";
import {convertToOpenAITool} from "@langchain/core/utils/function_calling";
import type {Tool as AnthropicTool} from<EMAIL_ADDRESS>

export interface ChatAnthropicVertexInput extends BaseChatModelParams {
    projectId: string;
    region: string;
    model: string;
    maxTokens?: number;
    temperature?: number;
    topP?: number;
    topK: number;
}

export function convertToAnthropicTool(tool: BindToolsInput): AnthropicTool {
    const formatted = convertToOpenAITool(tool).function;
    return {
        name: formatted.name,
        description: formatted.description,
        input_schema: formatted.parameters as AnthropicTool.InputSchema
    }
}

function formatMessagesAnthropic(messages: BaseMessage[]) {
    let system_message = null;
    let formatted_messages = [];

    for (let [i, message] of messages.entries()) {
        if (message._getType() === "system") {
            if (i !== 0) throw new Error("system message must be first");
            if (typeof message.content !== "string") throw new Error(`system message must be a string`);
            system_message = message.content;
            continue;
        }

        if (typeof message.content !== "string") {
            throw new Error("not implemented");
        } else if (message instanceof AIMessage) {
            throw new Error("not implemented");
        }
        const role = message._getType() === "human" ? "user" : "assistant";
        const content = message.content;

        formatted_messages.push({role, content});
    }
    return [system_message, formatted_messages];
}

export class ChatAnthropicVertex extends BaseChatModel<ChatAnthropicVertexInput> {
    client: AnthropicVertex;
    model: string;
    maxTokens: number;
    temperature: number;
    topP: number;
    topK: number;

    static lc_name(): string {
        return "ChatAnthropicVertex";
    }

    get lc_secrets(): { [key: string]: string } {
        return {
            "authOptions.credentials": "GOOGLE_VERTEX_AI_WEB_CREDENTIALS",
        };
    }

    _llmType(): string {
        return "vertex-ai-custom";
    }

    _identifyingParams(): Record<string, any> {
        return {
            modelName: this.model
        }
    }

    bindTools(tools: BindToolsInput[], kwargs?: Partial<ChatAnthropicVertexInput>): Runnable<BaseLanguageModelInput, BaseMessageChunk, ChatAnthropicVertexInput> {
        const formattedTools = tools.map(convertToAnthropicTool);
        return this.bind({
            tools: formattedTools,
            ...kwargs
        });
    }

    bind(kwargs: Partial<ChatAnthropicVertexInput>): Runnable<BaseLanguageModelInput, BaseMessageChunk, ChatAnthropicVertexInput> {
        console.log("HEREEEEEEE")
        console.log(kwargs)
        return super.bind(kwargs);
    }

    constructor(fields: ChatAnthropicVertexInput) {
        super(fields);
        this.model = fields.model;
        this.maxTokens = fields.maxTokens ?? 1024;
        this.temperature = fields.temperature ?? 0;
        this.topP = fields.topP ?? 0.95;
        this.topK = fields.topK ?? 40;
        this.client = new AnthropicVertex({
            projectId: fields.projectId,
            region: fields.region,
        });
    }

    async invokeLLM(messages: BaseMessage[], stop?: string[]) {
        const [systemMessage, formattedMessages] = formatMessagesAnthropic(messages);
        const response = await this.client.messages.create({
            model: this.model,
            max_tokens: this.maxTokens,
            temperature: this.temperature,
            top_p: this.topP,
            top_k: this.topK,
            messages: formattedMessages,
            ...systemMessage && {system: systemMessage},
            ...stop && {stop_sequences: stop}
        })
        return response.content[0].type === "text" ? response.content[0].text : "";
    }

    async _generate(
        messages: BaseMessage[],
        options: this["ParsedCallOptions"],
        runManager?: CallbackManagerForLLMRun
    ) {
        if (!messages.length) {
            throw new Error("message length cant be 0");
        }
        if (typeof messages[0].content !== "string") {
            throw new Error("cant work with multimodal messages yet");
        }
        const result = await this.invokeLLM(messages, options.stop);
        return {
            generations: [{message: new AIMessage(result), text: result}]
        }
    }
}

Is it possible to modify @langchain/anthropic to pass in a custom anthropic client?
import { expect, it } from 'vitest'
import { authenticate } from '../authenticate'
import { ChatAnthropic } from 'langchain-anthropic-edge'
import { AnthropicVertex } from '@anthropic-ai/vertex-sdk'
import { GoogleAuth } from 'google-auth-library'

it('Call Anthropic Vertex on nodejs', async () => {
  const client = new AnthropicVertex({
    region: import.meta.env.VITE_VERTEX_ANTROPIC_REGION,
    projectId: import.meta.env.VITE_VERTEX_ANTROPIC_PROJECTID,
    googleAuth: new GoogleAuth({
      credentials: {
        client_email: import.meta.env
          .VITE_VERTEX_ANTROPIC_GOOGLE_SA_CLIENT_EMAIL!,
        private_key: import.meta.env
          .VITE_VERTEX_ANTROPIC_GOOGLE_SA_PRIVATE_KEY!,
      },
      scopes: ['https://www.googleapis.com/auth/cloud-platform'],
    }),
  })
  const chat = new ChatAnthropic({
    apiKey: 'test',
    model: import.meta.env.VITE_VERTEX_ANTROPIC_MODEL,
    createClient: (() => client) as any, // custom anthropic client
  })
  const response = await chat.invoke([['human', 'Hello!']])
  console.log(response)
  expect(response).not.undefined
})

@rxliuli -- Yep, here is the diff we use to switch langchain js to AnthropicVertex.
diff --git<EMAIL_ADDRESS><EMAIL_ADDRESS>index 14bbafc..46047e1 100644
---<EMAIL_ADDRESS>+++<EMAIL_ADDRESS>@@ -1,4 +1,3 @@
-import { Anthropic } from "@anthropic-ai/sdk";
 import { AIMessageChunk } from "@langchain/core/messages";
 import { ChatGenerationChunk } from "@langchain/core/outputs";
 import { getEnvironmentVariable } from "@langchain/core/utils/env";
@@ -8,6 +7,7 @@ import { zodToJsonSchema } from "zod-to-json-schema";
 import { RunnablePassthrough, RunnableSequence, } from "@langchain/core/runnables";
 import { isZodSchema } from "@langchain/core/utils/types";
 import { isLangChainTool } from "@langchain/core/utils/function_calling";
+import { AnthropicVertex } from "@anthropic-ai/vertex-sdk";
 import { AnthropicToolsOutputParser } from "./output_parsers.js";
 import { extractToolCallChunk, handleToolChoice } from "./utils/tools.js";
 import { _formatMessagesForAnthropic } from "./utils/message_inputs.js";
@@ -422,6 +422,7 @@ export class ChatAnthropicMessages extends BaseChatModel {
         return {
             anthropicApiKey: "ANTHROPIC_API_KEY",
             apiKey: "ANTHROPIC_API_KEY",
+            "authOptions.credentials": "GOOGLE_VERTEX_AI_WEB_CREDENTIALS",
         };
     }
     get lc_aliases() {
@@ -537,11 +538,11 @@ export class ChatAnthropicMessages extends BaseChatModel {
         });
         this.anthropicApiKey =
             fields?.apiKey ??
-                fields?.anthropicApiKey ??
-                getEnvironmentVariable("ANTHROPIC_API_KEY");
-        if (!this.anthropicApiKey) {
-            throw new Error("Anthropic API key not found");
-        }
+            fields?.anthropicApiKey ??
+            getEnvironmentVariable("ANTHROPIC_API_KEY");
+        // if (!this.anthropicApiKey) {
+        //     throw new Error("Anthropic API key not found");
+        // }
         this.clientOptions = fields?.clientOptions ?? {};
         /** Keep anthropicApiKey for backwards compatibility */
         this.apiKey = this.anthropicApiKey;
@@ -755,10 +756,10 @@ export class ChatAnthropicMessages extends BaseChatModel {
     async createStreamWithRetry(request, options) {
         if (!this.streamingClient) {
             const options_ = this.apiUrl ? { baseURL: this.apiUrl } : undefined;
-            this.streamingClient = new Anthropic({
+            this.streamingClient = new AnthropicVertex({
                 ...this.clientOptions,
                 ...options_,
-                apiKey: this.apiKey,
+                // apiKey: this.apiKey,
                 // Prefer LangChain built-in retries
                 maxRetries: 0,
             });
@@ -774,13 +775,13 @@ export class ChatAnthropicMessages extends BaseChatModel {
     async completionWithRetry(request, options) {
         if (!this.batchClient) {
             const options = this.apiUrl ? { baseURL: this.apiUrl } : undefined;
-            if (!this.apiKey) {
-                throw new Error("Missing Anthropic API key.");
-            }
-            this.batchClient = new Anthropic({
+            // if (!this.apiKey) {
+            //     throw new Error("Missinxg Anthropic API key.");
+            // }
+            this.batchClient = new AnthropicVertex({
                 ...this.clientOptions,
                 ...options,
-                apiKey: this.apiKey,
+                // apiKey: this.apiKey,
                 maxRetries: 0,
             });
         }

I just made a similar modification to @langchain/anthropic. Do langchainjs want to accept this PR?
diff --git a/libs/langchain-anthropic/src/chat_models.ts b/libs/langchain-anthropic/src/chat_models.ts
index 11d683cba..bb32842a2 100644
--- a/libs/langchain-anthropic/src/chat_models.ts
+++ b/libs/langchain-anthropic/src/chat_models.ts
@@ -145,6 +145,8 @@ export interface AnthropicInput {
    * @default true
    */
   streamUsage?: boolean;
+
+  createClient?: (options: ClientOptions) => Anthropic
 }

 /**
@@ -604,13 +606,15 @@ export class ChatAnthropicMessages<
   clientOptions: ClientOptions;

   // Used for non-streaming requests
-  protected batchClient: Anthropic;
+  protected batchClient!: Anthropic;

   // Used for streaming requests
-  protected streamingClient: Anthropic;
+  protected streamingClient!: Anthropic;

   streamUsage = true;

+  createClient: (options: ClientOptions) => Anthropic;
+
   constructor(fields?: AnthropicInput & BaseChatModelParams) {
     super(fields ?? {});

@@ -644,6 +648,8 @@ export class ChatAnthropicMessages<

     this.streaming = fields?.streaming ?? false;
     this.streamUsage = fields?.streamUsage ?? this.streamUsage;
+
+    this.createClient = fields?.createClient ?? ((options: ClientOptions) => new Anthropic(options));
   }

   getLsParams(options: this["ParsedCallOptions"]): LangSmithParams {
@@ -908,7 +914,7 @@ export class ChatAnthropicMessages<
   ): Promise<Stream<AnthropicMessageStreamEvent>> {
     if (!this.streamingClient) {
       const options_ = this.apiUrl ? { baseURL: this.apiUrl } : undefined;
-      this.streamingClient = new Anthropic({
+      this.streamingClient = this.createClient({
         ...this.clientOptions,
         ...options_,
         apiKey: this.apiKey,
@@ -938,7 +944,7 @@ export class ChatAnthropicMessages<
       if (!this.apiKey) {
         throw new Error("Missing Anthropic API key.");
       }
-      this.batchClient = new Anthropic({
+      this.batchClient = this.createClient({
         ...this.clientOptions,
         ...options,
         apiKey: this.apiKey,


Matrix equality assertion

This pull request is not intended as a candidate for merge (yet).
I'm working on the matrix equality macro mentioned in #67. I added an example in the examples/ subfolder, which one can run with cargo run --example mismatched_f64_elements. See also the small number of tests currently included as well. The example looks like this:
#[macro_use]
extern crate rulinalg;

fn main() {
    // The purpose of this example is to demonstrate the type of errors generated
    // by `assert_matrix_eq!` when the comparison fails (which the below call will).
    let a = matrix![1.00, 2.00;
                    3.00, 4.00];
    let b = matrix![1.01, 2.00;
                    3.40, 4.00];
    assert_matrix_eq!(a, b, comp = abs, tol = 1e-8);
}

and it gives the following output:
     Running `target/debug/examples/mismatched_f64_elements`
thread 'main' panicked at '

Matrices X and Y have 2 mismatched element pairs. The mismatched elements are listed below, in the format
(row, col): x = x[[row, col]], y = y[[row, col]].

 (0, 0): x = 1, y = 1.01. Error: 0.010000000000000009
 (1, 0): x = 3, y = 3.4. Error: 0.3999999999999999

Comparison criterion: absolute difference, defined by
    |x - y| <= 0.00000001.

', examples/mismatched_f64_elements.rs:11
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Now, I'd like to give people the chance to give some input on how the macro should work. Comparing floating numbers is seriously hard. See for example this famous article. A preliminary conclusion is that there is no one-size-fits-all solution for comparing floating point numbers. Hence, it's impossible for us to have a default assert_matrix_eq!(a, b) macro that works in all cases. This is why I've opted for explicitly making the user choose which criterion to assert with (the comp = abs and tol = 1e-8 parameters).
However, I think we can provide a very conservative default assert_matrix_eq!(a, b) macro. I need to think a bit more on exactly how it's going to work, but I have the following in mind:

The default invocation is very strict and conservative.
The user simply writes assert_matrix_eq!(a, b) for his/her tests, and this might be fine if the numbers are very close to exactly equal.
However, in the case when the numbers are near but not sufficiently near, the macro will fail.
When the macro fails, the error message should explain the next steps the user should take (ideally by referring to a fleshed out part in the documentation on this) to ensure that he/she is using the correct comparison criteria.

The reasoning in step 4 again comes back to the fact that a one-size-fits-all comparison does not exist. I'm a bit inspired by how rustc guides users around compilation failures, by giving error messages that are truly helpful. Hopefully we can do the same for our users (and for our contributors).
Currently, the macro only supports absolute difference as a comparison criterion, but I want to at least support ULP-based comparison too (probably basing the default criterion on something involving ULP). I also need to write a lot more tests, as I hope this could form the cornerstone of future test assertions in rulinalg as a whole, as well as flesh out the documentation much more. Also, there should perhaps be an analogous assert_vector_eq macro?
Would really appreciate any opinions, questions, reservations or advice anyone might have!

This PR is really great! I really like how the macro works and the output is pretty much perfect (I think).
A few thoughts:

Should this macro capture a == b as well? I think not but wanted to put it out there as a potential comparison function.
The default implementation ideas you have sound really good. If this turns out to be a lot of work I think something less sophisticated would be acceptable. Maybe just default to abs and a low tolerance - but add a note in the panic message that the user can change these settings.
As you say I think we should add an assert_vector_eq macro too.

How do you plan to implement ULP?
Thanks for this!

@AtheMathmo,
I think it makes sense to introduce "comp = exact", perhaps? (with no tolerance) There are actually cases when you want to compare floating point numbers exactly, although you usually don't. Moreover, for integer types or boolean types, this certainly makes a lot of sense.
I have to figure out exactly how I'm going to support all the different types (bool, unsigned and signed integers, floating point at least... Complex numbers? Might leave complex numbers for a separate issue) in a decent manner. Ideally you want to be able to use the default macro with no additional arguments for all of them, which may require some sort of "specialization" through trait bounds or so, since the behavior for e.g. bools and floats must be different.
I also agree with the notion that I should not spend too much time on this, as it detracts from the time I could spend on improving arguably more important parts of the library. However, I think if I manage the number of features the macro should have in a sensible way, it makes sense to spend some time on making sure this works properly, in which case it should make future testing easier.
For ULP, I was initially planning to use the approx crate, however I realized that since it only gives you a boolean (i.e. "this is sufficiently close, or it is NOT sufficiently close within some ULP tolerance"), it doesn't give me enough information to give valuable feedback to the user. For example, I'd like to give the error in ULPs as well (corresponding to the "Error: 0.399..." in the output, but in ULPs instead). I looked at the implementation in approx, and it's fairly straightforward. I might use a similar approach but tweak it a little to better support our use case.
As I mentioned in one of the review comments though, I'm not sure if we actually want to expose ULPs to the user or just use it internally for the default macro invocation.

I was just wondering how much more you wanted to do on this? With the last couple of weeks I've lost track a little, sorry!

Just want to give an update on this. My current problem is that I have not found a way to reliably compute ULP differences given only a Float trait bound. I'd rather avoid having to implement a custom trait for floating point numbers, as it means exposing it for our users (in case they have their own floating point types).
There is Float::integer_decode(), but without knowing the actual width of each field, I can't think of a way to reliably compute the ULP difference. For example, I can use i.e. Float::max_value() to deduce this information, but only if I assume a IEEE754-type format, which the Float trait at least does not seem to guarantee, and it really sounds like a hack in any case.
I could also forego ULP for now, but providing only absolute difference is not so valuable in the general case. I could implement relative differences, but they are really not so intuitive to use. I need a bit more time to think on this, I think.

Actually, I think the custom trait way is the only reasonable way at the moment (short of sending pull requests for breaking changes into Num). That is, to provide our own Ulp trait, which would provide a ulp_diff() function and which we implement for f32, f64, and document how to implement it for custom types. Is this an acceptable solution to you?

I think the custom trait is a fine approach. It feels as though rulinalg isn't the natural place for such a trait but for now at least I see no issue with it.
I think it also worth opening an issue for discussion on the num crate. It would be good to at least find out if they would consider adding something like this. It wouldn't have to be a breaking change if it were introduced as a standalone trait initially.

@AtheMathmo,
all right! I'll look into it as soon as I have time. ULP does not fit perfectly into the current approach, as ULP does not make sense for certain situations (such as numbers of different signs or NaNs).
As for num, I think once we've landed on something here, we can consider opening an issue for num. I think in particular information about the size of the fields in integer_decode would be sufficient, and I think that could also make sense for them to include.

OK, so the three main classes of comparators are now implemented:

Exact comparison
Absolute difference comparison
ULP-based comparison

Apart from more documentation, much more and better tests and improved output (alignment, scientific notation, limit on number of disparities), the main feature that is lacking is a default comparison when you just call assert_matrix_eq!(x, y). Ideally I would want the following behavior, which is inspired by the AlmostEqualUlpsAndAbs function in this article:

If the scalar type is a floating point type:

If |x - y| <= C * epsilon, return true. Here C is a small constant, between 1 and 4 or so.
If ulp_diff(x, y) <= 4, return true, otherwise false. 4 somewhat arbitrarily chosen.

Else return true if x == y, otherwise false.

I'm not entirely sure how to get this type-conditional behavior though. I'll think about it until I have some more time to continue the implementation. In the meantime, do you have an idea, @AtheMathmo? (or anyone else, of course!)

I can't think of a clean way to get this kind of behaviour. I think it would involve creating a new trait for the default comparison, DefaultComparison or something. And for float primitives we do the comparison 1, and for all others comparison 2. The issue is that this would have to be public facing so that users can implement them on their own types. I'm also not sure if this would even fit well into the macro? I really haven't played with macros too much.

Yes, something along those lines is what I have been considering. Is it possible to use generic implementations with trait bounds to get the effect? I.e. we'd implement DefaultComparison for T where T: Float + Ulp and DefaultComparison for T: PartialEq<T> or so. Then it would stricly speaking have to be a public trait, but users do not need to implement it, and we can hide the docs. I'll try this out next time I work on it, but I'm not sure if Rust allows such overlapping trait bounds?

Sadly Rust does not allow this kind of generic trait implementaiton - I'm sure for good reason. This is the same reason why it is so difficult to implement lhs addition/subtraction operators (impl<T> Mul<Matrix<T>> for T where ... {})..
We'd have to do some macro magic to cover the primitives, and in the rare case that a user needs to implement this trait they'd be on their own I suppose.

I see. I suppose this is related to the lack of specialization?
In that case, I'm not sure if the required macro magic is worth the effort. I have two different suggestions:

The default assert_matrix_eq!(x, y) will only be valid for floating point types, and we require the trait bounds Float + Ulp. In this case we can use the absolute epsilon + ulp comparison I talked about earlier.
For other types, i.e. integers or whatever, the user explicitly needs to use assert_matrix_eq!(x, y, comp = exact) or similar. The downside here is that it may not be so clear to the user why the default comparison fails for i.e. an integer matrix.
The default trait uses exact comparison, and we can introduce an additional comp = float to use the combination of epsilon abs + ulp which I mentioned above. When the exact comparison fails, we can refer the user to the documentation for how to handle floating point types or other types of comparison in the error message.

Do any of these suggestions sound workable to you?

I think I prefer the sound of your second suggestion. I think if I happened on a new library I would expect an assert_eq. Having access to a nice default for floats (which presumably is well documented) should cover all of our bases.

@AtheMathmo, I completely agree. I also much prefer the second option, just wanted to get your thoughts on the matter. I'll try to implement it next time I sit down with this!

By the way, I just want to explain why I'm so insistent on having such a macro for rulinalg, and why I'm prioritizing it over other matters, such as the decomposition redesign.
I've recently been building some C++ code with Eigen for my thesis, and the lack of similar facilities for testing is a monumental pain in the ass. I rely heavily on unit tests and property-based testing (RapidCheck for C++), and especially debugging these tests when they fail has sometimes been very frustrating. My hope is that my providing a useful macro out of the box, we can prevent both ourselves and the users of rulinalg from similar pains.

I'm really happy that you are! I totally agree that it is necessary and hopefully an area where we can have good coverage from the start. It's going to make my life alone much, much easier.
If there is anything else that you think would have helped (or did help) with your current work please feel free to write up any related issues. My personal use of rulinalg is fairly narrow but I want to make it valuable to as many people as possible!

I absolutely don't want to derail you, but I've been meaning to write this up for a while and thought it might be interesting to you/relate to this work: #81 .
Perhaps later down the line this could provide some more functionality to this macro.

@AtheMathmo: yes, this is part of the reason I chose the current syntax, as it allows extension in the form of, i.e.:
// I just made the syntax here up on the spot, so might not be optimal
assert_matrix_eq!(x, y, metric = LNorm::Infinity, tol = 1e-6)

Had a quick look through, I think things are looking really good. The only issue I had was that I think the examples are a little unwieldy. I'm not against merging as-is, but would like to suggest the following ideas:

We move these example into a new folder: examples/macros/* or examples/equality/*?
We combine these into one example where the comparator is defined by a command line argument? So usage would look like: cargo run --example equality -- exact. And if no argument is given we use the default?

I prefer the second option. Let me know what you think.

@AtheMathmo: to tell you the truth, I made the examples mostly to guide my own development (i.e. so I can quickly see how the error messages look like in various scenarios). I think your suggestion is really good, but I would also be up for just outright removing the examples when I'm done.
I hope to have some time this weekend to work on it. I started on some more comprehensive documentation yesterday, but it's going to take me some time to test this properly. Since this is intended for use as the backbone of our future testing, it would be unfortunate if it contains bugs (although some might still slip through, of course).
This might actually be a good opportunity to try out QuickCheck. I recently started using the C++ library RapidCheck for some C++ code I'm developing, and it let me discover some truly obscure bugs in my mesh refinement algorithms that none of my (fairly detailed) unit tests covered. Would you mind if I add QuickCheck as a test dependency?

Yes I'd be really happy to see quickcheck added.
I'll leave the examples up to you. If adding a cmd line argument is too much effort I'd be fine with removing them completely. As you say the focus should be on making sure this is all correct :D

@AtheMathmo: one thing. I think it should be documented which traits bounds apply to the scalar types in the comparison. As it is, I've hidden the docs from the underlying types used in the macros because I don't really want to expose how it works. At the same time, this also hides the type information and consequently the trait bounds. I could of course explicitly write out the expected trait bounds. This seems like it could easily become out-of-sync. I'm not sure which is better: writing out the scalar types explicitly, or exposing the underlying types in the documentation? What's your opinion?

Also, I'm currently struggling with a complication. Because assert_matrix_eq!(x, y) calls a generic function in the body and passes &x and &y, it works fine if x and y are owned. However, if x and y are references, such as let ref x = matrix![];, then Rust cannot deref &&x to &x automatically, and the macro currently fails. I'm not sure how to solve this.
One way is to let it work like any Rust function, which means we'd have to write assert_matrix_eq!(&x, &y) if x and y are owned. I guess this is not a very big deal, but it IS more noise than necessary. On the other hand, it's explicit, like Rust should be. Thoughts?

Sorry for the late reply. I read this yesterday and couldn't figure out a good approach. Yours sounds fine to me - though I wonder if there is some way to have the macro accept both? For example the println! macro will accept wither x or &x.
Regardless I think your approach is totally fine for now and perhaps the best we can get.

@AtheMathmo: println! doesn't need to call generic functions, I guess. In any case, did you see my edit? I managed to find a workaround, so the macro actually works fine with both x and &x now.

@Andlon sorry I wasn't very clear, yes I saw the edit and I think it probably is the best approach :)

Slowly getting there... Remaining work:

[ ]  Some tests for elementwise_matrix_comparison to ascertain that it corrects the right elements as mismatching.
[ ] Better formatting, i.e. scientific notation and some alignment.
[ ] Need to implement analogous assert_vector_eq!
[ ] Put an upper bound on number of mismatches reported (i.e. 10-15) to prevent flooding the terminal.
[ ] Add examples of error reporting to documentation
[ ] Figure out which course to take with the documentation trait bound problem mentioned a few comments up. @AtheMathmo: got any input here?
[ ] (Optional/not sure if the best idea) Test exact output of error reporting? (Otherwise we have no automated tests which check that the textual output is as expected)

List looks long, but each point is not so much work. I'm done with writing most of the tests, which I expect was the most time consuming part.

@Andlon sorry I have been a little slow to respond here. Your list of remaining work looks good to me. I'm also unsure about testing the output - I feel like we will just have to update this test when we make any changes and it doesn't really lower the chance of any typos/bugs getting in.
As for the documentation issue, I'm not totally sure that I understand. But explicitly putting the trait bounds in the documentation sounds acceptable but not ideal. As you say I think it could get easily out of sync. It would be preferable if we could automatically show the required bounds from the compiler. If that isn't possible I think stating explicitly is fine. Personally I'd be inclined to reveal what's under the hood a little but I don't know exactly what you're concealing and your purpose for doing so. If you believe it is best hidden that may be the way to go.

About scientific notation. In order to use {:e} in format!, T needs to implement std::fmt::LowerExp. However, this is only implemented for f32 and f64, but our abs comparator needs to work for both integers and floating-point numbers. Without trait specialization, I am not sure how to deal with it. Unless anyone has an idea, I suggest we just leave it with the default output for now, and if it turns out to be too burdensome, we make an issue on it later.
Another question is whether or not absolute-valued comparisons are useful for integers. I suppose usually you are only interested in an exact result in the first place? I can't even think of a situation where I'd be interested in comparing matrices of integers with anything but exact equality. We might perhaps consider reserving abs for floating-point numbers only?

I think I saw that issue before, with LowerExp. It's a little odd that it isn't implemented for integers (though understandable). Let's leave it out for now then?
I agree that abs for integers seems a little unnecessary. If it is extra effort to include it let's leave it out too. If it is more effort to exclude it then we may as well keep it in?

While there are still things that could be improved upon, I consider this ready for review/merge now. Ideally the abs comparator would be constrained to LowerExp so we could get scientific notation (and consequently exclude integers from use), but I consider this a low priority feature, and I'd rather work on more pressing matters.
In the end, it turned out to be a rather large body of work. I spent a lot of time writing tests, but I find this necessary since the macros are intended to be used as core building blocks in writing future tests, and as such they arguably need to be the most reliable part of the library (though bugs may still have crept in).
I also suggest that we don't immediately rewrite existing tests using these macros, but rather encourage using it when writing new tests. In the long run, if we encounter no problems, we may perhaps start thinking about replacing our older tests.
@AtheMathmo: I'd like to start exploring some of my ideas for custom decomposition types (#40) next. I'd like to create a proposal for a redesign of the LU decomposition first. Do you think this is reasonable, or would you rather I work on something else? I'm up for suggestions. After the menial work of writing all these test cases for this macro, I need something more interesting, in any case, and I think the decomposition redesign would fit the bill.

Also, I experimented some with testing the output of panic_message(), but it was a nightmare to determine what was wrong if the test failed (i.e., there could be a space missing somewhere or similar). Hence, we currently have no tests to verify the actual textual output of the macros, but their behavior is quite well tested in all other aspects.

Glad to see this is ready for review! I'll try to find some time today to check it all over. The large number of tests makes me confident in this.

Ideally the abs comparator would be constrained to LowerExp so we could get scientific notation

I agree that this would probably be a nice change but can definitely wait a while.

I also suggest that we don't immediately rewrite existing tests using these macros, but rather encourage using it when writing new tests.

This sounds like a good idea. I'm pretty excited to make use of these but we should hold off until time makes us a little more confident.

I'd like to create a proposal for a redesign of the LU decomposition first.

Awesome! I'm really excited for this work to begin and I agree that LU is a good start. From memory I think where we left the discussion before I was happy with the ideas we had. I look forward to reading the proposal and hopefully seeing the subsequent work!

we currently have no tests to verify the actual textual output of the macros

This is absolutely fine. As I said above I'm not sure in practice that these would be the most valuable anyway. We'll just rely on users helping us to find any bugs in the output :).

FYI: I just added a small commit to the docs which details where the requisite trait bounds for matrix/vector elements can be found for each comparator.

Thanks for the comments! Will try to push up the changes tonight, if I have the time.

Forgot to address the custom comparators issue. Well, actually, it's currently not actually possible for a user to implement their own custom comparator that works with the macro. It wouldn't take too much extra work to support this, but that would be a bit of an extension that I'm not sure if it's worth it yet. May I perhaps suggest we try out the macro and see how well it works in practice, and then if we see the need for this, we can create an issue for improvements to the macro?

Take your time with the changes :).
I agree that leaving custom comparators out for now is fine. Maybe you can write up an issue detailing how we do this? I imagine it will be a while until (if) we get around to it but having it there ready may be valuable.
One other very minor thing that I forgot about before. Should the ElementwiseComparator compare function return a Result instead of an Option? I don't care much either way, but as we return an error maybe this is more natural?

Sure, I can write up an issue with remaining ideas for improvement after we've merged (if I somehow forget, feel free to remind me).
As for the compare function, I totally agree! It's a bit inverted as it is. Always felt wrong to me. I agree that a Result<(), ComparisonFailure> (pseudosyntax) would make more sense. Thanks :)

@AtheMathmo: I believe I have addressed your concerns with the latest commits! (I hope)
Turns out links are rather fragile things in rustdoc at the moment. They should all work now, but if you move structs around between modules they may easily break. I think they're worth having there though, because even if they don't work, they don't convey any less information than they weren't links in the first place. Hopefully, in the not-too-distant future rustdoc will have a better and more robust solution for linking in crate docs.

This all looks good to me! Will merge now.
Thanks for your hard work on this - I'm excited to make use of it!


Unable to run project on webOs 4.5 due to spread operator

Describe the bug
Trying to run a renative project on a LG WebOS 4.5 device fails due to the use of spread operator in the @react-navigation package.
To Reproduce
Steps to reproduce the behavior:

Run command 'rnv run -p webos -d'
See error in LG dev console

Expected behavior
The minified version of the module should be transpiled to not use spread since it's not supported on older devices.
Screenshots or copy&paste
bundle.js:12062 Uncaught SyntaxError: Unexpected token ...

Desktop (please complete the following information):

OS: Mac OSX 11.6.2 (M1)
Node Version v14.17.0
RNV Version 0.35.0 (also tried 0.34.0)

**Additional context
There are no clear instructions in the docs on how to customize the babel/webpack behavior when it comes to polyfill and transpiling of javascript for older devices.

Same issue here.

Same issue here, do you have a solution?

Same issue here, do you have found a solution?

Unfortunately not. I gave up on Renative and created my own react-project with LG build pipeline.

Is it possible to share you'r pipeline solution?

I can't reproduce it on rnv 1.0.0-rc.18. I've tested on macOS Ventura 13.6.4, Node v18.19.0. On both webOS devices:
➜  ~ ares-device-info --device webOS_TV_UN74003LB
modelName : 43UN74003LB
sdkVersion : 5.5.0
firmwareVersion : 04.50.56
boardType : K6LP_DVB_EU
otaId : HE_DTV_W20P_AFADABAA

➜  ~ ares-device-info --device webosTV
modelName : 32LK610BPLB
sdkVersion : 4.4.0
firmwareVersion : 05.50.15
boardType : M3_DVB_EU
otaId : HE_DTV_W18R_AFAAABAA
➜  ~


[Refactor] StreamInput, StreamOutput, Writeable to core library

This is a big commit as it refactors the StreamInput and StreamOutput core serialization and supporting classes from the server module to the core library such that it can be reused and overridden in cloud native and serverless applications. The majority of the changes in this commit are the import statements. Noteable refactors include:

StreamInput
StreamOutput
Writeable
NamedWriteable
NamedWriteableRegistry
Index
ShardId
BytesReference
ByteArray
BigArray
SecureString
Text
ParsingException
RestStatus

NOTE: The below dependency PRs reduce the surface area of this commit. However, it will still be a large commit as reducing to incremental commits adds a substantial intermediate "generics" framework that only serves to complicate the implementation. Thus we instead opt to solve the refactor in one swooping change.
relates #5910
depends on #7646
depends on #7780
depends on #8035

After merging #8035 it was easier to open a new PR #8157 instead of rebasing and dealing with merge conflicts. I will plan to close this PR once #8157 lands.

superseded by #8035


Tracking js-interface-ipfs-core and js-ipfs-http-client changes

In our conformance tests we are staying behind on the versions of $packages on the topic, because of originally the streaming multipart support. This is now worked on #224 and the proposed fix seems to handle most of the multipart parsing correctly.
Versions tested:
13c13
<     "interface-ipfs-core": "0.134.3",
---
>     "interface-ipfs-core": "0.137.0",
16c16
<     "ipfs-http-client": "^42.0.0"
---
>     "ipfs-http-client": "^44.3.0"

Overview of the issues:

~multipart without Content-Length (streamed bodies)~ #224
pubsub/pub has had an argument name change?
timeout options to number of APIs
wantlist cancellation (not supported at all)
pinning API use

I only tested upgrading both of the libraries because I was thinking about the multipart stuff which I already knew about. It might make sense to try if interface-ipfs-core: 0.137.0 works with the 42.0.0.

Oki this was dealt with:

https://github.com/rs-ipfs/rust-ipfs/pull/230
https://github.com/rs-ipfs/rust-ipfs/pull/231
https://github.com/rs-ipfs/rust-ipfs/pull/233
https://github.com/rs-ipfs/ipfs-rust-conformance/pull/27

We are now up to date pending the next release :)


flame_tiled Unable to load asset

What happened?
// My assets directory structure is like this.
/**
└── assets
    ├── images
    │   └── game
    │       └── image_name.png
    └── tiles
        └── tile_name.tmx
*/

# Already config flutter_gen in pubspec.yaml and get generated the file using this.
dart run build_runner build

// Update the game's prefix, because paths in generated file always started "assets/images" or "assets/tiles".
game.image.prefix = '';
// and loaded all images before use.
await game.images.loadAll(Assets.images.game.values.map((v) => v.keyName).toList());

// When I made a SpriteComponent, it worked.
class Water extends SpriteComponent with HasGameRef {
  @override
    Future<void> onLoad() async {
      final image =
          game.images.fromCache(Assets.images.game.imageName.keyName); // real path is "assets/images/game/image_name.png"
      sprite = Sprite(image);
    }
}

<!--In this file, the used image has a relative path-->
<image source="../images/game/image_name.png" width="64" height="64"/>

// But, when I use flame_tiled, it output error.
// [ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: Unable to load asset "../images/game/image_name.png"
await TiledComponent.load(
    Assets.tiles.tileName,
    Vector2.all(64),
    prefix: '',
);

But I found when I don't update game.image.prefix, it will be worked.
What do you expect?
When I update game.image.prefix, TiledComponent.load can be worked.
How can we reproduce this?
No response
What steps should take to fix this?
No response
Do have an example of where the bug occurs?
No response
Relevant log output
No response
Execute in a terminal and put output into the code block below
Output of: flutter doctor -v
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.16.9, on macOS 13.6.4 22G513 darwin-x64)
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 15.2)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2022.2)
[✓] VS Code (version 1.86.2)
[✓] Connected device (2 available)
[✓] Network resources

• No issues found!

Affected platforms
All
Other information
No response
Are you interested in working on a PR for this?

[ ] I want to work on this

If I'm not wrong the image paths in tilemaps are stored relative to the maps export location. Probably flame_tiled will have to modify the parsed paths based on the tilemaps location. The only problem is, prefix for images and tiles can be different and we wouldn't know the relation between them.

@howlwindy,
@ufrshubham is right. I faced this issue initially also. I tried to change the prefix to '' like you, but I realised this is not scalable. This is because Tiled exports supporting tileset .tsx files in this format: source="tiles.tsx" so it makes sense for Flame to add a prefix "assets/tiles" to your tilemap files since they will be in the same folder.
Technically you could still use add prefix: '', but you would have to change ALL your image sources to absolute paths:

I'll close this since there isn't any good way around it, if anyone come up with a good way we can re-open it again.

Just pass in the corresponding path for the images in the images parameter, and it should be the same as the prefix for TiledComponent. For example, like this:
tiledMap = await TiledComponent.load("ground.tmx", Vector2(210, 122),       prefix: "assets/tiles/build/",       images: Images(prefix: "assets/tiles/build/"));
In this code snippet, both the prefix for TiledComponent and the prefix for Images are set to "assets/tiles/build/". This ensures that when loading the tilemap and its associated images, Flame can correctly locate and load them from the specified directory in your project's asset folder.

Just pass in the corresponding path for the images in the images parameter, and it should be the same as the prefix for TiledComponent. For example, like this:
tiledMap = await TiledComponent.load(    "ground.tmx", Vector2(210, 122),       prefix: "assets/tiles/build/",       images: Images(prefix: "assets/tiles/build/") );
In this code snippet, both the prefix for TiledComponent and the prefix for Images are set to "assets/tiles/build/". This ensures that when loading the tilemap and its associated images, Flame can correctly locate and load them from the specified directory in your project's asset folder.


Download-URL-getting function in gee_interface should return single URL

In gee_interface.get_download_urls we will only ever get one URL in the list that is returned.
We should rename the function to be get_download_url, return the URL rather than a list, and modify satellite_data_analysis.process_coords accordingly (no longer need to loop over URLs.

Fixed in #101 as part of larger refactoring effort #91


[MAT-1042] Population Set Model

Porting CQM PopulationSet model for Bonnie on FHIR.

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- app/models/cqm/measure.rb  2

See the complete overview on Codacy