Custom {{timestamp}} formatting, or change default to ISO8601

Current use of {{timestamp}} will provide a timestamp as: Sat Oct 26 2024 - 13:02:33
Would be preferable to have this as standard ISO8601 by default: 2024-10-26T13:02:33Z
Best would be to allow for customization, for example in a daily note you want perhaps to have the time only as the date would be redundant. Example could be {{timestamp(HH:mm)}}

Hello @elvarb !
Thanks for opening this feature request
To avoid rewritting everything and make regexes for the dates and time, I simply did the following:
Template:
**Timestamp tests:**

timestamp: {{ timestamp }}
timestampz: {{ timestampz }}
timestamp(HH:mm): {{ timestamp(HH:mm) }}
timestampz(HH:mm): {{ timestampz(HH:mm) }}

Output:
**Timestamp tests:**

timestamp: Tue Oct 29 2024 - 7:23:11 PM
timestampz: 2024-10-29T23:23:11.746Z
timestamp(HH:mm): 19:23
timestampz(HH:mm): 23:23

I implemented it for tracks and podcasts
Does it work for you ?

If you added one version of the timestamp that would only include the current day in YYYY-MM-DD format then users can combine that with the HH:mm timestamp to fit all their needs.

So I redid the approach this way (i think it covers everything, including what I had before)
Input
timestamp : {{ timestamp }}
timestamp(YYYY-MM-DD) : {{ timestamp(YYYY-MM-DD) }}
timestamp(YYYY-MM-DD HH:mm) : {{ timestamp(YYYY-MM-DD HH:mm) }}
timestamp(HH:mm) : {{ timestamp(HH:mm) }}

timestampz : {{ timestampz }}
timestampz(YYYY-MM-DD) : {{ timestampz(YYYY-MM-DD) }}
timestampz(YYYY-MM-DD HH:mm) : {{ timestampz(YYYY-MM-DD HH:mm) }}
timestampz(HH:mm) : {{ timestampz(HH:mm) }}

Output
timestamp : Wed Oct 30 2024 - 8:35:15 PM
timestamp(YYYY-MM-DD) : 2024-10-30
timestamp(YYYY-MM-DD HH:mm) : 2024-10-30 20:35
timestamp(HH:mm) : 20:35

timestampz : 2024-10-31T00:35:15.124Z
timestampz(YYYY-MM-DD) : 2024-10-31
timestampz(YYYY-MM-DD HH:mm) : 2024-10-31 00:35
timestampz(HH:mm) : 00:35

I used only one regex and handling all the cases.
Does it wprk better for you ?


Switched to fixed npm package versions

One of the npm packages has updated to a breaking version, causing the application to break on npm install.
Removing variable npm versioning, or using yarn for deterministic dependency management fixed this problem. This will mean that upgrades will need to be more planned on a package basis, but would remove problems with packages changing so quickly and make it easier for newer users trying it out.
I've included both quick changes to package.json as well as a yarn.lock file.

Thanks @DavidLi-Minxiao - I believe the issue (which has been fixed) was just the react-native-router-flux package.
I think it best to keep most packages auto-updating to the patch version - and remove any when they cause an issue (eg. our friends at react-native-router-flux).
Thanks heaps for submitting the PR - very much appreciated!!


NTRs for nucleus: mitotic nuclear bridge

NTR mitotic nuclear bridge
Definition: The narrow constricted region that forms around the anaphase spindle and links a segregating nucleus during closed mitosis.
Parent : nucleus
synonym: nuclear bridge (broad)
NTR mitotic nuclear bridge stalk
Definition: The region of a mitotic nuclear bridge proximal to the neck of each daughter nucleus
Parent: NTR mitotic nuclear bridge
NTR  mitotic nuclear bridge midzone
Definition: The central region of a mitotic nuclear bridge where basketless nuclear pores are corralled into a characteristic bulghe containing excess membrane.
Parent: NTR mitotic nuclear bridge
Citing
Closed mitosis requires local disassembly of the nuclear envelope.
Dey G, Culley S, Curran S, Schmidt U, Henriques R, Kukulski W, Baum B.
Nature. 2020 Sep;585(7823):119-123. doi: 10.1038/s41586-020-2648-3. Epub 2020 Aug 26.
PMID: 32848252

I would rejig the text definitions, especially for the first one, because "links a segregating nucleus" doesn't make sense (links it to what?).
id: GO:new1
name: mitotic nuclear bridge
def: A narrow constricted region of the nucleus that forms around the anaphase spindle during closed mitosis, and connects the main portions of the newly forming daughter nuclei.
synonym: "nuclear bridge" BROAD []
is_a: ?
relationship: part_of GO:0005634 ! nucleus
id: GO:new2
name: mitotic nuclear bridge stalk
def: Either of the regions of a mitotic nuclear bridge proximal to the main portion of each daughter nucleus. The nuclear envelope in the stalk regions is depleted of nuclear pore complexes.
is_a: ?
relationship: part_of GO:new1 ! mitotic nuclear bridge
id: GO:new3
name: mitotic nuclear bridge midzone
def: The central region of a mitotic nuclear bridge, distal to the main portions of the daughter nuclei. The midzone forms a bulge that is enriched in nuclear pores that lack baskets.
is_a: ?
relationship: part_of GO:new1 ! mitotic nuclear bridge

How about is_a 'cellular anatomical entity' - same as 'half bridge of spindle pole body' ?

+[Term]
+id: GO:0140510
+name: mitotic nuclear bridge
+namespace: cellular_component
+def: "A narrow constricted region of the nucleus that forms around the anaphase spindle during closed mitosis, and connects the main portions of the newly forming daughter nuclei." [PMID:32848252]
+synonym: "nuclear bridge" BROAD []
+is_a: GO:0110165 ! cellular anatomical entity
+relationship: part_of GO:0005634 ! nucleus
+created_by: pg
+creation_date: 2020-09-07T09:59:46Z
+
+[Term]
+id: GO:0140511
+name: mitotic nuclear bridge stalk
+namespace: cellular_component
+def: "Either of the regions of a mitotic nuclear bridge proximal to the main portion of each daughter nucleus. The nuclear envelope in the stalk regions is depleted of nuclear pore complexes." [PMID:32848252]
+is_a: GO:0110165 ! cellular anatomical entity
+relationship: part_of GO:0140510 ! mitotic nuclear bridge
+created_by: pg
+creation_date: 2020-09-07T10:06:23Z
+
+[Term]
+id: GO:0140512
+name: mitotic nuclear bridge midzone
+namespace: cellular_component
+def: "The central region of a mitotic nuclear bridge, distal to the main portions of the daughter nuclei. The midzone forms a bulge that is enriched in nuclear pores that lack baskets." [PMID:32848252]
+is_a: GO:0110165 ! cellular anatomical entity
+created_by: pg
+creation_date: 2020-09-07T10:08:02Z

