[vm/ffi] API: Pointer.asExternalTypedData as extension method

Split off https://github.com/dart-lang/sdk/issues/37773 to keep the CL sizes manageable.

These methods would be better exposed as extension methods:

Pointer.asExternalTypedData (but keep original)

  /// Creates an *external* typed data array backed by this pointer.
  ///
  /// The typed data array returned is only valid for as long as the backing
  /// [Pointer]. Accessing any element of the type data array after this
  /// [Pointer] has been [Pointer.free()]d will cause undefined behavior.
  ///
  /// Since [Pointer]s do not know their length, the size of the typed data is
  /// controlled by `count`, in units of the size of the native type for this
  /// [Pointer] (similarly to [Pointer.allocate]).
  ///
  /// The kind of TypedData produced depends on the native type:
  ///
  ///   Pointer<Int8> -> Int8List
  ///   Pointer<Uint8> -> Uint8List
  ///   etc. up to Int64/Uint64
  ///   Pointer<IntPtr> -> Int32List/Int64List depending on platform word size
  ///   Pointer<Float> -> Float32List
  ///   Pointer<Double> -> Float64List
  ///
  /// Creation of a [Uint8ClampedList] is not supported. Creation of a typed
  /// data from a [Pointer] to any other native type is not supported.
  ///
  /// The pointer must be aligned to a multiple of the native type's size.
  //
  // TODO(37773): Use extension methods to articulate more precise return types.
  // We should still keep this member though as a generic way to access a
  // Pointer of unknown type.
  external TypedData asExternalTypedData({int count: 1});

@sjindel-google how did you envision this? Instance methods shadow extension methods.

We would change the name of the instance method to asExternalTypedDataDynamic or such.

(1) Using extension methods and a generic method:

pro: precise return type.
con: API pollution with both the precise and the dynamic method.
con: dynamic method has imprecise receiver type, throws on non-integer type arguments.

(2) Using only extension methods:

pro: precise return type.
pro: precise receiver type.
pro: only one (extension) method (per Pointer type argument) in the API.
con: users (or package:ffi) have to write the generic one by hand if they want it.

(3) Using only generic method (current situation):

pro: only one method in API.
con: imprecise return type.
con: imprecise receiver type, throws on non-integer type arguments.

@sjindel-google I don't like the API pollution of option 1.
I think option 2 is a better option.

I'm in favor or #1 or #3. The ability to manipulate a pointer generically is one of the advantages of asExternalTypedData.

I'm fine with option 3 as well, keeping the return type generic.
We should still move it to an extension method on Pointer<_NativeInteger> so that the receiver type is precise.

Could you elaborate on your concern with two versions of asExternalTypedData from solution #1?

Option 1:
final Pointer<Int8> p = fromSomewhere();
final td = p.// x

x: Here we would have two methods with exactly the same functionality with slightly different names, but one with a more precise return type. I think that is confusing from a public API point of view.
Option 3b:
If a user wants the more precise return type, (s)he can always write:
final Pointer<Int8> p = fromSomewhere();
final Int8List td = p.asExternalTypedData();

Or option 2:
If the user wants to have a generic one, (s)he can always write a wrapper.
Both option 3b and 2 do not confuse/penalize the user that wants no generic version or no precise return type.

x: Here we would have two methods with exactly the same functionality with slightly different names, but one with a more precise return type. I think that is confusing from a public API point of view.

But, they don't have the exact same functionality. One is slower but can be called on a generic pointer. If the function is named like asExternalTypedDataDynamic, I don't see how that's confusing.

/cc @lrhn @mkustermann

I'd make the count argument positional instead of named.
Providing an Int8List (or any typed-data view) means that you can extract its ByteBuffer buffer and then view it as, e.g., a Uint32List (maybe subject to alignment?).
Consider whether you actually want to support this. If so, this is fine. If not, maybe don't make it return an Int8List, just a List<int> which happens to truncate on store. (Do not make it an Int8List which throws if you extract the buffer, or give a buffer which throws on any of the asUintXList() methods).
Going through the buffer seems like the only way to get, say, a Uint8ClampedList, unless you add an extra method to Pointer<Uint8>.
Alternatively, you can provide a function to go directly to the buffer:
Pointer<Int8> p = fromSomewhere();
ByteBuffer buffer = p.asExternalTypedDataBuffer(count); // count * Int8.size bytes of buffer.
Int8List list = buffer.asInt8List();
// perhaps with shorthand:
Int8List alsoList = p.asExternalTypedDataList(count); // count elements.

The ability to access the byte buffer and cast it (provided alignment is correct, which is checked) is part of the feature.
I think the question is about how to make the return type more specific by turning asExternalTypedData into an extension method.

As discussed offline, we will add extension methods only to the types which support external type data, and we can add a generic version later.

Yes, option 2. And we change the name to asTypedList, instead of asExternalTypedData.
extension on Pointer<Int8> {
  Int8List asTypedList(int elements);
}

extension on Pointer<Int16> {
  Int16List asTypedList(int elements);
}

// etc

This has landed.
The old method still needs to be removed, but that is part of https://github.com/dart-lang/sdk/issues/38860.


on_save_checkpoint callbacks runs in rank zero only

🐛 Bug
If any callback implements on_save_checkpoint, then that function runs only in the rank zero worker. I think this is suboptimal as you might want to do some communication across workers before saving state.
The lineage of calls here is:

model checkpoint callback's on_validation_end is decorated with rank_zero_only
this calls the checkpoint callback's _save_model
which calls it's save_function
the save_function is trainer.save_checkpoint
save_checkpoint in checkpoint_connector calls dump_checkpoint
dump_checkpoint calls trainer.on_save_checkpoint()
trainer on_save_checkpoint() calls any callback implementing on_save_checkpoint

I think this could be avoided with more judicious usage of rank_zero_only. the main benefit of rank_zero_only in the model checkpoint callback to avoid redundant file I/O. For saving the checkpoint, that is taken care of by this check.
Other file I/O in the model checkpoint callback could be similarly guarded, and we should remove the decorator from on_validation_end

with this thread i wanted to raise awareness of a limitation in the callback API here and a proposed workaround. if the code complexity isn't palatable, then we should document the limitations of the API.
making the implementation in on_validation_epoch_end have some more checks for trainer.is_global_zero rather than relying on the catch all decorator isn't so bad.  we're still able to apply the rank_zero_only decorator to smaller functions like _del_model
removing the decorator from on_validation_epoch_end also means we should remove the decorator from on_pretrain_routine_start because there is state set in on_pretrain_routine_start that is later read in on_validation_epoch_end. if on_pretrain_routine_start runs on rank zero only, then there are uninitialized fields when on_validation_epoch_end runs in non-zero ranks.
it's also unclear what we need to do for the model checkpoint's own definitions of on_save_checkpoint.
do all callbacks implementing on_save_checkpoint now need to check for trainer.is_global_zero? is that a dealbreaker?

@williamFalcon PTAL

#3688 finished this


Feature: Add remark_call extrinsic to pallet-utilities

Is there an existing issue?

[X] I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

[X] This is not a support question.

Motivation
We are in a situation where we want to tie some calls to some specific value/hash. There is a pallet-remark, but this only allows storing marks, without any relation to a call.
Using a batch, we could get that association. Supposing we want to tie ExtrinsicA to MarkA, we could do something like batch(ExtrinsicA, pallet_remark::store(MarkA)). Nevertheless, a possible indexer (i.e. Subscan) would need to inspect all extrinsic nested in batches in order to get the associations between the mark and the calls. We would want a fast solution to identify such relations.
Request
We need a more powerful extrinsic that allows us to remark a call. Something like:
fn remark_call(origin, call: RuntimeCall, remark: Remark) {
    call.dispatch()
    dispatch_event(remark)
}

This call should not be nested by batches to avoid an indexer going through all calls of a batch. An indexer would only need to identify those remark_call extrinsic at the top level.
Solution
We think we can add that remark_call to pallet-utilities, ensuring the batching method does not contain such extrinsic.
Are you willing to help with this request?
Yes!

Nevertheless, a possible indexer (i.e. Subscan) would need to inspect all extrinsic nested in batches in order to get the associations between the mark and the calls. We would want a fast solution to identify such relations.

What is the problem of this? You only need to inspect the batches that emitted a remark(Mark*) event and can ignore the other ones. It wont get faster than this (maybe write it in Rust 😆).

This call should not be nested by batches to avoid an indexer going through all calls of a batch. An indexer would only need to identify those remark_call extrinsic at the top level.

I dont think it makes sense to change the runtime to optimize for such nieche off-chain use-cases. You could already look only at top-level remarks.

Make sense, probably too niche a use case. Thanks for the suggestions


included 5.6.0-14

Hey dear maintainers, I wanted to bring node-14 to included images, unfortunately current folder structure doesn't allow to do it easily. As a result I created this WIP PR, please help me with fixing it.
of course I can create my own image based on yours with node-14, but it might be useful for others

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

I think we want to keep the Node version the same in the included Docker image, as the bundled Node version inside Electron as in https://github.com/cypress-io/cypress-docker-images/issues/400 So I would encourage you to build own Docker image with pre-installed Cypress.


Can't get mod to work

the following error occurs when anyone of my friends tries to join whilst lethallib is in their files, however, without lethallib the lategameupgrades doesn't work at all.
Lastly, I will note that all other mods and multiplayer works just fine without lethallib although the lategame upgrades won't be in game at all.

So is the problem with LethalLib or LategameUpgrades?
If it's with LethalLib, you will need to report this to them with proper logs (as in posting the log file that is generated from the console).
If it's with LategameUpgrades spefically, I can't do anything with what you gave me because again, like you said, this mod can't load if you do not have LethalLib installed.
Note that you should mention what version of the game you're playing when reporting an issue as it helps in finding the causes of the problem.

I've run into the same issue, can't be sure if it is from the lethalLib or the mod itself, but the error is the same. We've tested with different versions of lethalLib and nothing was working. Also I am playing in v50

Same issue, using Lategame and LethalLib 0.15.1, and the latest thunderstore updates for the other dependencies. I also removed all other mods keeping only Lategame and its dependencies to see if there was mod incompatibility but it still didn't work. I used my main account and my second account with exactly the same files and configs. Using V50 Lethal Company.

Can each provide logs to understand if somethings wrong with the mod?
I understand you're having an issue but I can't help you right now as I can boot up the game just fine with just the mod and necessary dependencies.