ha ha good point. I originally put "links segregating nuclei" then made it non-plural without changing the context.


Feature/propagate arguments inside of loop scope

#147

Coverage increased (+0.04%) to 93.327% when pulling 3aa3e158bc857708734006b99936ace6662f00d2 on feature/propagate-arguments-inside-of-loop-scope into c55aab8ba548335cf0aa48cf696e93ac6345da8c on develop.

Coverage increased (+0.04%) to 93.327% when pulling d1eba6dab5c31046cc0209798f2a4f4fddb72563 on feature/propagate-arguments-inside-of-loop-scope into c55aab8ba548335cf0aa48cf696e93ac6345da8c on develop.

Coverage increased (+0.2%) to 93.513% when pulling 038cedd1094353c1c7994ae0f09735d3c0235a78 on feature/propagate-arguments-inside-of-loop-scope into c55aab8ba548335cf0aa48cf696e93ac6345da8c on develop.

Coverage increased (+0.2%) to 93.513% when pulling 1bba3e6b177ed20caba7aecaaec3d9aa6751a4fb on feature/propagate-arguments-inside-of-loop-scope into c55aab8ba548335cf0aa48cf696e93ac6345da8c on develop.

Coverage increased (+0.2%) to 93.516% when pulling ffbf8ecd97f03718ebfb7ee1369ec6238801376b on feature/propagate-arguments-inside-of-loop-scope into c55aab8ba548335cf0aa48cf696e93ac6345da8c on develop.

Coverage increased (+0.2%) to 93.516% when pulling cac03cf7c9019b29faa576621a0ae6e0e9f4b2c4 on feature/propagate-arguments-inside-of-loop-scope into c55aab8ba548335cf0aa48cf696e93ac6345da8c on develop.


View some images $('.images').viewer();  the selector should be images container

View some images
$('.images').viewer();

the selector should be images container,  i search the source code and find this, i suggest write this to read then make user easier

The selector also can be an image element if you only need to view a single image.


Fix CreateOrUpdateOrgSecret regression introduced in v53

CreateOrUpdateOrgSecret's API uses string for selected repository IDS while other APIs use int. This fixes the issue locally by implementing its own type.
fixes https://github.com/google/go-github/issues/2816

Also, in the future, please don't use force-push in PRs to this repo, as it makes reviewing more challenging to see what has changed since the last review.
See CONTRIBUTING.md for more details.  Thanks.

Thank you, @valbeat !
Merging.


fix: handle aws lambda timeout error handling better

refs 98745
Please see the log file attached in the ticket for more context.

The change for the production code looks good. Nice find!
I do not fully understand what benefit we gain from the changes to the test setup. Do we really need an extension mock that forwards data to the back end? Which cases in backend_connector can we cover with that setup, that we could not have covered with the previous setup?

^ discussed: We need two different processes (mock extension and mock backend) to test the case where the first request goes to the extension and the second one goes to the backend.


mac10.14.5 运行github的案例会报错