I'll post the logs later when I can (around 7 hours). Also the game boots up perfectly fine solo. Other players that join will get the black screen and fog effect with or without the exact same config files, even with no other mods installed and dependencies up to date.


Zoom/scaling

For qutebrowser I get this:

Not sure if there's much that can be done to actually improve the output, but I think a way to zoom in (or to enforce more spacing between nodes?) would help a lot.

As a short term fix, try zooming out in your browser and then refreshing the page.

But yes, I agree, I need to fix the scaling issues.


Error Malformed line 1 in source list /etc/apt/sources.list.d/microsoft-prod.list (type)

Same problem as
https://github.com/MicrosoftDocs/azure-docs/issues/59910
Running Ubuntu 20.4 LTS and trying to follow the guide. It's not possible to follow along with the guide as one gets
:~$ sudo apt-get install gpg
E: Malformed line 1 in source list /etc/apt/sources.list.d/microsoft-prod.list (type)
E: The list of sources could not be read.
E: Malformed line 1 in source list /etc/apt/sources.list.d/microsoft-prod.list (type)
E: The list of sources could not be read.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e2197cba-30ac-1749-e25a-6f39c9ee9d20
Version Independent ID: bcd14f13-ab59-8e69-5c83-42fee6e51f87
Content: Deploy Microsoft Defender ATP for Linux manually - Windows security
Content Source: windows/security/threat-protection/microsoft-defender-atp/linux-install-manually.md
Product: m365-security
Technology: mde
GitHub Login: @Dansimp
Microsoft Alias: dansimp

@konstruktoid : Maybe you would like to take a look at this issue?

@konstruktoid : Maybe you would like to take a look at this issue?

Can't reproduce.
But that page is getting a rewrite: https://github.com/MicrosoftDocs/windows-itpro-docs/pull/8960?
~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.1 LTS
Release:        20.04
Codename:       focal
~$ curl -o microsoft.list https://packages.microsoft.com/config/ubuntu/20.04/insiders-fast.list
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    97  100    97    0     0    167      0 --:--:-- --:--:-- --:--:--   167
~$ sudo mv ./microsoft.list /etc/apt/sources.list.d/microsoft-insider.list
~$ curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
vagrant@focal:~$ sudo apt-get -y update
Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease
Hit:2 http://security.ubuntu.com/ubuntu focal-security InRelease
Get:3 https://packages.microsoft.com/ubuntu/20.04/prod insiders-fast InRelease [7,416 B]
Get:4 https://packages.microsoft.com/ubuntu/20.04/prod insiders-fast/main amd64 Packages [3,946 B]
Hit:5 http://archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:6 http://archive.ubuntu.com/ubuntu focal-backports InRelease
Fetched 3,946 B in 1s (4,211 B/s)
Reading package lists... Done
~$ sudo apt-get install gpg
Reading package lists... Done
Building dependency tree
Reading state information... Done
gpg is already the newest version (2.2.19-3ubuntu2).
gpg set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 25 not upgraded.
~$ sudo apt-get -y upgrade
[...]
Processing triggers for install-info (6.7.0.dfsg.2-5) ...
Processing triggers for libc-bin (2.31-0ubuntu9.2) ...
Processing triggers for systemd (245.4-4ubuntu3.4) ...
Processing triggers for man-db (2.9.1-1) ...
~$

Can't reproduce.
But that page is getting a rewrite: https://github.com/MicrosoftDocs/windows-itpro-docs/pull/8960?
~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.1 LTS
Release:        20.04
Codename:       focal
~$ curl -o microsoft.list https://packages.microsoft.com/config/ubuntu/20.04/insiders-fast.list
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    97  100    97    0     0    167      0 --:--:-- --:--:-- --:--:--   167
~$ sudo mv ./microsoft.list /etc/apt/sources.list.d/microsoft-insider.list
~$ curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
vagrant@focal:~$ sudo apt-get -y update
Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease
Hit:2 http://security.ubuntu.com/ubuntu focal-security InRelease
Get:3 https://packages.microsoft.com/ubuntu/20.04/prod insiders-fast InRelease [7,416 B]
Get:4 https://packages.microsoft.com/ubuntu/20.04/prod insiders-fast/main amd64 Packages [3,946 B]
Hit:5 http://archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:6 http://archive.ubuntu.com/ubuntu focal-backports InRelease
Fetched 3,946 B in 1s (4,211 B/s)
Reading package lists... Done
~$ sudo apt-get install gpg
Reading package lists... Done
Building dependency tree
Reading state information... Done
gpg is already the newest version (2.2.19-3ubuntu2).
gpg set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 25 not upgraded.
~$ sudo apt-get -y upgrade
[...]
Processing triggers for install-info (6.7.0.dfsg.2-5) ...
Processing triggers for libc-bin (2.31-0ubuntu9.2) ...
Processing triggers for systemd (245.4-4ubuntu3.4) ...
Processing triggers for man-db (2.9.1-1) ...
~$

Very good. We can have more feedback or consider closing this ticket when the PR is merged and the page is updated.

Very good. We can have more feedback or consider closing this ticket when the PR is merged and the page is updated.

cd ..
rm -rf
git clone
cd
gh pr checkout 19
حذف مستودعك  ، واستنساخه جديدًا ، ثم سحب طلب السحب مرةاخره


Flutter SDK

Hi !
I noticed that several Flutter packages are available for the Adobe SDK, but this extension isn't yet. I haven't found any roadmap for it and my customer would like to integrate it into his app.
Do you have any short-term plans to release an SDK for Campaign which supports Flutter ?
Thank you.

Hi @aloisdeniel - we don't have near-term plans to provide Flutter support for Campaign given current priorities. Recommend working with your Adobe CSM and account team if this is an important need for you.


test: add ut for pkg/version/version.go

What type of PR is this?
/kind test
What this PR does / why we need it:
add ut for pkg/version/version.go
Which issue(s) this PR fixes:
Fixes # https://github.com/Project-HAMi/HAMi/issues/569
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

/lgtm


Highlight new column name

Related to: #12662
When a new column is added its input is focused for renaming the column

👍

It's in ded15, in case you want to take a look @piensaenpixel.

retest please

retest this please

<3


chore(main): release 0.2.15

:robot: I have created a release beep boop
0.2.15 (2024-11-10)
Bug Fixes

调试使用Github的环境变量22 (8e645e0)
调试使用Github的环境变量23 (e8d33da)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v0.2.15
:sunflower:


fix: sdk hot reload content mappings update

WHY
During local scene development, if the locally running scene updates its mappings (for example if a new GLTF 3D model asset is added in any of its directories), the Explorer reloads the scene but doesn't fetch the SceneEntityDefinition from scratch, thus keeping an old version of the content/mappings available in the scene.
This is something used VERY frequently with Decentraland Editor (the level editor accessible through the new Creators Hub) and it's very problematic that the Explorer is not able to reload correctly when a new 3D asset is placed in the scene.
WHAT
Updated the scene reload logic, only for local scene development, to make the pertinent systems fetch everything scene-related from scratch when reloading during hot-reload.
Bonus
Since having the local scene as a static/predefined scene makes it a lot easier, enabled the Landscape with dynamic generation for local scene development as well.
QA TEST INSTRUCTIONS
...

This will probably be updated once this other PR is merged...

Enabled dynamic landscape generation for local scene development in this same PR (closing https://github.com/decentraland/unity-explorer/pull/2229) since having the local scene in the static scenes makes it a lot easier.


wcrp_barrier_extent_report query incorrect

Fixing https://github.com/smnorris/bcfishpass/issues/104 means that the query for wcrp_barrier_extent.sql isn't right anymore - it has to exclude crossings that have no upstream crossings present for the sum to be accurate.
No, I don't think this is it, I'm not sure yet what the issue is.

Something is wrong with the fix to #104, the _belowupstreambarrier_ values are incorrect - closing this and reopening that one.

Ok, issue is the sum includes all crossings, not just barriers!


Support user set BUNDLE_USER_CACHE

Verification

[X] This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature
Have Homebrew Bundler honor BUNDLE_USER_CACHE path variable if it has been set by the user.
What is the motivation for the feature?
When Homebrew installs or updates vendor gems it creates or uses the ./bundle/cache directory ignoring BUNDLE_USER_CACHE variable set in the users environment. By the doing this it negates setting the variable in the first place.
How will the feature be relevant to at least 90% of Homebrew users?
It will not be relevant.
What alternatives to the feature have been considered?
No alternatives have been considered.

Why do you want this variable to be honoured?
That Homebrew uses Bundler should be seen as an implementation detail. This seems like a potentially small performance improvement for developer commands in exchange for a higher change of errors occurring with cache/Bundler issues.

I am not sure we are on the same page. Hopefully the following will add more clarity.
On macOS I have setup my shell environment to follow the XDG directory spec as much as possible. To have my preferences supported by Bundler I added the BUNDLER_USER_* variables to my profile per their instructions. Using Bundler (installed via Homebrew Ruby) directly I found that my defined paths were honored and the default ~/.bundler folder was not created. However, outside my use of Bundler I found that the ~/.bundler folder was being created and used by another tool. After a little testing, I found that Homebrew's use of Bundler was the source and only the ~/.bundler/cache folder was being created.
So for me, supporting BUNDLER_USER_CACHE would reduce some confusion and potentially support a user's existing preferences.
(I did try one quick attempt at implementing a solution but I was unsuccessful.)

After a little testing, I found that Homebrew's use of Bundler was the source and only the ~/.bundler/cache folder was being created.

Was anything put in it/used from it? Ideally we'd avoid creating/using these sorts of directories in Homebrew at all. I agree with avoiding writing things to $HOME is ideal if possible.

Yes. Standard looking compact_index folder and contents. Directory listing attached.
ruby-cache-ls.txt

As a side note, after clearing Homebrew gems and then reinstalling the following error is consistently flagged.
Error loading RubyGems plugin "/opt/homebrew/Library/Homebrew/vendor/bundle/ruby/3.1.0/plugins/yard_plugin.rb": cannot load such file -- /opt/homebrew/Library/Homebrew/vendor/bundle/ruby/3.1.0/gems/yard-0.9.36/lib/rubygems_plugin.rb (LoadError)

Setting it unconditionally to HOMEBREW_CACHE/bundler could make sense.

after clearing Homebrew gems

How are you clearing the gems?

How are you clearing the gems?

Via brew install-bundler-gems --groups=
I found the solution in a comment on GitHub. It wasn't clear to me how to do it otherwise.

Yeah that's the supported way. Will check why Bundler doesn't cleanup plugins.

Setting it unconditionally to HOMEBREW_CACHE/bundler could make sense.

Agreed. Should just be an environment variable to do so.

On my end #17304 doesn't resolve the issue. ~/bundle reappears when running brew install-bundler-gems --add-groups=bottle. No folder is created in ~/Library/Caches/Homebrew, if that is the new location.

What's the output of brew config and brew doctor?

brew config

HOMEBREW_VERSION: 4.3.0-22-g56db99e
ORIGIN: https://github.com/Homebrew/brew
HEAD: 56db99ee9f3e47283c97b5471dac3178f58daf55
Last commit: 3 hours ago
Core tap JSON: 15 May 16:39 UTC
Core cask tap JSON: 15 May 16:39 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_CLEANUP_MAX_AGE_DAYS: 60
HOMEBREW_DEVELOPER: set
HOMEBREW_EDITOR: /opt/homebrew/bin/mvim
HOMEBREW_GITHUB_API_TOKEN: set
HOMEBREW_MAKE_JOBS: 8
HOMEBREW_NO_EMOJI: set
HOMEBREW_NO_ENV_HINTS: set
HOMEBREW_NO_UPDATE_REPORT_NEW: set
HOMEBREW_SORBET_RUNTIME: set
Homebrew Ruby: 3.1.4 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/bin/ruby
CPU: octa-core 64-bit arm_ibiza
Clang: 15.0.0 build 1500
Git: 2.45.1 => /opt/homebrew/bin/git
Curl: 8.6.0 => /usr/bin/curl
macOS: 14.5-arm64
CLT: <IP_ADDRESS>.1.1708646388
Xcode: N/A
Rosetta 2: false

brew doctor

Your system is ready to brew.

~/bundle reappears when running brew install-bundler-gems --add-groups=bottle.

Do you have a ~/.bundle/config?

Do you have a ~/.bundle/config?

No. The following is my .zprofile:
export BUNDLE_USER_CONFIG=$XDG_CONFIG_HOME/bundle/config
export BUNDLE_USER_PLUGIN=$XDG_DATA_HOME/bundle
export BUNDLE_USER_CACHE=$XDG_CACHE_HOME/bundle

Output from bundle config list:
Settings are listed in order of priority. The top value will be used.
user_cache
Set via BUNDLE_USER_CACHE: "/Users/xxx/.cache/bundle"

user_config
Set via BUNDLE_USER_CONFIG: "/Users/xxx/.config/bundle/config"

user_plugin
Set via BUNDLE_USER_PLUGIN: "/Users/xxx/.local/share/bundle"

I don't have a config file so the config folder doesn't exist and is not created.


Change admin to superuser; implement Auth0 flow prototype

This changes the admin role to super user, and implements a prototype function for validating the issuer of a JWT.
This has not been tested at all, and should be viewed as a rough draft for what the new Auth0 flow for OpenFMB.hmi looks like.
Signed-off-by: Timothy<EMAIL_ADDRESS>

Closing without merging; the new OAuth branch includes these changes.


error[E0432]: unresolved imports self::tesseract_sys::TessBaseAPIGetAltoText, self::tesseract_sys::TessBaseAPIGetLSTMBoxText, self::tesseract_sys::TessBaseAPIGetTsvText, self::tesseract_sys::TessBaseAPIGetWordStrBoxText

Hi @ccouzens,
Thank you for your work on this! I am running into an issue where I am getting below error:
    Updating crates.io index
  Downloaded atty v0.2.14
  Downloaded env_logger v0.8.3
  Downloaded shlex v0.1.1
  Downloaded leptonica-sys v0.3.4
  Downloaded lazy_static v1.4.0
  Downloaded which v3.1.1
  Downloaded memchr v2.4.0
  Downloaded cfg-if v1.0.0
  Downloaded regex-syntax v0.6.25
  Downloaded regex v1.5.4
  Downloaded libc v0.2.94
  Downloaded cexpr v0.4.0
  Downloaded bitflags v1.2.1
  Downloaded humantime v2.1.0
  Downloaded clang-sys v1.2.0
  Downloaded bindgen v0.56.0
  Downloaded clap v2.33.3
  Downloaded quote v1.0.9
  Downloaded log v0.4.14
  Downloaded termcolor v1.1.2
  Downloaded strsim v0.8.0
  Downloaded thiserror v1.0.24
  Downloaded version_check v0.9.3
  Downloaded thiserror-impl v1.0.24
  Downloaded vec_map v0.8.2
  Downloaded peeking_take_while v0.1.2
  Downloaded proc-macro2 v1.0.26
  Downloaded aho-corasick v0.7.18
  Downloaded unicode-xid v0.2.2
  Downloaded textwrap v0.11.0
  Downloaded syn v1.0.72
  Downloaded ansi_term v0.11.0
  Downloaded libloading v0.7.0
  Downloaded lazycell v1.3.0
  Downloaded unicode-width v0.1.8
  Downloaded nom v5.1.2
  Downloaded leptonica-plumbing v0.3.0
  Downloaded rustc-hash v1.1.0
  Downloaded glob v0.3.0
  Downloaded tesseract-sys v0.5.5
  Downloaded tesseract-plumbing v0.5.1
  Downloaded leptess v0.12.0
  Downloaded 42 crates (4.7 MB) in 1.85s (largest was `leptess` at 2.1 MB)
   Compiling memchr v2.4.0
   Compiling libc v0.2.94
   Compiling proc-macro2 v1.0.26
   Compiling unicode-xid v0.2.2
   Compiling glob v0.3.0
   Compiling version_check v0.9.3
   Compiling cfg-if v1.0.0
   Compiling log v0.4.14
   Compiling bitflags v1.2.1
   Compiling unicode-width v0.1.8
   Compiling regex-syntax v0.6.25
   Compiling bindgen v0.56.0
   Compiling termcolor v1.1.2
   Compiling humantime v2.1.0
   Compiling vec_map v0.8.2
   Compiling ansi_term v0.11.0
   Compiling strsim v0.8.0
   Compiling lazy_static v1.4.0
   Compiling shlex v0.1.1
   Compiling rustc-hash v1.1.0
   Compiling lazycell v1.3.0
   Compiling peeking_take_while v0.1.2
   Compiling syn v1.0.72
   Compiling clang-sys v1.2.0
   Compiling nom v5.1.2
   Compiling libloading v0.7.0
   Compiling textwrap v0.11.0
   Compiling aho-corasick v0.7.18
   Compiling quote v1.0.9
   Compiling atty v0.2.14
   Compiling which v3.1.1
   Compiling clap v2.33.3
   Compiling regex v1.5.4
   Compiling cexpr v0.4.0
   Compiling thiserror-impl v1.0.24
   Compiling env_logger v0.8.3
   Compiling leptonica-sys v0.3.4
   Compiling tesseract-sys v0.5.5
   Compiling thiserror v1.0.24
   Compiling leptonica-plumbing v0.3.0
   Compiling tesseract-plumbing v0.5.1
error[E0432]: unresolved imports `self::tesseract_sys::TessBaseAPIGetAltoText`, `self::tesseract_sys::TessBaseAPIGetLSTMBoxText`, `self::tesseract_sys::TessBaseAPIGetTsvText`, `self::tesseract_sys::TessBaseAPIGetWordStrBoxText`
 --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/tesseract-plumbing-0.5.1/src/tess_base_api.rs:5:43
  |
5 |     TessBaseAPICreate, TessBaseAPIDelete, TessBaseAPIGetAltoText, TessBaseAPIGetComponentImages,
  |                                           ^^^^^^^^^^^^^^^^^^^^^^ no `TessBaseAPIGetAltoText` in the root
6 |     TessBaseAPIGetHOCRText, TessBaseAPIGetInputImage, TessBaseAPIGetLSTMBoxText,
  |                                                       ^^^^^^^^^^^^^^^^^^^^^^^^^ no `TessBaseAPIGetLSTMBoxText` in the root
7 |     TessBaseAPIGetSourceYResolution, TessBaseAPIGetTsvText, TessBaseAPIGetUTF8Text,
  |                                      ^^^^^^^^^^^^^^^^^^^^^ no `TessBaseAPIGetTsvText` in the root
8 |     TessBaseAPIGetWordStrBoxText, TessBaseAPIInit2, TessBaseAPIInit3, TessBaseAPIMeanTextConf,
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `TessBaseAPIGetWordStrBoxText` in the root
  |
help: a similar name exists in the module
  |
5 |     TessBaseAPICreate, TessBaseAPIDelete, TessBaseAPIGetUTF8Text, TessBaseAPIGetComponentImages,
  |                                           ^^^^^^^^^^^^^^^^^^^^^^
help: a similar name exists in the module
  |
6 |     TessBaseAPIGetHOCRText, TessBaseAPIGetInputImage, TessBaseAPIGetBoxText,
  |                                                       ^^^^^^^^^^^^^^^^^^^^^
help: a similar name exists in the module
  |
7 |     TessBaseAPIGetSourceYResolution, TessBaseAPIGetUTF8Text, TessBaseAPIGetUTF8Text,
  |                                      ^^^^^^^^^^^^^^^^^^^^^^
help: a similar name exists in the module
  |
8 |     TessBaseAPIGetBoxText, TessBaseAPIInit2, TessBaseAPIInit3, TessBaseAPIMeanTextConf,
  |     ^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `tesseract-plumbing`

To learn more, run the command again with --verbose.

My dockerfile is as follows:
FROM rust:1.52

RUN apt-get update && DEBIAN_FRONTEND="noninteractive" TZ="America/Los_Angeles" apt-get install -y tesseract-ocr libleptonica-dev libtesseract-dev clang tesseract-ocr-eng

RUN mkdir -p /home/producting
WORKDIR /home/producting

And cargo.toml:
[package]
name = "rust_tess"
version = "0.1.0"
authors = ["me"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
leptess = "0.12.0"

Any chance you would know what I am doing wrong here?

Yup - thats how the hunch I had, too, and decided to change the version.
Again, thank you for your work and replying to my issue!
On a completely unrelated topic, I am just curious how you got involved in tesseract and rust. Reading the code, I can tell thats a lot of work someone is doing for free 👍  . I am still learning so I really appreciate this!

Again, thank you for your work and replying to my issue!

No problem

I am just curious how you got involved in tesseract and rust

I got into Rust because I kept hearing great things about it. I eventually looked into it- and was very impressed so I kept going.
I got into maintaining the Tesseract Rust crates by doing this Advent of Code Puzzle. The puzzle leads you to construct a bitmap containing a word. The solution to the puzzle is the word. The easy thing to do would be to print the bitmap and read the word manually. But I wanted to unit test it and have the word read from the bitmap automatically. I found tesseract-rs but it didn't quite work.
I submitted some patches to tesseract-rs and was eventually invited to become a co-maintainer. My experience with tesseract-rs allowed me to help out with leptess and I was invited to be a co-maintainer there too.
It's funny- I don't actually know much about Tesseract. Many of the crate users probably know more than me about it. But fortunately most feature requests make use of easier parts of the API so I've been able to accommodate them.

I am still learning so I really appreciate this!

How are you finding it?


yuv2buf for processing ImageReader output

Sorry, I unintentionally closed https://github.com/android/camera-samples/pull/336 and had to close https://github.com/android/camera-samples/pull/404 because of google-cla bot. So here is updated version of them.
Part discussion of this code is in issue #277.
Documentation about approach, unit-tests, performance benchmarks + demo application are here https://github.com/gordinmitya/yuv2buf. This code is tested in several apps in production with both: Camera2 output and MediaCodec outputs.
I compared performance of previous and new code on my Mi 9t pro (Snapdragon 855): old 3.5-4.0ms, new 2.6-3.0ms.
Modified CameraActivity.kt was used for comparison.
Will be happy to answer questions, if any!

cool.  a separate note, if you have not filled the CameraX 1.0  survey yet, may you fill it here: https://forms.gle/DarkBYwWFmDzdtLr8? It would be a good one to Camera(X) team: make sure to state your suggestions!  Thanks!

Confirmed for the performance gain in Pixel3 devices with images 640x480: about 30% improvement. Performance is import. A couple of things to do, I think:

Add some more detailed comment for YuvToRgbConvert() in your version or keep the original warning there (feel free to change but keep the warning might be good)
Convert the file to Kotlin
CameraX dependency: need to decide, punt it for now.

could you help for them? thx

@gordinmitya merging this one now, then I will get help internally to convert it to kotlin then plug it into samples (right now it is in the lib module, not used). thank you for the PR.


Fix for pytest in test_joining.py

Running pytest on pygdf root folder fails for GDF containing columns of type np.float32 and np.float64. Until they are supported in libgdf.gdf_multi_left_join_generic, this should be a solution.

@yashv28 can we fix/change the test instead of changing the API? We changed the API to use left and left-compat because that's what end users will expect.

okay @nsakharnykh and I can look into it, until then this should serve as a temporary workaround.

Looks good to me. Thanks @yashv28. Merging!


Change the name to be more related

Smart Unit Preferences is kinda a fascinating name, especially the smart part. Therefore, if you have any suggestion would be nice :)

@sffc , @zbraniecki , @hugovdm ... could you add suggestions, please?

Based on LDML - http://unicode.org/reports/tr35/tr35-general.html#Unit_Preference_and_Conversion - maybe "NumberFormat Unit Preferences"?

Or just "Measurement Unit Preferences"?

I think Unit Preferences is enough

I would have liked "NumberFormat Unit Preferences" if that was all that we would propose with this.
There was some talk in the meeting about exposing just the preferences as a first step, and not implementing the conversions? Because of this, I'm feeling "Measurement Unit Preferences" is broader in scope and would have us covered even if we did end up "pivoting" away from [only] changing Intl.NumberFormat with this.

The problem with "Unit Preferences" is that it is easy to confuse with "User Preferences".

@hugovdm , I do not want to tight Unit Preferences with NumberFormat, because may be people will use some of the Unit Preferences stuffs without formatting such as conversion or just to know the preferences themselves ... etc.
@sffc,  I agree with you

@hugovdm , I do not want to tight Unit Preferences with NumberFormat, because may be people will use some of the Unit Preferences stuffs without formatting such as conversion or just to know the preferences themselves ... etc.

Does it mean you intend for the API to be attached to Intl directly rather than Intl.NumberFormat?

The problem with "Unit Preferences" is that it is easy to confuse with "User Preferences".

I don't see this as an issue.

@hugovdm , I do not want to tight Unit Preferences with NumberFormat, because may be people will use some of the Unit Preferences stuffs without formatting such as conversion or just to know the preferences themselves ... etc.

Does it mean you intend for the API to be attached to Intl directly rather than Intl.NumberFormat?

I'm primarily thinking of the request someone made: for us to consider providing an API that returns user preferences, before we consider adding an API that actually does all the conversions etc as well. I'm not convinced by this suggestion, but I'm appreciating some concerns about the complexity we're adding to the ECMAScript platform when we're going so far as to add unit conversions to it.
Recap: practically speaking, how do we relate to up-to-date ECMAScript implementations that don't make use of ICU? (Do they exist at this time, or is this hypothetical?)

Two examples of future non-ICU implementations are polyfills (such as format.js) and ICU4X.

for us to consider providing an API that returns user preferences, before we consider adding an API that actually does all the conversions etc as well.

That was me and the motivation is to continue with the tradition of ECMA402 being building blocks for user libraries that are intended to lower the entry barrier and payload per-website.
In this case, I'm not confident that the payload is high, and the use case is common enough to justify such API, but if it is, offering building blocks rather than end-to-end solution seems safer and less likely to backfire.

Recap: practically speaking, how do we relate to up-to-date ECMAScript implementations that don't make use of ICU? (Do they exist at this time, or is this hypothetical?)
-- This does go a bit off-topic, maybe we need a separate discussion thread for this?

I would consider it to be a failure of this WG if we ended up designing a spec that implicitly requires ICU backing.


Make wumbo mandatory

related: #78
We want to eliminate other scenarios that we didn't test for. Target users of PeerSwap really need larger channels. There is no good reason to operate a non-wumbo LN node with peerswap. PeerSwap should check for this during startup and refuse to load if the accompanying LN node is not properly configured then print an informative error message before exiting.
CLN has listconfigs which can show configuration options.
LND has something similar?

Not sure if forcing large channels is necessary.
Smaller nodes could still use and benefit from PeerSwap and maybe would not be comfortable receiving/opening such channels. It might not look extreme now, but keep in mind a 10x purchasing power.
Also don't know a way to check in LND apart from parsing the lnd.conf.

Not sure if forcing large channels is necessary.
The main reason for wumbo is it reduces the scenarios we need to test for. We can't afford unexpected behavior in a configuration that we did not test much at all.

Also note: CLN v0.12 they are considering making wumbo default.

https://github.com/lightning/bolts/blob/master/09-features.md
specifies featurebit 18/19 as wumbo channels. On startup we could run lncli getinfo and restrict swaps larger than 4.2mm sats to only wumbo enabled nodes.

Does this really mean that PeerSwap is not expected to work with smaller than 16M channels?

IIUC it is not about the channelsize, but the way payments larger than 4.2m sats are paid / simply if the festurebit is set. As in we can more easily support wumbo-enabled channels of less than 16m sats than non-wumbo enabled channels.

Does this really mean that PeerSwap is not expected to work with smaller than 16M channels?

I'm pretty sure wumbo enabled channels below 16 million sats are able to transfer the entire amount without MPP?

There is nothing I found in the specs thats suggests that the wumbo setting affects the max HTLC size:
https://github.com/lightning/bolts/blob/master/02-peer-protocol.md

The option_support_large_channel is a feature used to let everyone know this node will accept funding_satoshis greater than or equal to 2^24. Since it's broadcast in the node_announcement message other nodes can use it to identify peers willing to accept large channel even before exchanging the init message with them.

The requirement for funding_satoshis to be less than 2^24 satoshi was a temporary self-imposed limit while implementations were not yet considered stable, it can be lifted by advertising option_support_large_channel.

https://amboss.space displays the max HTLC-s of nodes and it showed the number equal to the size of the channel for a node I know not has wumbo configured.

What benefit is there in running with non-wumbo, and is that worth ballooning the quantity of required test cases to ensure it doesn't break here?

What benefit is there in running with non-wumbo, and is that worth ballooning the quantity of required test cases to ensure it doesn't break here?

I see it as a default protection for having and moving large amounts on the node, but agree that it does not worth risking to break the larger swaps.
Will just add the option to the config files in the PeerSwap install script.
As it will be set manually by most it would be best to start recommending already in the installation notes.

CLN v0.12 they're considerig making wumbo default.
This ticket would make PeerSwap refuse to start if wumbo is not active so users won't make mistakes.


[Bug]: OpensearchVectorStore is not BasePydanticVectorStore

Bug Description
According to blog this should work:
vector_store = QdrantVectorStore(client=client, collection_name="test_store") pipeline = IngestionPipeline(     transformations=[         SentenceSplitter(chunk_size=25, chunk_overlap=0),         TitleExtractor(),         OpenAIEmbedding(),     ],     cache=IngestionCache(cache=RedisCache(), collection="test_cache"),     vector_store=vector_store, ) pipeline.run(documents=[Document.example()])
This doesn't work with OpensearchVectorStore, because it's still a normal VectorStore and not refactored into BasePydanticVectorStore
Version
0.9.1
Steps to Reproduce
Just try a pipeline with an OpensearchVectorStore
Relevant Logs/Tracbacks
No response

I think, this whole class / abstraction is quite unusable.
The delete function is also not working at all and all kind of OpenSearch client exceptions leak through.
This seems totally wrong:
OpensearchVectorClient
def delete_doc_id(self, doc_id: str) -> None:
self._os_client.delete(index=self._index, id=doc_id)
It tries to delete by ID, which is not document ID, but the generated node chunk UUID.
It must delete "by query" with "doc_id".
Many architectures already contain an OpenSearch stack - so it would be nice to really support this Software as good as other more exotic stuff...    Plz check the paper "Lucene is all you need" for vector indices.

well crap, encountered this today. this breaks my plans.

@dosu-bot What other classes inherit from BasePydanticVectorStore that are able to run in AWS and locally?

@andrePankraz the behavior you described seems to be related to the changes made in this PR. Since _id is auto-generated, llama index doesn't properly track which document to delete.

It must delete "by query" with "doc_id".

Is delete by query supported on AOSS?

Yes it is. I'm using that on another project
On Sat, Jan 27, 2024, 14:36 Collin Dutter @.***> wrote:

@andrePankraz https://github.com/andrePankraz the behavior you
described seems to be related to the changes made in this PR
https://github.com/run-llama/llama_index/pull/10043. Since _id is
auto-generated, llama index doesn't properly track which document to delete.
It must delete "by query" with "doc_id".
Is delete by query supported on AOSS?
—
Reply to this email directly, view it on GitHub
https://github.com/run-llama/llama_index/issues/8954#issuecomment-1913355205,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC24BRYKBPI2K3OQY3ZF7VTYQV6NNAVCNFSM6AAAAAA7N6O27KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGM2TKMRQGU
.
You are receiving this because you commented.Message ID:
@.***>

@blade2005 are you able to share any information on how you're using _delete_by_query? I've not been able to get it working, and am facing the same issues described here.

from opensearchpy import OpenSearch

host: str
port: str
client = OpenSearch(
        hosts=[{"host": host, "port": int(port)}],
        http_auth=auth
    )
index_name: str
url: str # s3 bucket url
response = client.delete_by_query(
    index=index_name, body={"query": {"match": {"url": url}}}
)

Hello,
I am also planning to use IngestionPipeline with AWS OpenSearch Serverless(AOSS) which is not compatible at the moment. Any plan to implement this?

@sumeshmr With the latest refactoring announced for v0.10, we seem to be officially on our own for supporting the "integrations" now.

@dosu-bot I tried the new version v0.10, still IngestionPipeline is not compatible with opensearch


Add feature gates documentation to public docs

The purpose of this issue is to ensure that the FEATURE_GATES.md documentation gets migrated to https://docs.konghq.com/kubernetes-ingress-controller/latest/references/ as it's own sub-page

https://github.com/Kong/docs.konghq.com/pull/4140 pr here


Is this still under progress?

What do you mean, the ts2c project? Yes it is still work in progress. There is a big refactoring  ongoing in the "types-refactoring" branch at the moment.

Even the types-refactoring branch also seems to be dormant for some time.
Any roadmap of when the next commit will be made to either of the branches?

Hi, no real roadmap as such. Just returned from the summer vacation. Will continue with ts2c when I have time!


fix(2494): Incidents: Add the ability to edit incident details

fix #2494
Fixes #2494.
Changes proposed in this pull request:

merge code from master to current branch
change useResolveIncident hook to useUpdateIncident
in ViewIncidentDetails page, implement controlled inputs/forms with useState and useEffect, and make relevant fields editable:
1a. department
1b. category
1c. category item
1d. description
1e. incident reported to (*) - (to-do, need more info on whether this maps to another user or is just string field)
1f. patient impacted
make ViewIncidentDetails.test.tsx reflect that form should be editable
make it so that patient field is always visible, with on view/update, allows user to update the patient field from previously null/empty/undeff to a new patient value
add reportedTo

cla was signed but showing as not signed, waiting on this

@tehKapa could you add james + cynthia again for the reviewers? I can't seem to add them by myself

@riiniii The issue with the CLA is that every author every commit in this PR has to sign the CLA. I would edit the commits to remove the authorship of Renee Huang, as it seems that they do not have a GitHub account and thus cannot sign the CLA. @tehKapa It seems like a good amount of contributors are running into this -- should the CLA only consider the GitHub author of the PR?

updated w/ pr fixes/comment updates, not in progress anymore


Add debug mode flag for zenml info

Added a -d or --debug flag to go with zenml info that will output information about a user's current / active stack (and the components included as part of it. In addition to whatever we usually have as part of the zenml info command, you get this kind of information, to be used potentially as part of debugging cloud stacks on Slack:

Pre-requisites
Please ensure you have done the following:

[ ] I have read the CONTRIBUTING.md document.
[ ] If my change requires a change to docs, I have updated the documentation accordingly.
[ ] If I have added an integration, I have updated the integrations table and the corresponding website section.
[ ] I have added tests to cover my changes.

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 change)
[ ] Other (add details above)