=== BUILD TARGET Runner OF PROJECT Runner WITH CONFIGURATION Debug ===
ld: warning: ignoring file /Users/zhuzhao/Desktop/nautilus-master/ios/Frameworks/UTDID.framework/UTDID, file was built for unsupported file format ( 0x56 0x65 0x72 0x73 0x69 0x6F 0x6E 0x73 0x2F 0x43 0x75 0x72 0x72 0x65 0x6E 0x74 ) which is not the architecture being linked (arm64): /Users/zhuzhao/Desktop/nautilus-master/ios/Frameworks/UTDID.framework/UTDID
ld: warning: ignoring file /Users/zhuzhao/Desktop/nautilus-master/ios/Frameworks/UTMini.framework/UTMini, file was built for unsupported file format ( 0x56 0x65 0x72 0x73 0x69 0x6F 0x6E 0x73 0x2F 0x43 0x75 0x72 0x72 0x65 0x6E 0x74 ) which is not the architecture being linked (arm64): /Users/zhuzhao/Desktop/nautilus-master/ios/Frameworks/UTMini.framework/UTMini
Undefined symbols for architecture arm64:
  "_OBJC_CLASS_$_UT", referenced from:
      objc-class-ref in AlibcTradeCommon(AlibcUTMiniAdapter.o)
  "_OBJC_CLASS_$_UTSecuritySDKRequestAuthentication", referenced from:
      objc-class-ref in AlibabaAuthExt(ALBBUTUserTrack.o)
      objc-class-ref in AlibcTradeCommon(AlibcUTMiniAdapter.o)
  "_OBJC_CLASS_$_UTOirginalCustomHitBuilder", referenced from:
      objc-class-ref in AlibcTradeCommon(AlibcUTMiniAdapter.o)
  "_OBJC_CLASS_$_AppMonitorMeasureValueSet", referenced from:
      objc-class-ref in AlibcTradeCommon(AlibcTradeAppMonitorAdapter.o)
  "_OBJC_CLASS_$_UTDevice", referenced from:
      objc-class-ref in AlibabaAuthExt(ALBBSecurityStorageImpl.o)
      objc-class-ref in AlibcLinkPartnerSDK(ALPJumpAppService.o)
      objc-class-ref in AlibcLinkPartnerSDK(ALPDegradeService.o)
      objc-class-ref in AlibcTradeCommon(AlibcTradeCommonSDK.o)
      objc-class-ref in OpenMtopExt(MtopSetupRequstBeforeFilter.o)
      objc-class-ref in OpenMtopExt(TBSDKConfiguration.o)
  "_OBJC_CLASS_$_AppMonitorAlarm", referenced from:
      objc-class-ref in AlibcTradeCommon(AlibcTradeAppMonitorAdapter.o)
  "_OBJC_CLASS_$_AppMonitorDimensionSet", referenced from:
      objc-class-ref in AlibcTradeCommon(AlibcTradeAppMonitorAdapter.o)
  "_OBJC_CLASS_$_AppMonitorMeasureSet", referenced from:
      objc-class-ref in AlibcTradeCommon(AlibcTradeAppMonitorAdapter.o)
  "_OBJC_CLASS_$_AppMonitorStat", referenced from:
      objc-class-ref in AlibcTradeCommon(AlibcTradeAppMonitorAdapter.o)
  "_OBJC_CLASS_$_AppMonitorDimensionValueSet", referenced from:
      objc-class-ref in AlibcTradeCommon(AlibcTradeAppMonitorAdapter.o)
  "_OBJC_CLASS_$_UTCustomHitBuilder", referenced from:
      objc-class-ref in AlibabaAuthExt(ALBBUTUserTrack.o)
  "_OBJC_CLASS_$_UTAnalytics", referenced from:
      objc-class-ref in AlibabaAuthExt(ALBBUTUserTrack.o)
      objc-class-ref in AlibcTradeCommon(AlibcUTMiniAdapter.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Could not build the precompiled application for the device.

ios不懂。

IOS这块是只写了代码实现没有写配置什么的对吗

应该不需要配置什么。反正我的客户用了是没什么问题。

是我手欠配置错了哈哈哈，确实不用配置啥


Add Wise 's Graduate Software Engineer job listing

This issue was created automatically by PowerAutomate
Company:
Wise
Logo:
https://d21buns5ku92am.cloudfront.net/69645/images/470455-Frame 39263-cdfad6-original-1677657684.png
Title:
Graduate Software Engineer
Application Link/Email:
https://grnh.se/8bf889271us - this is a referral link
Application Deadline:
2023-12-31
Employment Type:
Permanent (Graduate jobs)
Salary:
£45000 per annum
Location:
London, Remote (UK)
Industry:
Software Engineering
Company Overview:
Whether you’re sending money to another country, spending money abroad, or making and receiving international business payments, Wise is on a mission to make your life easier and save you money.
Since it was founded in 2010, 5,000+ people work at Wise, from 125 nationalities, in 17 global locations. You’ll be part of Wise’s global mission to build an open, fair, and human financial system – to make money without borders the new norm. Because people without borders need money without borders.
Requirements:

Work cross-functionally in squads who are vital to driving the mission of our business forward
Create clear and helpful interfaces, whilst maintaining consistency, maintainability and performance
Understand the challenges our customers face and set out to solve them

Your first 6 months:

You’ll onboard with the global Graduate cohort in one of our offices and learn the basics of being a Wiser
Understand how engineering works at Wise and what each team and tribe does. From Fraud to Anti Money Laundering teams – there are lots! Don’t worry, we’ll help you get acquainted through our WiseStart Engineering Bootcamp
You’ll spend some time understanding your team and tribe’s vision
Understand the Wise domain
Understand the problems your team are solving
Understand the tech culture, the detail of the tech stack and how we build stuff. We work in autonomous teams, on different stacks so you’ll need to understand the details

Here’s one of the grads to tell you more about what all that means! https://www.wise.jobs/2021/09/14/my-first-year-as-a-graduate-ios-engineer-at-wise/
Responsibilities:
Must haves:

You are graduating in 2023 or 2024 from a Bachelors or Masters degree. This might be in Computer Science, or any other STEM subject
You are able to start a full time graduate job in September 2024
Knowledge of computer science fundamentals including data structures, algorithms and software design
Familiarity of data models with SQL
Knowledge of working with RESTful Web Services
A basic knowledge in modern web technologies and a strong interest in web development
A self-started side project(s) that you are proud to talk about
Great communication skills and the ability to articulate complex, technical concepts to a non-technical audience
Curious, keen to learn and proactive by nature
You believe in and follow best coding practices and code reviews
You are open to and value feedback in order to improve
Eligible to work in London

Nice to haves:

Experience in web or microservice development, from a previous internship or project
Familiarity with any major programming languages like Java/JavaScript/Python/Kotlin/Swift (we are more focussed on your willingness to learn new technologies)
A strong product mindset and passion for user experience. You prioritise work with customers in mind, and make data-driven decisions to fix customer pain-points

Other information:
You can check out more about us, the interview process and how we work and why we do what we do at https://wise.jobs - feel free to reach out to me<EMAIL_ADDRESS>or https://mitchlui.dev/linkedin) if you have any questions!
Full form submission details (including contact details). NB: This is not accessible by everyone.
If you have questions about this listing, view the link above to see who to contact about this.

Listed


Fix some mistakes in typings

Codecov Report

Merging #63 into feature/type-specs will not change coverage.
The diff coverage is n/a.

@@                Coverage Diff                @@
##           feature/type-specs    #63   +/-   ##
=================================================
  Coverage                 100%   100%
=================================================
  Files                       5      5
  Lines                     102    102
  Branches                   26     26
=================================================
  Hits                      102    102

Continue to review full report at Codecov.

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


branch-2.0 add tests for jdbc catalog

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

#26608


Fixed the trackAllCaptures enum

It was "trackingAllCaptures". It should be "trackAllCaptures"
@Tratcher @BrennanConroy @natemcmaster

:shipit:


Console color doesn't work on windows

Trying this with a win10 machine, and it only prints the \x1b[32;1m version on cmd.exe shell (works with Powershell though).
e.g.
No conflicts detected 🎉
Suggestion would be using some other packages like https://github.com/sirupsen/logrus, https://github.com/mattn/go-colorable or https://github.com/fatih/color.

Closing this issue because it has to do with cmd.exe and Windows supports bash.
However, if someone figures out how to support colors for the Windows Command Line, a PR would be much appreciated :D


Revert "add CLI tab-to-autocomplete ability and implement for nrfconnect"

Reverts project-chip/connectedhomeip#13630
This causes a build failure here:
https://github.com/project-chip/connectedhomeip/runs/4962987772?check_suite_focus=true
@lmpprk as an FYI

thanks! it was a race between PRs, I can fix this quickly by pushing a change if that works better?

@lmpprk Sorry for the confusion, I do need to get the tree running, but if you put up a PR, with the fix from trunk, I can prioritize it coming in!

@lmpprk I will be online for the next hour, otherwise I can pick this up tomorrow AM! (FYI)

thanks no worries, mine can wait :) I'll sync and send it later. Thank you for the help in resolving!


[LIVY-622][LIVY-623][LIVY-624][LIVY-625][THRIFT][FOLLOWUP] Use ResultSet in catalog operations

What changes were proposed in this pull request?
This is a followup of #194 which addresses all the remaining concerns. The main changes are:

reverting the introduction of a state specific for catalog operations;
usage of ResultSet to send over the wire the data for catalog operations too.

How was this patch tested?
existing modified UTs

cc @jerryshao @yantzu

If there are no comments I'm going to merge in a couple of days.

CC @yiheng , please take a look.

+1

Looks like there's some conflicts need to be fixed.

Thank you all. Merging to master.


Always add decimal when converting float to string

So that
var a: float = 1
print(a)

prints
1.0

Makes working with numbers less confusing. I remember someone mentioned it around https://github.com/godotengine/godot-proposals/issues/1866
Closes https://github.com/godotengine/godot-proposals/issues/7894

Does this change apply automatically to floats within Vectors/Colors as well?

Hmm, it doesn't. Changing it might be not as easy :I

Ok, so I extended this to these types (in addition to floats): Vector2, Rect2, Vector3.
The original aim was to differentiate integer types from floats. As we don't have AABBi or Basisi I left these types untouched.

Also need to solve this problem:
print(5.0)                    # 5
print(5.0000001234)           # 5 <--
print("%.16f" % 5.0)          # 5.0000000000000000
print("%.16f" % 5.0000001234) # 5.0000001234000004

$ python3 -q
>>> print(5.0000001234)
5.0000001234

The precision problem doesn't look related.

The precision problem doesn't look related.

The problem is not with the precision of the numbers themselves, but that print doesn't display the number as precisely as it could. This can be seen by the fact that everything works with the formatting operator.

Ah, right. I don't know how to fix this tbh. I can't use is_equal_approx() in FLOAT_STRING, because it produces stuff like 1.00001.0.

Ok changed it. Here's the FLOAT_STRING as it was originally:
#define FLOAT_STRING(f) (rtos(f) + (Math::floor(f) == f ? ".0" : ""))

The new one is slightly less efficient, but maybe it doesn't matter that much.

We approved the change in a PR review meeting today, though we were concerned about the performance cost of the FLOAT_STRING define (doing a costly calculation twice + a find()).
A better option might be to use String::num_real() instead of String::num(), which already takes care of adding a .0 where relevant. I'm not sure how num() and num_real() differ aside from that and whether there would be some stuff handled by the one and not the other.

Rebased and reworked. I removed the macro and just changed usages of String::num_real() to use true as second argument (which makes the .0 always appear). I did it in the operators instead of stringify() method to avoid duplicating formats. As a result, some more classes are affected, e.g. Basis, which uses vectors.
print(1.0)
print(Vector2.ONE)
print(Rect2(Vector2.DOWN, Vector2.ONE))
print(Basis())

->
1.0
(1.0, 1.0)
[P: (0.0, 1.0), S: (1.0, 1.0)]
[X: (1.0, 0.0, 0.0), Y: (0.0, 1.0, 0.0), Z: (0.0, 0.0, 1.0)]

So I just noticed that changing Variant::stringify() will affect generated docs (as seen in failed CI, PI and TAU lose their precision). Not sure if that's ok 🤔

This seems to break the generated Mono glue:
/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/Generated/GodotObjects/VisualScript.cs(125,84): error CS1503: Argument 1: cannot convert from 'double' to 'float' [/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/GodotSharp.csproj]
/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/Generated/GodotObjects/VisualScript.cs(125,89): error CS1503: Argument 2: cannot convert from 'double' to 'float' [/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/GodotSharp.csproj]
/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/Generated/GodotObjects/TextParagraph.cs(351,110): error CS1503: Argument 1: cannot convert from 'double' to 'float' [/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/GodotSharp.csproj]
/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/Generated/GodotObjects/TextParagraph.cs(351,115): error CS1503: Argument 2: cannot convert from 'double' to 'float' [/home/runner/work/godot/godot/modules/mono/glue/GodotSharp/GodotSharp/GodotSharp.csproj]

CC @godotengine/mono

The C# bindings generator can be fixed by appending the f suffix.

If this implementation is causing problems, I could go back to what I did before, i.e. change formatting for each type individually; it would be less intrusive. Should I change it?

If this implementation is causing problems, I could go back to what I did before, i.e. change formatting for each type individually; it would be less intrusive. Should I change it?

I think this is still the right approach, we just need to fix:

Mono bindings to not rely on operator String() but another function / have their own conversion method to ensure that floats get the f suffix. That being said I'm puzzled that it works currently, as we do have some default values such as gravity with Vector3(0, -9.8, 0). Was it just by luck that currently no default value with non-whole number is used in Mono bindings? So this sounds to me like a pre-existing bug.
Change the behavior of num to do something similar to num_real, or add a dedicated method, so that explicit doubles can still be printed properly.

I can have a look at this now, or we can push the fix after this is merged if you prefer that.

Was it just by luck that currently no default value with non-whole number is used in Mono bindings? So this sounds to me like a pre-existing bug.

Indeed. To be fair, it was a quite safe assumption to make 😅

I can have a look at this now, or we can push the fix after this is merged if you prefer that.

Feel free to work on it now, this PR still needs some work to figure out the other problem with float/double pretty printing.

I pushed the fix :+1:

Something broke in the bindings after rebase.

There was a mix-up in the NodePath ctor, I also took the opportunity to add the fix for the new Vector4, Vector4i and Projection types that were added after neikeq's push.
diff --git a/modules/mono/editor/bindings_generator.cpp b/modules/mono/editor/bindings_generator.cpp
index 9855dc82c6..7c3fa28ef9 100644
--- a/modules/mono/editor/bindings_generator.cpp
+++ b/modules/mono/editor/bindings_generator.cpp
@@ -3272,6 +3272,13 @@ static String _get_vector3_cs_ctor_args(const Vector3 &p_vec3) {
 			String::num_real(p_vec3.z, true) + "f";
 }

+static String _get_vector4_cs_ctor_args(const Vector4 &p_vec4) {
+	return String::num_real(p_vec4.x, true) + "f, " +
+			String::num_real(p_vec4.y, true) + "f, " +
+			String::num_real(p_vec4.z, true) + "f, " +
+			String::num_real(p_vec4.w, true) + "f";
+}
+
 static String _get_vector2i_cs_ctor_args(const Vector2i &p_vec2i) {
 	return itos(p_vec2i.x) + ", " + itos(p_vec2i.y);
 }
@@ -3280,6 +3287,10 @@ static String _get_vector3i_cs_ctor_args(const Vector3i &p_vec3i) {
 	return itos(p_vec3i.x) + ", " + itos(p_vec3i.y) + ", " + itos(p_vec3i.z);
 }

+static String _get_vector4i_cs_ctor_args(const Vector4i &p_vec4i) {
+	return itos(p_vec4i.x) + ", " + itos(p_vec4i.y) + ", " + itos(p_vec4i.z) + ", " + itos(p_vec4i.w);
+}
+
 static String _get_color_cs_ctor_args(const Color &p_color) {
 	return String::num(p_color.r, 4) + ", " + String::num(p_color.g, 4) + ", " +
 			String::num(p_color.b, 4) + ", " + String::num(p_color.a, 4);
@@ -3316,7 +3327,7 @@ bool BindingsGenerator::_arg_default_value_from_variant(const Variant &p_val, Ar
 		case Variant::NODE_PATH:
 			if (r_iarg.type.cname == name_cache.type_StringName || r_iarg.type.cname == name_cache.type_NodePath) {
 				if (r_iarg.default_argument.length() > 0) {
-					r_iarg.default_argument = "(%s)\"" + p_val.default_argument + "\"";
+					r_iarg.default_argument = "(%s)\"" + p_val.operator String() + "\"";
 					r_iarg.def_param_mode = ArgumentInterface::NULLABLE_REF;
 				} else {
 					// No need for a special `in` statement to change `null` to `""`. Marshaling takes care of this already.
@@ -3375,8 +3386,11 @@ bool BindingsGenerator::_arg_default_value_from_variant(const Variant &p_val, Ar
 			r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
 			break;
 		case Variant::VECTOR4:
+			r_iarg.default_argument = "new Vector4(" + _get_vector4_cs_ctor_args(p_val.operator Vector4()) + ")";
+			r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
+			break;
 		case Variant::VECTOR4I:
-			r_iarg.default_argument = "new %s" + r_iarg.default_argument;
+			r_iarg.default_argument = "new Vector4i(" + _get_vector4i_cs_ctor_args(p_val.operator Vector4i()) + ")";
 			r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
 			break;
 		case Variant::OBJECT:
@@ -3451,7 +3465,11 @@ bool BindingsGenerator::_arg_default_value_from_variant(const Variant &p_val, Ar
 			if (projection == Projection()) {
 				r_iarg.default_argument = "Projection.Identity";
 			} else {
-				r_iarg.default_argument = "new Projection(new Vector4" + projection.columns[0].operator String() + ", new Vector4" + projection.columns[1].operator String() + ", new Vector4" + projection.columns[2].operator String() + ", new Vector4" + projection.columns[3].operator String() + ")";
+				r_iarg.default_argument = "new Projection(new Vector4(" +
+						_get_vector4_cs_ctor_args(projection.columns[0]) + "), new Vector4(" +
+						_get_vector4_cs_ctor_args(projection.columns[1]) + "), new Vector4(" +
+						_get_vector4_cs_ctor_args(projection.columns[2]) + "), new Vector4(" +
+						_get_vector4_cs_ctor_args(projection.columns[3]) + "))";
 			}
 			r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
 		} break;

Fixed. String::num() was removing all trailing zeroes.

Since this PR ended up improving the output of String::num() I noticed that this same code also reports back if a float/double is "nan" or "inf". For "inf" it also checks, using signbit(), if it's "+inf" or "-inf". I was wondering if it makes sense to also do this for zero values and nan values. I don't think this is just a theoretical improvement either. Let me give an example I bumped into recently. When you calculate the "arc tangent" of a number, an often used way to do that is using some implementation (see for example https://en.cppreference.com/w/cpp/numeric/math/atan2) of atan2(y, x). There are edge cases where this function will return a different value based on if one of the inputs was +0 or -0, therefore I think it makes sense if printing such a value would show the sign bit correctly. I'm not saying this should be part of this PR since it addresses a different issue, it's just that me reading this triggered the thought.

This PR breaks line numbers in the script editor. Line numbers are integers, they should not have .0 at the end.

I tested this on GodSVG, a project that heavily relies on float stringification, and here are the results:

The resulting SVG text looks quite different, but it is actually completely valid, just not the most minimal. This is a good sign that even in UI-heavy applications, this PR will not break things. GodSVG already has code to minify floats, which is why 0.0 becomes .0, because it expects any number with . is not a whole number. The float minifier will only require small tweaks to account for the trailing .0. But anyway, the project still works correctly exactly as-is.

This PR breaks line numbers in the script editor. Line numbers are integers, they should not have .0 at the end.

I changed String::num() to add trailing zero, because it takes double as argument. Seems like CodeEdit uses this method.

Thanks!

Does this only affect print or does it also change the behaviour of str in @GlobalScope? I relied on it to neatly display values when there were no decimal cases. It behaved exactly how I wanted, so is there no option to choose the behaviour?
What's the alternative now? Having to run step_decimals on every float value to determine wether to use "%.0f" or not?

Was there some research that went into this decision? The initial post has lots of upvotes, but it's naturally biased because everyone happy with the existing behavior would not come here.
In my opinion, this is a significant breaking change and the downsides should be considered carefully. The picture example is quite compelling here, it makes things harder to read and edit in cases where integers are needed.
Furthermore, while Python does it, I'm not sure if that's so relevant? GDScript syntactically resembles it, but for Godot gamedev other languages such as C# and C++ (or even Rust) are more relevant, and they all format floats without .0 by default.
Not saying there are no use cases for this, but besides "is it useful", we should probably consider practical implications, namely:

Should the default stay as-is and this new behavior be opt-in?
If not, is there an easy way to emulate the old behavior? What do we tell users whose code is now broken?
Independent of the above, can we let UI elements like matrices/vectors still use the old format for readability/editability purposes?

CC @aaronfranke @Calinou @Mickeon

Was there some research that went into this decision? The initial post has lots of upvotes, but it's naturally biased because everyone happy with the existing behavior would not come here.

It was a relatively brief, final discussion about it, but the PR had a whooping 3 years of time to cook. The consensus is that this should be merged as early as possible in the development cycle so that feedback can be gathered and evaluated as soon as possible, instead of breaking everything late when no one has time to adapt.
I myself anticipated this would have unforeseen consequences like the above. This is exactly what we need, and I appreciate it. Now the question is how to go about it.

Should the default stay as-is and this new behavior be opt-in?

Unsure of how. It only sounds feasible as a project setting, which sounds like a bad idea, as it would influence the result of all GDScript code.

If not, is there an easy way to emulate the old behavior? What do we tell users whose code is now broken?

For most cases, I can imagine that casting the float to an integer before displaying it would fix this, if the value would be equivalent.

Independent of the above, can we let UI elements like matrices/vectors still use the old format for readability/editability purposes?

Perhaps there could be toggle in SpinBox itself for this, although it sounds somewhat specific.

@Lippanon As I noted above, projects may need to change their code if they want to keep the same behavior, especially GodSVG. However, GodSVG keeps working, so amazingly, it didn't fully break compatibility, it just changed the visual appearance and resulted in sub-optimal SVG files, which will be easy for @MewPurPur to fix, and easy for other devs in their projects. The upside is huge: floats are stringified as float literals by default, making the type clear.

You claim it's easy yet provided no clean alternative. For example an RPG character page or dynamic tooltip for a skill or unit in an RTS, one can't simply cast to int, and having to call a function that checks the decimal cases and attributes the correct string formatting in gdscript is, in my opinion, not an acceptable alternative for a behaviour that has been the same for many years (if not since Godot's inception) and changed due a proposal that had ~25 thumbs-up (as mentioned by Bromeon nobody who likes the current behaviour will go out of their way to look for something that changes to disagree with it, and most users don't have time to check every proposal or PR).
I'll happily support the inclusion of this feature/new behaviour, but I don't support forcing such a change onto users. The only issue I see linked was this and their main problem was not being able to have sliders with integers.
The inspector in the editor seems cluttered to me now, harder to read, besides the aforementioned problem.

We absolutely should provide a function for the old behavior. It would be a static method in String, num_something.

changed due a proposal that had ~25 thumbs-up (as mentioned by Bromeon nobody who likes the current behaviour will go out of their way to look for something that changes to disagree with it, and most users don't have time to check every proposal or PR).

Users can retroactively leave thumbs-downs if they disagree with the change. While votes are not guaranteed to decide what we go with, it is still extremely useful to be able to measure user feedback in this way.

If not, is there an easy way to emulate the old behavior? What do we tell users whose code is now broken?

str(some_integer).trim_suffix(".0") should do the trick.

I am trending towards using the old behaviour, adding a new method for the new behaviour, and making each change case by case to the latest behaviour to keep backwards compatibility.

would it be possible to have a setting on Label/RichTextLabel that toggles this change on/off for floats set as text

No. You can't set float to a Label, only set the final String.
We can add a utility method that converts float to String and trims zero when necessary.

No. You can't set float to a Label, only set the final String.

Oh yeah, duh haha.

We can add a utility method that converts float to String and trims zero when necessary.

Would that look something like float_to_str(float_value) or str(float_value).trim_zero?

Regardless, we should provide methods for each style of behavior. Users shouldn't need to write str(float_value).trim_zero().
Would anyone like to propose APIs for these cases?

If this PR is kept, what should the non-.0 function be called?
If this PR is reverted, what should the .0 function be called?

I think this change causes my project that runs fine in 4.3 to throw errors in 4.4 dev4.
I have several data files generated by a separate C# app, where keys in a dictionary are ints that can be referenced by other data files. The trick is that C# exports JSON dictionaries with int keys as strings instead, and I have not found a way to disable/change that behavior, so when I go to do that lookup I end up with something like
DataDict[str(RefKey)]
which works fine in 4.3. In 4.4 dev4, these need to be changed to
DataDict[str(int(RefKey))]
because RefKey is now being interpreted as a float when it's read from JSON, even though there's no decimal on it anywhere.
This isn't a difficult change for me to make, but it's a surprise than this applies to all numeric values loaded from JSON.

var current_level: int = 12 print(current_level) would print 12 before this PR, but now prints 12.0
Example before this PR to work:
var current_level: int = 12
	while current_level > target_level:
		level_holder.get_node("Level" + String.num(current_level)).hide()

after this PR
var current_level: int = 12
	while current_level > target_level:
		level_holder.get_node("Level" + String.num(current_level).replace(".0","").hide()

would print 12 before this PR, but now prints 12.0

It doesn't

the number is int.
String.num() works with floats. Just use str().

Thank you for the swift response - was already changing my conversions so I am glad you replied before I finished.
It turns out that just using str() instead of String.num() doesn't worsen integers :+1:

I'm pretty sure this is the right thread---
Integers are getting the extra ".0" on them all over the place, in internal functions, even.
With sign(), specifically, it used to return 1, 0, -1.
Now it returns 1.0, 0, -1.0
And since 1 as an integer isn't the same thing as 1.0, anything that tries to, say, match a value with sign() will not work as intended.
Also, a related weird thing that is definitely happening on Linux...
If you have a variable like @export var neato_dictionary : Dictionary[String,Variant] { "thing_one" : 1, "thing_two" : 1.0, }
..if you iterate over the values in the dictionary, it'll recognize the former as an int, and the latter as a float.
But when you use str(neato_dictionary.values()[0] (or anything similar to get to that specific value), it'll print "1.0" not "1"

Note that sign() takes and returns Variant, so if you got float, it means your argument is float. Make sure the argument is int or use signi() instead.

Hello, I needed a feature included only in 4.4 version. So I switched my project. But I'm currently having a problem with this pull feature now. All integer values are returning wrong in WebApi responses. For example; item_id stored as 1 is now 1.0. When I set this responses in a "json" object, all i see is values like 1.0, 2.0 etc. Now I have to convert whole project responses prior to that which is 19k lines of codes. Isn't there an option to change this in a project worldwide?

Edit: I suspected something during serialization; while getting HTTP responses; I am using "JSON.parse_string(body.get_string_from_utf8()" as suggested in official documents. If ".0" appears at the end of integer values just because we are using "get_string_from_utf8" function, this needs to be fixed.

JSON doesn't have integer type, it only has a number type which is parsed as a float in most implementations. Some implementations have a way to force integers to be used when parsing JSON; see https://github.com/godotengine/godot-proposals/issues/8830.

Edit: I suspected something during serialization; while getting HTTP responses; I am using "JSON.parse_string(body.get_string_from_utf8()" as suggested in official documents. If ".0" appears at the end of integer values just because we are using "get_string_from_utf8" function, this needs to be fixed.

JSON doesn't have an integer type. Instead, it only has a number type which is parsed as a float in most implementations. Some implementations have a way to force integers to be used when parsing JSON; see godotengine/godot-proposals#8830.

Problem here is you can't deny lots of people using serialization and api results are always the same just because of a .0 extension to an integer value as i never saw before in any other languages. Now all data we have been using requires a deep refactoring. You should have confirmed this pull request after a little thinking about consequences.

JSON is a standard. It does not have "integers". You seem to have been misusing the standard. This PR's main goal was to make floats vs integers explicit and it surfaced that a lot of folks have been using one when they meant the other.

Oh sir, please read what i am telling up there and try to understand my point. JSON has integers or not, that's no matter. One way or another serialization is part of lots of projects. IF a PR effecting a common usage, you have to "think" about the consequences before applying it. This PR is affecting usage of serialization clearly because it seems like anything inside the "get_string_from_utf8" forced out to print ".0". In a very basic response of mine; sql stores the value as 1, WebAPI stores the value as 1. But Godot converts it to 1.0 during serialization. Just why? What would happen if you apply this PR to a language like Javascript. Can you imagine the chaos? Well I took a look at whole issues and repository logs here and I don't understand why Godot developers became so arrogant. Everyone has a meaningless fanaticism over things. Anyway I'm simply saying again; this PR made a method meaningless that has been used frequently.

As said above, the JSON specification does not distinguish between int and float, there is only Number. Regardless of the presence or absence of trailing .0 in a JSON string obtained using JSON.stringify(), after deserializing the string using JSON.parse_string() you always get a float. This has not changed, in 4.3 the same behavior, you can check this with typeof() or var_to_str().
@tool
extends EditorScript

func test(value):
    var decoded = JSON.parse_string(JSON.stringify(value))
    prints(value, type_string(typeof(value)),
            "->", decoded, type_string(typeof(decoded)))

func _run():
    test(1)
    test(1.0)

4.3:
1 int -> 1 float
1 float -> 1 float

master:
1 int -> 1.0 float
1.0 float -> 1.0 float

Although 1 == 1.0 evaluates to true, these are values of different types and in many cases they are considered unequal (dictionary keys, match patterns, etc.). This change is that other string conversions (str(), print(), and some others) now make this more obvious. The previous behavior was confusing and misleading (for instance, print({ 1: "a", 1.0: "b"}) prints { 1: "a", 1: "b" } in 4.3).
I'm sorry to hear that this seems to have been a significant nuisance for you. However, you probably already had hidden bugs due to Godot's non-obvious behavior. It's possible that the bugs didn't show up because of implicit type conversions, but it's too risky and fragile to rely on that. This change just exposed the real problem, the mismatch between your expectations and how it actually works.
Regarding conversions between native and JSON types, we recently added a new API that is intended to be as preserving and unambiguous a conversion as possible. Unfortunately the current implementation has several flaws, so I've opened PR #99765 to fix them.

Thank you for your reply sir. Honestly I had upgraded from 4.2 to 4.4. I literally had no idea, 4.3 also had this conversion. Thanks for the #99765


[WORK IN PROGRESS] Add shared multiplatform lib module

Towards #2049

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (e223801) 52.65% compared to head (a759bfb) 52.65%.
Report is 1 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff            @@
##             master    #2184   +/-   ##
=========================================
  Coverage     52.65%   52.65%
  Complexity     1210     1210
=========================================
  Files           314      314
  Lines          6108     6108
  Branches        636      636
=========================================
  Hits           3216     3216
  Misses         2550     2550
  Partials        342      342

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

This was experimental, one of several ideas to reduce code duplication. Final solution is still TBD.


Ubuntu CI build wheels [WIP]

Link the Issue(s) this Pull Request is related to.
#333
Summarize your change.
This PR introdces cibuildwheel instead of tox. The issue linked above talks about ci for windows and MacOS too. That will be added once it works as expected for Ubuntu.
Reference associated tests.
It doesn't test the adapters nor does it run and upload coverage at the moment. Only the core otio tests are run.
PS: I apologise for the number of commits. It took a long time to get this working.

I was looking at an example linked from the cibuildwheel docs, and looks like they have a specific action to build the wheels/upload them, triggered on release.  Maybe that is something we want to do as well?  I can say from experience that the manual upload-to-pypi thing we do right now is a painful part of the release process.

I was looking at an example linked from the cibuildwheel docs, and looks like they have a specific action to build the wheels/upload them, triggered on release.  Maybe that is something we want to do as well?  I can say from experience that the manual upload-to-pypi thing we do right now is a painful part of the release process.


Improve error handling when trying to import an invalid .mol file.

So I get my .mol file from user input in a web application. If the user inputs something invalid (e.g. a central carbon connected to 5 other carbons), I want to show the user a warning. Currently, Chem.MolFromMolBlock() prints a warning to the terminal when the molecule is invalid, e.g.
Explicit valence for atom # 0 C, 5, is greater than permitted

Trying to get the warning string into the Python code, I tried Chem.SanitizeMol(m), but I get the following error when doing that on an invalid molecule. When I do Chem.SanitizeMol(m)on a valid representation, it works fine.
    Chem.SanitizeMol(m)
Boost.Python.ArgumentError: Python argument types in
    rdkit.Chem.rdmolops.SanitizeMol(NoneType)
did not match C++ signature:
    SanitizeMol(RDKit::ROMol {lvalue} mol, unsigned int sanitizeOps=rdkit.Chem.rdmolops.SanitizeFlags.SANITIZE_ALL, bool catchErrors=False)

If I understand correctly, this is because Chem.MolFromMolBlock() returns None when the molecule is invalid. I believe it would be much more correct to throw an exception here, which the programmer may catch and handle as they see fit. "Silently" returning None is surely bad practice.

There are multiple views on what the correct behavior is when invalid input is provided. The RDKit's behaviour (in the Python wrappers) is to return None.
If you would like an exception to be raised when parsing or sanitization fails, it's pretty easy to do with something like this (not tested):
def mol_from_mb(mb):
  res = Chem.MolFromMolBlock(mb,sanitize=False)
  if res is None: raise ValueError('bad input')
  sanitFail = Chem.SanitizeMol(res,catchErrors=True)
  if sanitFail: raise ValueError(sanitFail)
  return res

Sure, I can do that. But the problem is I can't be more specific than "bad input", even though RDkit knows why my input is bad (it prints it to stderr, e.g. "can't kekulize" or "too many bonds" etc.). I need to get that information into the script.

OK, I solved it. When you add sanitize=False as you indicated, the function no longer returns Nonefor an invalid molecule. So the following works perfectly:
m = Chem.MolFromMolBlock(block,sanitize=False)
try:
    Chem.SanitizeMol(m)
    sm = Chem.MolToSmiles(m)
except ValueError as e:
    sm = str(e)

Now sm containes the SMILES if the user input is valid, and otherwise it contains the correct error message.
Closing.


Cache location is required when cache type is "S3"

Found a bug? Maybe our Slack Community can help.

Describe the Bug
A clear and concise description of what the bug is.
Cannot create code build with following settings:
cache_type = "S3"
cache_bucket_suffix_enabled = true
Expected Behavior
A clear and concise description of what you expected to happen.
Steps to Reproduce
Steps to reproduce the behavior:
This happens for the first time planing while suffix is not available

cache_type S3 and cache_bucket_suffix_enabled
terraform plan

cache_bucket_suffix_enabled  = false fix this
Screenshots
If applicable, add screenshots or logs to help explain your problem.
Environment (please complete the following information):
Anything that will help us triage the bug will help. Here are some ideas:

OS: OSX
Version [e.g. 10.15]

Additional Context
╷
│ Error: cache location is required when cache type is "S3"
│
│   with module.codebuild.aws_codebuild_project.default[0],
│   on modules/codebuild/main.tf line 292, in resource "aws_codebuild_project" "default":
│  292: resource "aws_codebuild_project" "default" {
│

@KaKeimei is this still an issue with the latest version ?
Please confirm and we can reopen.


Properties of therminol fluids

Dear Ian
I just installed the lates version of Matlab-CoolProp (5.0.7). It works properly with fluid like water. However, for fluids like thermino if gives me problems:
Here the screenshot:

Hope you can help me.
Regards,
Sebastian

The error is correct, the standard backend is a Helmholtz-energy-based one and that does not support T66. Use INCOMP::T66 instead. I am not mistaken, just T66 has never worked before.

Not in version 5 at least... It did in version 4 though.

It works! Thank you very much.

You are welcome. Please have a look at the documentation if you experience errors. Many things changed from version 4 to 5 and you might discover a few more rough edges. Please keep posting issues in case you find bugs.

... and please use the new repo at https://github.com/CoolProp/CoolProp next time.


Not working with material-ui v1.0.0-rc

The v1.0.0-rc.0 breaking change affects the material-ui-image component.
The diff
-import CircularProgress from '@material-ui/core/Progress/CircularProgress';
+import CircularProgress from '@material-ui/core/CircularProgress';

Yup, we will port everything in the coming weeks. A PR would be very appreciated. :+1:


Created a Web Page for predicting the stock price and also implemented concept of ensemble learning closes #132

Issue Reference:
Closes #132
Description of Changes:

I have created a web page for predicting stock prices using ensemble learning techniques.
The page allows users to input stock data and get predictions.
Ensemble learning models like Random Forest and Gradient Boosting have been implemented to improve prediction accuracy.
Additional features include data visualization and performance metrics to help users understand the predictions.

I have checked and I have done all the tasks

How I have done please review

please sync your repo with the latest changes

@balbirs22  you will also need to mention the steps in contributing.md

@balbirs22 please ensure that all other notebooks in the main repo that you are not working is present in your commit

@jvedsaqib I have ensured that as I only added or modified notebooks and not deleted any thing


infer -- javac -cp not considering deps in lib directory

I am trying to compile only one java file. It require a bunch of dependencies which are present in a lib folder. When I run the following command:
 javac -cp .:lib/* FileName.java
The file is getting compiled successfully. But when I run the same with Infer:
infer -- javac -cp .:lib/* FileName.java. It is throwing all the compilation errors (i.e. the dependencies in lib directory is not getting considered).  Is it intended ? or am I missing something ?
EDIT
I tried the same by specifying all the dependencies with -cp instead of putting lib/* directly. It worked this time. Not really sure why is it not working with lib/* directly.

Hi @rammanoj . You may have to quote the classpath so that the shell doesn't try to expand the wildcard.  For instance javac -cp ".:lib/*" FileName.java.

@ngorogiannis, Thanks for the reply. I've tried it with quotes, it behaved in the same manner!


[FEATURE] Add Notification Toasts when Products are Added or Removed to Cart

When customer adds a product to cart, a toast should appear at the right top area that 'Product has been added' and also when the product is removed from cart too. This gives a sense of confirmation to customers that the product has been successfully added/removed.
Would request you to assign this task to me under GSSOC '24
We can do it in below page:

One issue at a time buddy :) 👍🏼  @yashmandi

I can work on this issue first for now, and later on issue #56
Request you to assign this issue to me.

As of now, no need to manage the State, just show the Toast on click of Add to Cart. @yashmandi


[New Primitive] VirtualList

Feature request
Overview
Infinite scrolling has become some what of a standard on social media platforms. However the more dom elements you create as you scroll, the less performant your page will be. A commonly used technique is to re-use cells and substitute their content as the user scrolls while also increasing the paddingTop to increase the scrollbar. One can see this technique in practice in libraries like react-scrollable-list or react-window. This will be a great addition to the radix primitives family.
Examples in other libraries
react-scrollable-list
react-window
Who does this impact? Who is this for?
This component is probably targeted towards advanced users, yet if simple to implement, it should be benefitial to any user.
Additional context
This feature request was also requested on Discord
And there seems to be some public interest on it too :)

Thanks for this. As promised, we'll take a look asap. We're working on Select, Toast, and modality work right now, so it won't be possible for at least a couple months. But we'll consider it for the next cycle.

I just want to mention that react-virtuoso is not too hard to set up with ScrollArea.
https://codesandbox.io/s/wandering-browser-b5rcze?file=/App.js
Can be helpful for anyone who's still waiting for VirtualList and couldn't make other virtualization libraries work.

Is the sandbox still available? I would like to take a look but the link isn't working

@marcoripa96 Sorry, accidentally deleted the old sandbox. I just added a new one and posted the code in the comment as well.

Hi, I'm author of https://github.com/inokawa/virtua .
It's lightweight (about 10x lighter than react-virtuoso) and made with easy virtualization in mind. I hope it may help someone wants headless virtualization.
https://inokawa.github.io/virtua/?path=/story/advanced-with-radix-ui--default
https://github.com/inokawa/virtua/blob/main/stories/advanced/With radix-ui.stories.tsx

Hi, I'm author of https://github.com/inokawa/virtua .
It's lightweight (about 3x lighter than react-virtuoso) and made with easy virtualization in mind. I hope it may help someone wants headless virtualization.
https://inokawa.github.io/virtua/?path=/story/advanced-with-radix-ui--default https://github.com/inokawa/virtua/blob/main/stories/advanced/With radix-ui.stories.tsx

You saved me life 🫶

great lib @inokawa! appreciate the effort you made

Hey guys! Any updates on this component? I want to implement the pagination for my select component that uses Radix UI but I can't find the proper way to do that