Also on a more general note, the --debug flag name doesn't really capture what this does IMO, maybe something like --include-stack-info or some shortened version of that?


rails 5 @tmpname nil

the original_filename method was raising an exception if {column}_data_filename =  was not set before trying to save the data uri. This pull request addresses that by defaulting to the name of the tempfile instead of @tmpname, which was nil.

@jasonaibrahim Thanks for contribution. But can you please add spec to simulate this bug?

if you run the current specs using ruby 2.3.0 they will fail. with this pull request they pass. thanks to @KBalderson for identifying that it was a ruby issue, not rails.

@jasonaibrahim yes, indeed. Just added ruby 2.3 to travis and it fails.
Can you please rebase from master to make sure specs are passing with ruby 2.3

just rebased and pushed. not sure what you mean by rebase from master.. do you want me to merge my commit onto master and issue another pr ?

I added ruby-2.3 to the travis and it is in the master now. So i just meant to rebase latest changes from master to this branch to see if ruby2.3 case was fixed.
But that's ok. i will merge it right now.


go version 1.12 not allowed

when I use go version 1.12 and 1.12.3 build my exe,I cannot open my exe, when I double click exe nothing to show, then I use go version 1.11.3 window/amd64 build, then it works , I cant find why, hope an cool person to help me, thank you very much

#51

A new version was not released after the fix.
Try using go get github.com/zserge/lorca@master to get the latest version

Created v0.1.7 tag.


atoms can be portable classes

This should give atoms the ability to be portable classes

Which means they can have capabilities, which means they can send updates from server to client!

exactly!


Multiple acessory images

Backwards compatible with setting a single image.
Fixes #57 and #56

Hi @nsolter
Sorry it took me so long to get back at you.
I'm seeing an issue in the demo project:
http://d.pr/i/ZTdL

@andreamazz sorry, I have stopped working on the project that uses this, so I don't know that I'm going to be able to complete this pull request.

No problem 👍


SWIFT_VERSION for targets other than iOS

In the swift 2.3 branch, only iOS target has the SWIFT_VERSION setted.
This PR set the tag for other targets

Thanks @bmichotte 😃


Fixed text rendering artifacts on Radeon cards.

Padding set to 1.0 was causing adjacent glyphs leaking on Radeon cards. The initial padding value for glyphs was too high anyway, the proper value should be 0.5 on each side.
Example video: https://youtu.be/sN44kuPA1Jk

Can you please post before-after screenshots, so we can compare two padding values directly?

It's in the linked video, I can only post a screenshot now zoomed in of the text rendering before the fix:

I see, so there's some tearing. Does the distance between glyphs change? Or is it still the same?
If so, I think that this PR should be approved. At the worst case we should have padding configurable for sf::Font (not sure if other values would be meaningful for it)

I tested different padding sizes and compared screenshots before my initial commit with padding 1.0. Since I apply the padding to the size and uv coords the glyph size and positioning stay the same, so no worries with that. Adding an additional parameter would not serve any useful purpose.

Am I correct that setting padding of 0.5 makes vertices have non-integer coordinates? This makes me a bit anxious, because from experience I've seen non-integer coordinates cause a lot of tearing.
Otherwise we need to test:

For different GPUs
For different fonts

Right now it looks like text rendering is really simplistic in SFML and it doesn't take kerning into account, as far as I see. If you render text  with 1.0 padding to sf::RenderTexture, does tearing go away?

Don't be.
UV and coord set to -0.5  null each other out.
Without padding the glyphs were clipping during sub pixel scrolling.
With padding 1.0 on AMD there is no clipping
With padding 1.0 nVidia there is no clipping, but adjacent glyphs are leaking from the glyph texture.
With padding 0.5 everything is working nicely.
Btw it's the same as half texel offset used for textures by Laurent many years back.

I've tested it myself on Win10 with AMD, nvidia and integrated Intel and also on the Raspberry PI

There is an alternative route, but requires modifying glyph texture generation. You leave the padding as 1.0 and add 2 pixel padding between glyphs on the glyph sheet instead of 1.

I think this looks pretty solid then, thanks for testing and explanations.
Now it's to @LaurentGomila and @eXpl0it3r to decide. :)

@binary1248  - any thoughts as well?

I wouldn't call this phenomenon "leaking" as it can occur even when there is a lot of space between "set" texels, and it should be consistent every time a glyph is rendered, which doesn't look to be the case.
I'm guessing this is one of those cases where the OpenGL specification didn't 100% define how texture filtering should be performed along the edges of the source rectangle where a part of the sampling area basically consists of "undefined" data. I would have to guess how big the sampling area is, but it would be at least 3x3 texels around the centre, maybe even larger.
Sampling is always done at texel centres, so adding 0.5 would be more correct in that sense and leave less room for interpretation/interpolation by the implementation.
I would still also bump the padding between glyphs up to 2 just to be extra safe. I don't think requiring that extra space is going to make any difference in real world scenarios. It is amortized when dealing with larger glyphs anyway which is the only scenario where you would have to worry about texture size.

So, does it mean that you approve my commit?

Implementations might change. Remembering my work from years ago when broken Intel IGPs were still prevalent, I remember that a padding of 1 was not enough in some rare scenarios. That's why I always used a value of at least 2 in my own code. This might no longer be necessary now with less broken implementations around, so we have the choice of increasing the padding now as a precautionary measure or waiting until a real bug report comes in and increasing it then.

@oomek Do you still have the example code? I want to give this a run on my system.

@ eXpl0it3r sure, but tomorrow if you don't mind, as my daughter is occupying my PC atm.

I'm sorry, I forgot to post a sample code, but because I couldn't find it I wrote a new one:
`#include <SFML/Graphics.hpp>
int main(int argc, char *argv[])
{
sf::VideoMode desktop_mode = sf::VideoMode::getDesktopMode();
sf::RenderWindow window(desktop_mode, "FONT TEST", sf::Style::Fullscreen);
sf::Font font;
font.loadFromFile("c:/windows/fonts/arial.ttf");

sf::Text text;
text.setFont(font);
text.setString("Lorem ipsum dolor sit amet,\nconsectetur adipiscing elit,\nsed do eiusmod tempor incididunt\nut labore et dolore magna aliqua.\nUt enim ad minim veniam,\nquis nostrud exercitation ullamco laboris\nnisi ut aliquip ex ea commodo consequat.\n");
text.setCharacterSize(80);
text.setFillColor(sf::Color::White);

window.setVerticalSyncEnabled(true);

while (window.isOpen())
{
	sf::Event event;

	while (window.pollEvent(event))
	{
		if (event.type == sf::Event::Closed)
			window.close();

		if (event.type == sf::Event::KeyPressed)
		{
			if (event.key.code == sf::Keyboard::Escape)
				window.close();

			if (event.key.code == sf::Keyboard::Down)
				text.setCharacterSize(text.getCharacterSize() - 1);

			if (event.key.code == sf::Keyboard::Up)
				text.setCharacterSize(text.getCharacterSize() + 1);
		}
	}
	text.move(0.05, 0.05);
	window.clear();
	window.draw(text);
	window.display();
}
return 0;

}`
Use up and down arrows.
I've noticed that the "leaks" occur only when I change the size of the text, maybe the reused glyph buffer isn't cleared properly?

Thanks for the code! 🙂
It's interesting. If I use SFML-master on the integrated Intel GPU, I notice the artifacts. If I use SFML-master on the discrete Nvidia GPU, I don't see any artifacts.
If I use this PR then I don't see any artifacts on the integrated Intel GPU nor on the discrete Nvidia GPU.
In all cases the letters wobble quite a bit when slowly enlarging the font, but I guess that's to be expected.
Will try my AMD GPU at home this evening.

What's very weird, when you don't change the size of the characters there aren't any artifacts, and it does not matter what setCharacterSize() you have set in the beginning. It only manifests when you change the font size at runtime, so it made me thinking, maybe reused textures for glyphs have old uncleared glyph data still in the padding area? what do you think?

maybe reused textures for glyphs have old uncleared glyph data still in the padding area? what do you think?

Glyph textures are never reused. A sf::Font instance does not know what glyphs and sizes will be requested by sf::Text objects, so once it has generated something, it keeps it until its destruction. Internally, sf::Font keeps one separate set of textures per requested character size.

Sorry wrong wording, not glyph data, the textures are reused. Please try my revised code. It's clearly showing the old glyphs from previous sizes that were generated.

A simple clearing the texture after it's generated should fix the problem.

Would be easy to try, the clearing should be made here: https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/Font.cpp#L729

Is it ok to change the newTexture to RenderTexture? Clearing with update() from an image may add some unneccessary overhead.

Would this be acceptable? It works, but requires an Image.
                // Make the texture 2 times bigger
                Texture newTexture;
                newTexture.create(textureWidth * 2, textureHeight * 2);
                Image image;  //added
                image.create(textureWidth * 2, textureHeight * 2, Color::Transparent);  //added
                newTexture.loadFromImage(image);  //added
                newTexture.setSmooth(true);
                newTexture.update(page.texture);
                page.texture.swap(newTexture);

Before talking about the best way to do it... does it solve the problem? Did you make sure to revert your previous changes (padding) before testing this solution?

Yes, it works with padding 1.0

Ok great.
The best way to clear the texture would be to use a dedicated OpenGL feature (attaching to a FBO + glClear, or the GL_ARB_texture_clear extension, ... found on stackoverflow). No idea how hard it would be to integrate to SFML, or if we can even do it, according to our requirements on OpenGL version.
The other solution is to allocate a vector of width*height pixels and call texture.update(...) with that. With the possibility to reuse a single vector to avoid big allocations.

Would you rather have a dedicated function for it, or mixed code in font.cpp?

Ok, how about this:
RenderTexture renderTexture;
renderTexture.create(textureWidth * 2, textureHeight * 2);
renderTexture.clear(sf::Color::Transparent);
Texture newTexture(renderTexture.getTexture());
newTexture.setSmooth(true);
newTexture.update(page.texture);
page.texture.swap(newTexture);

It's actually working.

Seems like we need to summon @binary1248 😉

There are a few points to discuss here.
Is clearing the whole texture necessary when resizing it to accommodate for new glyphs? If e.g. we resized the texture to 4x the size as is done in the current implementation, and only wanted to insert a single glyph, wouldn't it be wasteful to initialize the area that we never intended on using anyway? If uninitialized texture data is the root cause of the problem (and it seems likely), I would focus my effort on initializing only the regions we intend on using, i.e. the area around glyphs that will actually be considered for filtering.
If we look at the current implementation at https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/Font.cpp#L629 we can see that the padding is considered when allocating a rectangle for the new glyph, but when copying the actual data we don't bother to initialize the padding area. This is the error. When resizing an already generated texture object, OpenGL essentially does a "free" and then a "malloc". Because of the proximity of the operations, it would almost always lead to the old block being reused, maybe slightly offset from before in some way. As such, trying to access this data, even through sampling, would be considered as "undefined behaviour" in C++ land.
Quoting the OpenGL specification:

If the data argument of TexImage1D, TexImage2D, orTexImage3D is NULL, and the pixel unpack buffer object is zero, a one-, two-, or three-dimensional texture image is created with the specified target, level, internalformat, border, width, height, and depth, but with unspecified image contents.

When considering performance, which as I understand is what is currently being discussed, we have to look at the actual access patterns before ending up micro-optimizing or even pessimizing the implementation in ways that don't correspond to real-world usage.
How often will an sf::Font texture realistically be resized during the lifetime of an application?
Would the clearing of the texture really dominate this time? Or would some other operation, e.g. FreeType-related consume measureably more time than the actual texture manipulations?
Bear in mind that for quite a while, GPUs and iGPUs have been attached to the system via PCIe or some other form of PCIe-like interface. These interfaces don't like small transfers. Any decent driver will batch a big chunk of "data" together before being sent to the GPU. This increases average latency but also significantly increases throughput as well.
As such, if I had to guess, expanding the rectangle around a glyph to initialize the padding area to proper values wouldn't even have a performance penalty, unless of course the glyphs were really really huge which doesn't happen every day.
This would be the variant I favour.
Because I too find that in some situations clearing a texture to a predefined colour can be useful when the user knows that they would otherwise have to do it "manually", I propose adding a sf::Texture::clear(const sf::Color&) method to sf::Texture. Initially this can be implemented using the naive OpenGL 1.1 compatible implementation. Building in optimizations that take into account extensions and even multiple platforms can get complicated really fast.

Oh god, I somehow knew I'm not gonna get a simple yes or no answer, but I agree with everything you said. I was thinking about increasing the padding to 2.0 for font generation and using a smaller padding 1.0 for drawing as well. The only thing that was stopping me was a hope that we will get a clear() function for textures which I was hoping to get as a bonus, but since you've mentioned it I'm all up for it. I was having the same artifacts on the bottom and right edges while moving textures after updating them dynamically with png's with various sizes. I'm glad we can agree on that. I'm updating the PR then.

My final analysis would be:
PR #1452 introduced a 1 pixel border of "overdraw" around each glyph in order to reduce motion artifacts. This border started to place texel centres within the padding region of the glyph textures. Since this padding was only 1 pixel wide, when OpenGL is forced to interpolate the texture data due to vertices having non-integer coordinates, linear filtering is applied (SFML always set font textures to smooth). Linear filtering samples a 2x2 texel area whose centre lies closest to the texture coordinate in question. Because this 2x2 area would include texels beyond the 1 pixel padding area, regions of undefined texel data would be sampled as well leading to the artifacts along the edges of the glyphs.
The solution was to adjust the padding in accordance with the overdraw introduced in PR #1452 to make sure that any potentially sampled texels within the padding area are initialized to transparent.
The padding in Font.cpp should therefore always be 1 more than the padding in Text.cpp in order to prevent artifacts from appearing.
As an example: setting padding to 2 in both files will cause artifacts as well.

Agreed 100% :+1:

This fixed Nintendo Switch port too.


Use the Jsonrpc types as the abstraction layer in the store interfaces

Description
Use the types from the jsonrpc package on the abstraction interface.
Changes include

[ ] Bugfix (non-breaking change that solves an issue)
[ ] Hotfix (change that solves an urgent issue, and requires immediate attention)
[ ] New feature (non-breaking change that adds functionality)
[ ] Breaking change (change that is not backwards-compatible and/or changes current functionality)

Breaking changes
Please complete this section if any breaking changes have been made, otherwise delete it
Checklist

[ ] I have assigned this PR to myself
[ ] I have added at least 1 reviewer
[ ] I have added the relevant labels
[ ] I have updated the official documentation
[ ] I have added sufficient documentation in code

Testing

[ ] I have tested this code with the official test suite
[ ] I have tested this code manually

Manual tests
Please complete this section if you ran manual tests for this functionality, otherwise delete it
Documentation update
Please link the documentation update PR in this section if it's present, otherwise delete it
Additional comments
Please post additional comments in this section if you have them, otherwise delete it

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


FAQ

I'm putting together a FAQ wiki page. What questions do you have?

@sid3xyz Please checkout https://github.com/sigoden/aichat/issues/684. You can comment on that issue.

Hi @sigoden - I plan to perform rag against a git repository with markdown files. These files will change frequently over time. I do not see how to refresh the rag vector db with current content. Will you kindly explain? Chuck

How do we  contribute to the documentation?
Previously we can just make a PR for modifying README. But now the documentation is migrated to wiki, and it seems that wiki does not something similar to "PR"?

@cboecking  .rebuild rag is what you need.
@milanglacier You can open an issue or discuss it on Discord.

@milanglacier You can open an issue or discuss it on Discord.

Is it a concern that the documentation maintained in the wiki will be out of sync with the program itself since it is not maintained with git but maintained separately?

@milanglacier I will update the wiki when a new version is released.

@sigoden - FYI - I do not see the .rebuild reference in https://github.com/sigoden/aichat/wiki/RAG-Guide

Folks, If you have any questions about AICHat, you can first ask the AICHAT Wiki.
https://github.com/sigoden/aichat/assets/4012553/d4a42406-bf86-4894-a041-215678ab0246

Folks, If you have any questions about AICHat, you can first ask the AICHAT Wiki.
aichat-wiki.mp4

This is an absolutely fun and intuitive video demonstrating how to use RAG. Love it!

The WIKI page on RAG opens:
RAG can improve the efficacy of large language model (LLM) applications by leveraging custom data

AICHAT has a built-in vector database and full-text search engine, eliminating reliance on third-party services and providing ready-to-use RAG functionality.

It would be great to expand a little on this, for example, how do I work out how much it costs to use? I am not sure how the size of what I upload relates to the cost in tokens. What would it cost if I tried to uploads an entire PDF book for example? Explaining roughly how RAG works for beginners in the intro would be great :)

My question, how do you set the response format to json with aichat (with openai):
"response_format": {"type": "json_object"}
see: https://platform.openai.com/docs/guides/text-generation/json-mode

Cost in tokens

It is easy to estimate the cost.
One million tokens cost approximately $0.01 to $0.10 for embedding.
One million tokens are roughly equivalent to 750,000-800,000 words.
(750,000 words * 6 characters/word) bytes = 4.5 MB approximately

Explaining roughly how RAG works for beginners in the intro would be great

There are a lot of materials online, so I won't repeat them. If you are really interested, you might as well read the source code directly.
https://github.com/sigoden/aichat/blob/19f5f6c397470630d428792c47b1ba599c4ca192/src/rag/mod.rs#L374

how do you set the response format to json with aichat

No way. AIChat is a cli tool rather than a library, and it cannot take any parameters. If you really want to return json, you can ask for it in the prompt. In fact, json_format is not really needed.

how do you set the response format to json with aichat

No way. AIChat is a cli tool rather than a library, and it cannot take any parameters. If you really want to return json, you can ask for it in the prompt. In fact, json_format is not really needed.

Asking for it in the system prompt seems to work well.

Hi,
I don't have access to openai API in my country (Hong Kong). But I have a server in USfrom where I can access openai. I want to set up a proxy server or a client in aichat (local) config so that it can connect to aichat running in US. Is it possible to do so?
I tried --serve and setting the following in the config. It didnot work
# For any platform compatible with OpenAI's API
  - type: openai-compatible
    name: local
    api_base: http://localhost:8080/v1                # ENV: {client}_API_BASE
    api_key: xxx                                      # ENV: {client}_API_KEY
    chat_endpoint: /chat/completions                  # Optional

Folks, If you have any questions about AICHat, you can first ask the AICHAT Wiki.
aichat-wiki.mp4

I got this error when trying the rag feature on the aichat wiki :
Unable to run `rag-crawler https://github.com/sigoden/aichat/wiki/ /tmp/aichat-output-3b193bdd-5cb7-4618-9522-f62c01646c68`, Perhaps 'rag-crawler' is not installed?

Any hints @sigoden , rag-crawler is not installed automatically with cargo ?

Any hints @sigoden , rag-crawler is not installed automatically with cargo ?

rag-crawler is written in Node.js and should be installed with npm.
https://github.com/sigoden/aichat/blob/17fd7b326097d43a20c7332031bc2f250dd8d4d0/config.example.yaml#L75

Very funny prompt injection ^^

How can I activate a pager in the TUI that waits for input before scrolling down when the results overflow the screen height in aichat?

How can I activate a pager in the TUI that waits for input before scrolling down when the results overflow the screen height in aichat?
No way.

No way. Have you seen any other REPLs that have implemented this kind of feature?

Not directly I'd say. The pager that works well for example is the one in batcat. But I understand it is not an easy thing to do as we don't know the length of the generation in advance in streaming mode.
Concerning the GUI chats, most of them do not scroll down when they generate as it make it difficult to read moving lines.

Would be good to have where to put the config file in the FAQ! 🤣

How do you add multiple API providers?

Would be good to have where to put the config file in the FAQ! 🤣

@sammcj  ask wiki

How do you add multiple concurrent API providers, without adding yet another aggregator in front of this?

@dagelf Not supported. I don't think the CLI multiple concurrent API providers.

is it possible to do text embedding incrementally? i'm crawling a large site and always after nearly 75% i'm facing operation time out error

How to setup aichat --serve by env vars to enable multiple platforms support like using a config file? Should I set AICHAT_PLATFORM to only one fixed value?

How to setup aichat --serve by env vars to enable multiple platforms support like using a config file? Should I set AICHAT_PLATFORM to only one fixed value?

AICHAT_PLATFORM: Combined with {client}_API_KEY to run aichat without a configuration file (it will be ignored if a configuration file exists).
If you want to support multiple platforms, you must use a config file.


fix pvr gitref

Fix build issue: "Fetcher failure: Unable to find revision 0db5530636ee834bbfdac576eca19c77a93ed363 in branch bugfix/no-fakeroot-if-root even from upstream"

seems this is zero change? maybe you didnt pull latest?

this is a zero change PR.... closing. thx


[struct_pack] Add support for varint

Why
struct_pack should supprot variant code to zip the integer.
What is changing
Add struct_pack::var_int32_t,  struct_pack::var_int64_t,  struct_pack::var_uint32_t,  struct_pack::var_uint64_t.
For more infomation, please see document.
Example
  std::vector<struct_pack::var_int64_t> vec;
  for (int i = 0; i < 100; ++i) vec.push_back(rand() % 128 - 64);
  auto buf = struct_pack::serialize<
      std::string,
      serialize_config{.add_type_info =
                           struct_pack::type_info_config::disable}>(vec);
  CHECK(buf.size() == 4 + 1 + 1 * 100);

LGTM


Multiple devices

Hello, I'm trying to do the following: In oMyDevices.Push, I put the DeviceID of 2 devices. I want it to only execute the action when they are connected. It works. But I also wanted it to display an error when they are not connected. So I added the two separately in oMyDevices.Push, but when I pull a device it performs the action. Is there a way to do this?

Hi, Multiple devices on the same "line" is not supported right now. I'm working on an extended version of this script that will allow to also monitor processes and windows. It will also support group of devices/processes/windows. I will release it on GitHub if I'm able to finish it. I think you can subscribe to my profile and you will be notify if I'm releasing it.

Thank you for your excellent work. I can't wait, I'm subscribed :)

Thank you for your excellent work. I can't wait, I'm subscribed :)

I've updated DeviceIDPnP to support groups of devices and added new options. Try it out if you are interested!

Thank you for your excellent work. I can't wait, I'm subscribed :)

I've updated DeviceIDPnP to support groups of devices and added new options. Try it out if you are interested!

Thank you very much! I haven't been able to test it yet, but I will soon :)


Why I can't change variable/class/struct name in all files?

I just can change the name in the file that I'm writing. But when I open the definition file, I find the variable is still the old name. This made me tired, I need to modify each file individually.

I remember it working normally at beginning, but suddenly it doesn't work.

oh, do you mean this?
-- configure lua server (with special settings)
-- lspconfig["sumneko_lua"].setup({
lspconfig["lua_ls"].setup({
  capabilities = capabilities,
  on_attach = on_attach,
  settings = { -- custom settings for lua
    Lua = {
      -- make the language server recognize "vim" global
      diagnostics = {
        globals = { "vim" },
      },
      workspace = {
        -- make language server aware of runtime files
        library = {
          [vim.fn.expand("$VIMRUNTIME/lua")] = true,
          [vim.fn.stdpath("config") .. "/lua"] = true,
        },
      },
    },
  },
})

i used sumneko_lua at first, but it couldn't work, so i changed it to lua_ls. could you please give me some advise? sad..

the default vim.lsp.buf.rename works fine ? some server can rename whole project some server can't . which server do you used ?

oh, do you mean this?
-- configure lua server (with special settings)
-- lspconfig["sumneko_lua"].setup({
lspconfig["lua_ls"].setup({
  capabilities = capabilities,
  on_attach = on_attach,
  settings = { -- custom settings for lua
    Lua = {
      -- make the language server recognize "vim" global
      diagnostics = {
        globals = { "vim" },
      },
      workspace = {
        -- make language server aware of runtime files
        library = {
          [vim.fn.expand("$VIMRUNTIME/lua")] = true,
          [vim.fn.stdpath("config") .. "/lua"] = true,
        },
      },
    },
  },
})

i used sumneko_lua at first, but it couldn't work, so i changed it to lua_ls. could you please give me some advise? sad..

I used lua_ls to rename a variable . whole project of this variable changed.  what i mean is :lua vim.lsp.buf.rename() if this works fine. lspsaga rename can't work is lspsaga bug. if both not work then no bug here maybe server bug.


chore: reduce dependencies.

This PR reduce one dep and turn testing into its own module.
Comment on workspaces: I tried to do something like https://github.com/corazawaf/coraza/pull/422/files#r970198666 for this with no success. Also I think go.work is meant to be ephemeral and not a permanent thing (see for example Best practices and warnings in https://dev.to/gophers/what-are-go-workspaces-and-how-do-i-use-them-1643). Still I am not an expert on it.

Thank you for contributing to Coraza WAF, your effort is greatly appreciated
Before submitting check if what you want to add to coraza list meets quality standards before sending pull request. Thanks!

Make sure that you've checked the boxes below before you submit PR:

[ ] My code includes positive and negative tests.
[ ] I have an appropriate description with correct grammar.
[ ] I have read Contribution guidelines, maintainers note and Quality standard.
[ ] My code is properly linted and passes pre-commit tests.

Thanks for your contribution :heart:

Codecov Report

:exclamation: No coverage uploaded for pull request base (v3/dev@05d352c). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff            @@
##             v3/dev     #426   +/-   ##
=========================================
  Coverage          ?   73.06%
=========================================
  Files             ?      135
  Lines             ?     5787
  Branches          ?        0
=========================================
  Hits              ?     4228
  Misses            ?     1323
  Partials          ?      236

Flag
Coverage Δ

no-tinygo
73.11% <ø> (?)

overall
73.06% <ø> (?)

tinygo
71.14% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


web: consider adding onload event handler

Hello, did you consider onload event to be part of the “standard” set? It’s available for , , , , , ,

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Preserve 'use client' directives

Fixes #4933

Pulls in rollup-plugin-preserve-directives and adds it to all un-bundled builds to preserve 'use client' directives

See rollup issue https://github.com/rollup/rollup/issues/4699

Adds 'use client' to all files that should have it (I think)

This makes everything work as documented with Next app router, that is, developers should no longer need to:

Wrap our imports in "use client" themselves (just import and use Hydrate directly for example)
Import from @tanstack/query-core in RSCs (can now import directly from @tanstack/react-query)

For anyone reading along: Note that React Query-support for the Next app router is still experimental!

I tested it like this (basically quick version of the docs):
// Providers.jsx
// This wraps the entire app in root layout.jsx
"use client";

import { useState } from "react";
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";

export default function Providers({ children }) {
  const [queryClient] = useState(() => new QueryClient());

  return (
    <QueryClientProvider client={queryClient}>{children}</QueryClientProvider>
  );
}

// page.jsx
import { dehydrate, Hydrate, QueryClient } from "@tanstack/react-query";
import ClientComponent from "./ClientComponent";

export default async function ReactQuery() {
  const queryClient = new QueryClient();

  await queryClient.fetchQuery({
    queryKey: ["1"],
    queryFn: () => "Server",
  });

  return (
    <Hydrate state={dehydrate(queryClient)}>
      <ClientComponent />
    </Hydrate>
  );
}

// ClientComponent.jsx
"use client";

import { useQuery } from "@tanstack/react-query";

export default function ClientComponent() {
  const { data } = useQuery({
    queryKey: ["1"],
    queryFn: () => "Client",
    // Set staleTime to see that we get the "Server" output,
    // can later switch tabs to trigger revalidation and see we
    // get the "Client" output
    staleTime: 10000,
  });

  return <div>{data}</div>;
}

Codecov Report
Patch coverage: 97.67% and project coverage change: +0.31 :tada:

Comparison is base (ed7d9f8) 91.90% compared to head (5c925aa) 92.22%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #5161      +/-   ##
==========================================
+ Coverage   91.90%   92.22%   +0.31%
==========================================
  Files         111      111
  Lines        4188     4229      +41
  Branches     1083     1099      +16
==========================================
+ Hits         3849     3900      +51
+ Misses        318      308      -10
  Partials       21       21

Impacted Files
Coverage Δ

packages/query-core/src/query.ts
99.03% <ø> (ø)

...kages/react-query-devtools/src/styledComponents.ts
92.85% <ø> (ø)

packages/react-query/src/errorBoundaryUtils.ts
100.00% <ø> (ø)

packages/react-query/src/reactBatchedUpdates.ts
100.00% <ø> (ø)

packages/react-query/src/useBaseQuery.ts
95.45% <ø> (ø)

packages/react-query/src/useInfiniteQuery.ts
100.00% <ø> (ø)

packages/react-query/src/useIsFetching.ts
92.30% <ø> (ø)

packages/react-query/src/useIsMutating.ts
92.30% <ø> (ø)

packages/react-query/src/useMutation.ts
96.15% <ø> (ø)

packages/react-query/src/useQueries.ts
94.64% <ø> (ø)

... and 5 more

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

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

I've checked the output of the codesandbox preview build:

✅ /build/umd/index.development.js doesn't have any 'use client'
✅ /build/umd/index.production.js doesn't have any 'use client'
✅ /build/lib/Hydrate.esm.js has 'use client' at the top
✅ /build/lib/Hydrate.js has 'use client' at the top, followed by 'use strict'

This looks like what we want 👍 . Shipping it 🚢

I'm seeing a lot of warnings like this:
Module level directives cause errors when bundled, "use client" in "node_modules/.pnpm/@tanstack+react-query<EMAIL_ADDRESS>was ignored.

Occurs when bundling client output with Vite. Not sure what I need to change in my setup, to support the "use client" directive?

I'm seeing the same warnings in rollup:
packages/react-query/src/useMutation.ts (1:0)
1: 'use client'
   ^
2: import * as React from 'react'
3: import { useSyncExternalStore } from './useSyncExternalStore'
(!) Module level directives cause errors when bundled, 'use client' was ignored.
packages/react-query/src/useInfiniteQuery.ts (1:0)

it does make sense because when we bundle together into one file, we shouldn't keep 'use client'.

Won't that always be the case when consuming react-query? It will always be bundled into the application?

I don't know. I guess nextJs might consume the .mjs files separately and then decide based on that what is a client component and what isn't. I honestly don't know enough about how next does this 🤷

Great - Not just me that's confused about this new "use client" thing. Add it to the pile of problems we already have with CommonJS, ESM and module publishing. :(
Is this the right solution for the the react-query library? If the Next.js 13 app folder is still beta, should the ecosystem figure out the right way of handling use client in libraries as part of this?

@thebuilder It is confusing, and sorry for adding a bunch of warnings to your build! I suspect you are not using Server Components at the moment, so you can safely just ignore these warnings.
If you want to hide the annoying output, you can add a Rollup onwarn filter to hide them. I get why Rollup warns for this, but now that directives is becoming more common, it's also unfortunate.
The reason you are seeing this is because you are using the unbundled .mjs-version of React Query, which now includes 'use client' at the top of some files. It's good that you are using this version, because that means your bundler can remove any parts of React Query you are not actively using, so it doesn't get included in your final app-bundle!
Thing is though, Server Components can use this 'use client' directive to do even smarter code splitting. So yes, React Query will always get bundled into the application one way or another in the end, but for the unbundled builds that are a sort of "intermediary step", we want to provide all the "metadata" we can to bundlers to do smart things.
This is all based on a specification any bundler can implement too, so it's not Next.js specific even if they were first to implement it. It's definitely something that is up to us as an ecosystem to figure out, and different libraries might have different tradeoffs.

Oh, and just to answer your question specifically to avoid confusion:

Not sure what I need to change in my setup, to support the "use client" directive?

Since you are not using Server Components, you don't need to "support" the directive! Your bundler is warning because it doesn't know what to do with this. It's at the top of a file it wants to include in a bundle, and it can't safely hoist that directive to the entire bundle, so it's removing it instead, which is fine since you don't need it. It doesn't want to just remove things without warning though, which is why you are seeing this.

Thanks for the explanation. Since RSC is still only supported in a few select frameworks, like Next, it obviously is not something we can use with Vite or other frameworks.
I feel like this is something that Vite/Rollup should handle out of the box. My build output is going to be filled with warnings, especially if more libraries start adding 'use client'. Until that happens, it seems a bit premature to start adding it to library code?

I think about it the other way around though. Unless libraries start using this, what's the incentive to change/fix the behaviour? 😃
Again, sorry about the noisy warnings, adding an onwarn handler is a quick way to get rid of them. If it helps I can put together the specific config you need to add tomorrow?

Maybe it should be added directly to the https://github.com/vitejs/vite-plugin-react/tree/main/packages/plugin-react package instead?

Absolutely! I only suggest adding the onwarn as a stopgap. I think ultimately Rollup should only output this warning once per build instead of once per file and I think any React plugin that explicitly does not support RSCs could hide that warning by default.

I got many error warning when build production with React + Vite v4.2.1
Not use NextJS

I got many error warning when build production with React + Vite v4.2.1 Not use NextJS

I hot the same issue with React + Vite v4.1.4

same as  vite 4.2.1

Here is the vite.config.ts snippet that disables "use client" warnings
import { defineConfig } from "vite";

// https://vitejs.dev/config/
export default defineConfig({
  build: {
    rollupOptions: {
      /**
       * Ignore "use client" waning since we are not using SSR
       * @see {@link https://github.com/TanStack/query/pull/5161#issuecomment-1477389761 Preserve 'use client' directives TanStack/query#5161}
       */
      onwarn(warning, warn) {
        if (
          warning.code === "MODULE_LEVEL_DIRECTIVE" &&
          warning.message.includes(`"use client"`)
        ) {
          return;
        }
        warn(warning);
      },
    },
  },
});


image plane priors for position

This PR introduces image plane priors for the positions of objects. With these, it's possible to fix the position of a source to one of its visible images. This is done in the ini file by prefixing the prior with image, for example
source.x   = image unif 34 36
source.y   = image unif 63 65

The image plane prior is calculated in the set_params kernel which is called when parameters need adjustment. Given how rarely that happens relative to the deflection and surface brightness calculations, there should not be any noticeable impact on performance.
The implementation is restricted to objects that have subsequent parameters x and y (i.e. all of the current ones).

cc @fabiobg83 @rbmetcalf

Excellent!

I'm a bit peeved by the fact that this was possible with so little changes.

There is a problem with the different address spaces used for data. The way it's written seems to work on integrated cards, but not on those with dedicated memory.
I think I have to change the storage of the data objects to local memory before this can work.

I have rebased this onto the proposed changes of #202 as they should take care of the problems.


Fix automated tests

FIXES #548.
Changed import of get_platform to be from sysconfig
My one concern is that the original code had get_platform(None), and the new get_platform doesn't take an argument.  There is a cryptic comment force a platform tag, and I'm not sure if that is referring to the whole statement, or the None argument that I had to elide.  Can't find any documentation.

By default building a wheel for wgpu-py results in a platform agnostic wheel. This is because we don't compile anything. The rust binaries embedded in the wheel are precompiled and are considered data files as such.
However those binaries are of course not platform agnostic. So this implementation of finalize_options forces a platform tag to be set for the built wheel files. This allows us to build a wheel for every platform. That's what the comment means.
It's kind of a hack for a shortcoming in setuptools. There's no clean public API for this scenario.

Looking at the build logs, you seem to have done this correctly:
1 wheels produced in 1 minutes:
  wgpu-0.16.0-py3-none-manylinux_2_28_x86_64.whl   3,487 kB

I do think you should call the function from setuptools instead of sysconfig though, see the implementation here: https://github.com/pypa/setuptools/blob/46fe69938e2b88fcad78d2dfbcfc701a4cfa6b3f/setuptools/command/bdist_wheel.py#L67

Changed the get_platform to the one you recommended.  Making sure that tests still pass.

@Korijn
I'm not exactly sure what it is you want me to change.  The implementation of get_platform you pointed me to seems not to exist anymore.
I'm travelling for the next three days, so I'm not going to be able to do any more on this bug. I'm closing this pull request so that someone else can handle this.

As the error message you shared in #548 indicated, the function we import has moved to setuptools.
Deprecated the bdist_wheel module, as the code was migrated to setuptools itself
So we need to update setup.py to import get_platform from setuptools, that's all.

I just tried from setuptools import get_platform
  ImportError: cannot import name 'get_platform' from 'setuptools' (/tmp/pip-build-env-a5bs2y1b/overlay/lib/python3.11/site-packages/setuptools/__init__.py)

At this point, someone else is going to need to fix this.
On Tue, Aug 6, 2024 at 9:51 AM Korijn van Golen @.***>
wrote:

As the error message you shared in #548
https://github.com/pygfx/wgpu-py/issues/548 indicated, the function we
import has moved to setuptools:
Deprecated the bdist_wheel module, as the code was migrated to setuptools
itself
So we need to update setup.py to import get_platform from setuptools,
that's all.
—
Reply to this email directly, view it on GitHub
https://github.com/pygfx/wgpu-py/pull/549#issuecomment-2271725342, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABC2LIMIXZDYO6TPKWDY5SLZQD5HPAVCNFSM6AAAAABMBQAZGSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZRG4ZDKMZUGI
.
You are receiving this because you modified the open/close state.Message
ID: @.***>