Problems with sound and drive commands

I was using your libary for create2 and found it very usefull. Thanks!
But I was having some errors and after sending commands via Arduino to the robot directly, they disappeared. So I assume it's a bug in the libary code, even though I couldn't locate it.
The problems occur only sometimes. Without changing anything in the code or the setup, they just happen.

Roomba doesn´t drive straight but slightly turns to the left. Next time I turn it on, it drives perfectly straight as I wish. Same code, nothing changed.
Sometimes it takes longer for roomba to make a full turn.
Sometimes it plays the programmed songs nicely and the next time a note freezes while playing. Than the song stops and the next song isn’t played at all. (maybe a problem in the calculation of the songnotes?)

Until now I didn't ran into these problems when sending the commands directly.
(I was using serial with your libary now I'm using soft serial, maybe this could be part of the problem as well?)
I posted the problem together with my code and a video on stackexchange:
https://robotics.stackexchange.com/questions/21128/irobot-create-2-random-changes-in-driving-speed
I hope this is the right place to post comments and field reports - I'm new to github.
Best
Sebastian

Thanks for reaching out, been awhile since I touched this code but I can review the technical document again. Thats interesting that it works with normal serial but the software based serial seems to drop commands now and again. I will try to get to this some time this month :)

Hey,
I finished the roomba-project I was working on. I found out, that the weird behavior (not driving straight, taking different amounts of time for full turns) is not related to your code. It occurs also without your libary. I think it`s something in the basic programming or hardware of the roomba.
The only thing that really seems to be related to your libary is the playing of songs. After I made a code from scratch they played nicely and never failed to play.
Just as a final report :)

Thanks for the library. It was a good start for me.
As for the code to play songs: The definition of notes is not correct. The octave number for the notes is wrong. That makes songs play like the poor roomba is pretty drunk.
enum notes{
N_G1 = 31,
N_G1S = 32,
N_A1 = 33,
N_A1S = 34,
N_B1 = 35,
N_C1 = 36,      //should be C2
N_C1S = 37,    //should be C2S
N_D1 = 38,      //should be D2
N_D1S = 39,    //should be D2S
N_E1 = 40,      //should be E2
N_F1 = 41,      //should be F2
N_F1S = 42,    //should be F2S
N_G2 = 43,
N_G2S = 44,
N_A2 = 45,
N_A2S = 46,
*
*
*
And so on. I know, musicians don't seem to know how to count. See for example: https://www.inspiredacoustics.com/en/MIDI_note_numbers_and_center_frequencies
Or: https://www.google.com/search?q=midi+notes+numbers&rlz=1C1GCEA_enNL902NL902&oq=mid&aqs=chrome.0.69i59j69i57j69i65l3j69i61j69i60l2.2279j0j7&sourceid=chrome&ie=UTF-8
If the constant delay of 100ms used to calculate the length of the song is changed it seems to solve some songs not to be played. It's especially apparant when using a few long notes. Maybe the length of the notes isn't exact enough? Resulting in a mismatch in timing between Roomba and Microcontroller? It all depends on timers and dividers used in hardware I presume?


iOS 10 ESTBeaconConnection - CoreBluetooth XPC Error

Problem started with #233 on iOS 10 and that error was resolved, but now when calling ESTBeaconConnection *connection = [ESTBeaconConnection connectionWithProximityUUID:uuid major:major minor:minor delegate:self]; it throws... [CoreBluetooth] XPC connection invalid and doesn't connect to beacon

@ferologics Any updates on this? Something similar mentioned on the forums when monitoring. https://forums.estimote.com/t/swift-3-xcode-8-xpc-connection-invalid-issue/4822/9

@gnazarkin did you try acorsi's solution?

@ferologics Yes I tried it and didn't help

@gnazarkin do you have network, location and blue-tooth access enabled as well?

@ferologics Yes

Maybe useful from the apple developer forum.
Here the problem was caused, because CBPeripheralManager was not an instance variable
and so CoreBluetooth was not able to initialise successfully.
https://forums.developer.apple.com/thread/54510

new iOS 10.2 @gnazarkin  @ferologics
Other improvements and fixes
Adds notification support for HomeKit accessories including window coverings, occupancy, motion, door/window, smoke, carbon monoxide, and water leak sensors
Adds notification support for HomeKit accessories when software updates are available to HomeKit accessories
Improves Bluetooth performance and connectivity with 3rd party accessories

@gnazarkin did iOS 10.2 update change behaviour of the error in any way? Were you successful in resolving the problem?

@ferologics I'll give it a try as soon as I can as I still need to resolve the issue myself. Swamped with another project right now

I kept getting getting the "[corebluetooth] xpc connection invalid" error when trying to connect to beacons using the ESTDeviceManager with iOS 10. Connections worked fine with iOS 9 but with 10 it always timed out. I resolved the issue by adding "Privacy - Location When In Use Usage Description" permission to the plist file. @ferologics @gnazarkin

i have that in the .plist "Privacy - Location When In Use Usage Description" for iOS 10. The in app beacon ranging is still faulty.

That's strange, I have a separate app that ranges beacons and I haven't had any issues as of yet running on iOS 10. Although for that app I request the Always Usage @shattars3d

@aj-bartocci  Are you using the Estimote framework in your personal project? Or are you using the example Estimote project?

I'm using the framework in my own project @shattars3d


negative zero literal with decimal point produces JS syntax error

This won't happen on Windows 10, but happens on Wine-4.9 hosted by Linux. In both cases I'm using the Windows version of CLI. The compiler is installed separately to both enviroments.
Steps To Reproduce
Bridge version is 17.9.0
public class BasingBuilder
{   double test;
    public BasingBuilder()
    {   test = -0.0;
    }
}

This requires that the literal is zero, and has both a minus sign and a decimal point. Existence of leading zero and amount of decimal zeros are irrelevant.
Expected Result
ctor: function () {
                this.test = -0.0;
            }

Actual Result
ctor: function () {
                this.test = --.;
            }

Thanks for reporting. We will try and fix right away and include in the Bridge 17.10.0 release.


[bug][neoforge] Unbreakable swords instantly break

Version:
Sword In the Stone 2.1
NeoForge 21.0.148
Expected behaviour:
Setting the sword durability to 0 in the config makes the swords unbreakable.
Actual behaviour:
Setting the sword durability to 0 in the config makes the swords break after a single use.

Thanks for letting me know. It was caused by a strange change in vanilla's code when I ported from 1.20 -> 1.21. I will upload a fixed 1.21 jar soon.


[Day 11] - Generate from 52 different "cards"

https://github.com/Ostronkex/100-Days-of-Code-The-Complete-Python-Pro-Bootcamp-Solutions/blob/38d4bb20d46ed804c8a6ce147bcf7894ff7118f1/Day11/Blackjack.py#L97-L98
Currently a random number is generated meaning the same "card" or value can be generated more than four times (one for each color)

Fully solved in 365516a. Instead of subtracting 10 from the total, it now replaces the 11 in hand by 1 if the total is > 21 and then calculates the new total.

Solved in 365516a. Now picks a random value from a list of 52 "cards" via random.choice and then .remove() that generated value from the list.
However this removes the first index corresponding with that generated number, NOT the actual number/index generated. This doesn't affect the final product but will cause issues if the ASCII-art for specific cards is implemented.


add approval step to staking widget

This PR adds some UX improvements to the staking widget. Namely:

It adds the approval step to the staking widget itself as opposed to a banner
It adds an explicit call to action to "Enter an Amount" if no amount has been inputted

Closes #978

Looks great! Just one question:
I enters a non-zero amount in the staking widget and I noticed that the buttons for the 2-step flow were labeled with "Approve" and "Move Stake":

In this case, my account has never staked before so it feels a bit weird to me for the 2nd button to say "Move Stake" since the account doesn't have any stake to begin with. Should the 2nd button just say "Stake" instead?
The one scenario where I could see the 2nd button saying "Move Stake" is if the account is already staked, needs to approve an additional amount, and the orchestrator in the staking widget is different than the account's current orchestrator. That being said, I believe the explorer currently uses infinite approvals and in that case I don't think any account would end up in this scenario (unless it approved and staked during a time before the explorer supported infinite approvals).

In this case, my account has never staked before so it feels a bit weird to me for the 2nd button to say "Move Stake" since the account doesn't have any stake to begin with. Should the 2nd button just say "Stake" instead?

Ah nice catch. Yes this is a mistake. It should only say "Move Stake" if you're already staked and staking to a different orch. Will fix. Thanks!

@yondonfu fixed 👍


How to Upgrade Net Core 3.0 project to Net Core 3.1 in Visual Studio 2019 16.4 Preview 5

Issue Title
Be as descriptive as you can with your title.
General
Provide details on the problem you are experiencing including the .NET Core version, operating system version and anything else that is relevant.
Please provide a code sample for your issue if it is relevant, either inline, link to a gist (or similar) or add it as a zipped attachment.
For some issues, you will get a quicker and better response if you file it at a more specific .NET repo. For example, if the problem is with ASP.NET Core, you are encouraged to use the aspnet/home repo.

I have a Net Core 3.0 solution that I want to test under Net Core 3.1 but in Visual Studio 2019 16.4 Preview 5 under Application Properties the Target framework only shows .Net Core 3.0.  If I edit the project file(s), projects and solution will not compile stating:
Error		Project '..\RssImageProcessorX64\RssImageProcessorX64.csproj' targets 'netcoreapp3.1'. It cannot be referenced by a project that targets '.NETCoreApp,Version=v3.0'.

Error	NU1201	Project RSSImageX64ProcessorNetCore3 is not compatible with netcoreapp3.0 (.NETCoreApp,Version=v3.0). Project RSSImageX64ProcessorNetCore3 supports: netcoreapp3.1 (.NETCoreApp,Version=v3.1)

Error	NETSDK1045	The current .NET SDK does not support targeting .NET Core 3.1.  Either target .NET Core 3.0 or lower, or use a version of the .NET SDK that supports .NET Core 3.1.

If I create a new .Net Core 3.1 project in Visual Studio 2019 16.4 Preview 5 it lists both Net Core 3.1 and Net Core 3.0 under VS Application Properties, and allow downgrading the Net Core 3.1 to Net Core 3.0.
So for existing Net Core 3.0 solutions, how do I upgrade from Net Core 3.0 to Net Core 3.1 when using Visual Studio?
I am using Microsoft Visual Studio Enterprise 2019 Preview Version 16.4.0 Preview 5.0
VS Info:
Microsoft Visual Studio Enterprise 2019 Preview
Version 16.4.0 Preview 5.0
VisualStudio.16.Preview/16.4.0-pre.5.0+29512.175
Microsoft .NET Framework
Version 4.8.03761

Installed Version: Enterprise

Architecture Diagrams and Analysis Tools   00433-90100-63537-AA870
Microsoft Architecture Diagrams and Analysis Tools

Visual C++ 2019   00433-90100-63537-AA870
Microsoft Visual C++ 2019

.NET Portability Analyzer   1.1.10808.0
Evaluates portability of assemblies across .NET platforms.

Add New File   3.5.134
The fastest and easiest way to add new files to any project - including files that start with a dot

ADL Tools Service Provider   1.0
This package contains services used by Data Lake tools

ASP.NET and Web Tools 2019   16.4.455.40912
ASP.NET and Web Tools 2019

ASP.NET Web Frameworks and Tools 2019   16.4.455.40912
For additional information, visit https://www.asp.net/

Atomineer Pro Documentation   1.0
Source-code documentation-comment creation and maintenance, and other documentation-related tools.

Automatic Versions   2.0.48
Provides tools for managing assembly versions.

Azure App Service Tools v3.0.0   16.4.455.40912
Azure App Service Tools v3.0.0

Azure Data Lake Node   1.0
This package contains the Data Lake integration nodes for Server Explorer.

Azure Data Lake Tools for Visual Studio   2.4.2000.0
Microsoft Azure Data Lake Tools for Visual Studio

Azure Functions and Web Jobs Tools   16.4.455.40912
Azure Functions and Web Jobs Tools

Azure Stream Analytics Tools for Visual Studio   2.4.2000.0
Microsoft Azure Stream Analytics Tools for Visual Studio

C# Tools   3.4.0-beta4-19562-01+1cb14195ed43eefdf7f9de59140ff6db70eea76e
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

CodeRush for Roslyn   <IP_ADDRESS>
DevExpress CodeRush for Roslyn package.

CodeRush for Roslyn Tool Windows   <IP_ADDRESS>
DevExpress CodeRush for Roslyn Tool Windows package.

Comment Remover   1.3.25
Remove all comments in any file with a click of a button. Can also remove #regions and preserve XML Doc comments.

Common Azure Tools   1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

ConvertAppToCore3Command Extension   1.0
ConvertAppToCore3Command Visual Studio Extension Detailed Info

Cookiecutter   16.4.19310.1
Provides tools for finding, instantiating and customizing templates in cookiecutter format.

Dotfuscator Community Edition   <IP_ADDRESS>14-e0e25f754
PreEmptive Protection - Dotfuscator CE

Extensibility Message Bus   1.2.0 (d16-2@8b56e20)
Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration.

Fabric.DiagnosticEvents   1.0
Fabric Diagnostic Events

GhostDoc   19.3.19260.0
Generate XML Comments from your code, maintain clean and up-to-date documentation, produce help documentation in multiple formats, use intelligent source code Spell Checker in Visual Studio.

IntelliCode Extension   1.0
IntelliCode Visual Studio Extension Detailed Info

Microsoft Azure HDInsight Azure Node   2.4.2000.0
HDInsight Node under Azure Node

Microsoft Azure Hive Query Language Service   2.4.2000.0
Language service for Hive query

Microsoft Azure Service Fabric Tools for Visual Studio   16.0
Microsoft Azure Service Fabric Tools for Visual Studio

Microsoft Azure Stream Analytics Language Service   2.4.2000.0
Language service for Azure Stream Analytics

Microsoft Azure Stream Analytics Node   1.0
Azure Stream Analytics Node under Azure Node

Microsoft Azure Tools   2.9
Microsoft Azure Tools for Microsoft Visual Studio 2019 - v2.9.21016.1

Microsoft Continuous Delivery Tools for Visual Studio   0.4
Simplifying the configuration of Azure DevOps pipelines from within the Visual Studio IDE.

Microsoft JVM Debugger   1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

Microsoft Library Manager   2.0.87+gbb515bf382
Install client-side libraries easily to any web project

Microsoft MI-Based Debugger   1.0
Provides support for connecting Visual Studio to MI compatible debuggers

Microsoft Visual C++ Wizards   1.0
Microsoft Visual C++ Wizards

Microsoft Visual Studio Tools for Containers   1.1
Develop, run, validate your ASP.NET Core applications in the target environment. F5 your application directly into a container with debugging, or CTRL + F5 to edit & refresh your app without having to rebuild the container.

Microsoft Visual Studio VC Package   1.0
Microsoft Visual Studio VC Package

Mono Debugging for Visual Studio   16.5.23 (1b51e8c)
Support for debugging Mono processes with Visual Studio.

NuGet Package Manager   5.4.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/

Office Developer Tools for Visual Studio   16.0.29417.02
Microsoft Office Developer Tools for Visual Studio

Open in Visual Studio Code   1.4.46
Adds a menu command that lets you open any solution, project, folder and file in Visual Studio Code.

OzCodePackage Extension   1.0
OzCodePackage Visual Studio Extension Detailed Info

ProjectServicesPackage Extension   1.0
ProjectServicesPackage Visual Studio Extension Detailed Info

Python   16.4.19310.1
Provides IntelliSense, projects, templates, debugging, interactive windows, and other support for Python developers.

Python - Conda support   16.4.19310.1
Conda support for Python projects.

Python - Django support   16.4.19310.1
Provides templates and integration for the Django web framework.

Python - IronPython support   16.4.19310.1
Provides templates and integration for IronPython-based projects.

Python - Profiling support   16.4.19310.1
Profiling support for Python projects.

Snapshot Debugging Extension   1.0
Snapshot Debugging Visual Studio Extension Detailed Info

Snippet Designer   1.6.5
Snippet Designer is a Visual Studio plug in which allows you to create and search for snippets inside the IDE

SQL Server Data Tools   16.0.61911.11100
Microsoft SQL Server Data Tools

Syncfusion ASP.NET Core (Essential JS 1) Project Templates   <IP_ADDRESS>
Provides project templates for creating an ASP.NET Core Web Application using Syncfusion Essential JS 1 components.

Syncfusion ASP.NET Core (Essential JS 2) Project Templates   <IP_ADDRESS>
Provides project templates for creating an ASP.NET Core Web Application using Syncfusion Essential JS 2 components.

Syncfusion ASP.NET MVC (Essential JS 2) Project Templates   <IP_ADDRESS>
Provides project templates for creating ASP.NET MVC (Essential JS 2) Web Applications using Syncfusion components.

Syncfusion UWP Project Templates   <IP_ADDRESS>
Project to create an Universal Windows Application using Syncfusion Products.

Syncfusion WPF Project Templates   <IP_ADDRESS>
Provides Project Templates to add Syncfusion WPF Project along with corresponding configurations.

Syncfusion.ASP.NET.Extension   <IP_ADDRESS>
Provides Project Templates to create Syncfusion ASP.NET web sites.

Syncfusion.WindowsForms.Package   <IP_ADDRESS>
Provides Item/Project Templates to add Syncfusion Windows Forms Item/Project along with corresponding configurations.

SyncfusionMenu Extension   1.0
SyncfusionMenu Visual Studio Extension Detailed Info

Syntax Visualizer   1.0
An extension for visualizing Roslyn SyntaxTrees.

Tabs Studio   4.5.0
The document tabs manager.

TermWindow Extension   1.0
TermWindow Visual Studio Extension Detailed Info

ToolWindowHostedEditor   1.0
Hosting json editor into a tool window

TypeScript Tools   16.0.11031.2001
TypeScript Tools for Microsoft Visual Studio

Visual Basic Tools   3.4.0-beta4-19562-01+1cb14195ed43eefdf7f9de59140ff6db70eea76e
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual F# Tools 10.4 for F# 4.6   16.4.0-beta.19504.1+e3676d75d501a2df6789ad0f5ebc310bc2cee6b5
Microsoft Visual F# Tools 10.4 for F# 4.6

Visual Studio Code Debug Adapter Host Package   1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio

Visual Studio Color Theme Editor   1.0
Allows users to create and edit Visual Studio themes. Themes can customize colors used for menus, toolbars, tabs, titlebars, the text editor, and other environment colors.

Visual Studio Container Tools Extensions (Preview)   1.0
View, manage, and diagnose containers within Visual Studio.

Visual Studio Tools for Containers   1.0
Visual Studio Tools for Containers

Visual Studio Tools for Kubernetes   1.0
Visual Studio Tools for Kubernetes

VisualStudio.DeviceLog   1.0
Information about my package

VisualStudio.Mac   1.0
Mac Extension for Visual Studio

Workflow Manager Tools 1.0   1.0
This package contains the necessary Visual Studio integration components for Workflow Manager.

Xamarin   <IP_ADDRESS>1 (d16-4@4593f70)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer   <IP_ADDRESS>7 (remotes/origin/d16-4@2fad68f52)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin Templates   16.4.25 (579ee62)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.

Xamarin.Android SDK   <IP_ADDRESS> (d16-4/5e2fd06)
Xamarin.Android Reference Assemblies and MSBuild support.
    Mono: e1ef774
    Java.Interop: xamarin/java.interop/d16-4@c4e569f
    ProGuard: xamarin/proguard/master@905836d
    SQLite: xamarin/sqlite/3.28.0@46204c4
    Xamarin.Android Tools: xamarin/xamarin-android-tools/master@9f4ed4b

Xamarin.iOS and Xamarin.Mac SDK   <IP_ADDRESS> (44c08f2)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.

Note: I also reported this in feedback to Visual Studio.

@SFC-Sarge is this still an issue? If not, can you provide a sample project? Thanks.


422 Unprocessable Entity

I received the following error: any ideas?
Loaded options from default config file in '[redacted]/config.ini'
y
You are about to add to 'glauth/glauth':
 * 11 new issues
 * 4 new comments
 * 0 new milestones
 * 4 new labels
Are you sure you wish to continue? [Y/n] ERROR: There was a problem importing the issues.
422 Unprocessable Entity
DETAILS: Validation Failed

same as #28 ?


fix: add annotations route without verse slug

used when an annotation only includes special characters

Could you give an example of a Genius URL that uses this pattern?


MIL-STD-2525D Issues

This issue is to track issues found in the draft of MIL-STD-2525D for @abouffard to take back to the committee (@mepler). Some of these may not be issues at all, but in the review they seemed counter-intuitive, so I am listing them here.

Location
Page
Issue

A-XIX
57
Acquisition is mispelled (130302)

A-XIX
58
Equipped is mispelled (140105)

A-XXV
72
Mine is not capitalized (210200)

A-XLIV
122
General is not capitalized (29)

D-II
165
Field AR (Special Designator) should have a designated location

F-II
328
Sea Subsurface does not have all of the Sea amplifiers (i.e. Speed, Location)

G-II
354
Offset Location Indicator is Field S, not Q

D-XIII
272
Law Enforcement (20112100) should list an Icon Type.

D-XIII
274
Emergency Operation (20112200) should list an Icon Type.

D-XIII
277
Economic Infrastructure Asset (20120204) should be Icon Type: Main

D-XV
294
Symbol Set Code should be 20

D-XV
294
Descriptions should only be listed once

D-XV
294
All modifiers should have a Category

I-II
737
Shoreline Protection - EntitySubType and EntitySubSubType?

I-II
738
Hydrography:Aids to Navigation - Error! Bookmark not defined.

@abouffard ensuring that these are still an issue and creating a CP.

Above errors have been reviewed, in light of the June 10th final pdf version of 2525D, and a new change proposal has been authored and submitted, recommending these errors be fixed in 2525D Change 1.
https://github.com/Esri/joint-military-symbology-xml/blob/master/documentation/change_proposals/CP_Esri_022415-1.doc added in #173
@joebayles , I recommend we close this issue and continue tracking these errors via the CP process.

Verified.


Update sqlclient-driver-support-lifecycle.md

Add latest patch versions

@David-Engel
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Update settings for syntax highlighting

Summary
This adds the tree-sitter config to package.json to run tree-sitter highlight
Requirements (place an x in each [ ])

[x] I've added tests for any new code and ran npm run test-corpus to make sure all tests pass.
[x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.

Hmm, not sure why this test is failing. It passes locally. I'll do some investigation.


Allow comparisons between integers of different types

Rendered
Edit: Fixed typo in implementation description (signed->unsigned), added an examples.
Edit: Mentioned that Ord and Eq changes as optional, added an example.
Edit: Added widening to signed as a more efficient way to compare small signed/unsigned pairs.
Edit: Added note about branching in implementation. Explicit branching removed from example. Potential security risks mentioned.

It is completely unnecessary (and impossible due to backwards compatibility) to change Ord and Eq. Rather, the RFC should be about adding the missing implementations of PartialOrd<T> and PartialEq<T>.

It is completely unnecessary (and impossible due to backwards compatibility) to change Ord and Eq.

I suddenly found that operator overloading only requires you to implement partial traits. Makes sense in hindsight. You're absolutely right, changing Ord and Eq is unnecessary.
It doesn't look impossible though. It obviously should be defined in backward compatible form:
pub trait Eq<Rhs = Self>: PartialEq<Rhs> { }

pub trait Ord<Rhs = Self>: Eq<Rhs> + PartialOrd<Rhs> {
    fn cmp(&self, other: &Rhs) -> Ordering;
}

But anyway, you're absolutely right, it's more about missing implementations.

It doesn't look impossible though. It obviously should be defined in backward compatible form
I didn't actually know that was possible. My bad. :)

Any chance we could shoehorn in more operators?
In particular, there no reason whatsoever for AddAssign<T> and friends not to be implemented for at least the types where T: Into<Self>.

@le-jzr You just meant that informally as "those specific numeric types which implement Into<Self>, i.e. which are cleanly promotable", right? Actually using where T: Into<Self> in the impl sounds like potentially a bad idea if there are any surprising impls for non-numeric types (as far as I can tell the IpV4Addr impl only goes in the other direction, which is what I originally thought of, but there may be others).

Yes, I was thinking of primitive integer types only.

I thought about compound operators too, but I think it's a separate change.
You can find some discussion here.

Really old discussion about this and other ideas, for the record: https://internals.rust-lang.org/t/implicit-widening-polymorphic-indexing-and-similar-ideas/1141

By the way,

The rest of rust math prohibits mixing different types and requires explicit casts. Allowing heterogeneous comparisons (and only comparisons) makes rust math somewhat inconsistent.

This is not entirely true. Shl and Shr traits are implemented for all right-hand integer types. Div has very similar to those, in asymmetry and closedness, but is only implemented for Self. So the math is already somewhat inconsistent in this regard.

If the signed integer in a signed-unsigned pair is the larger type, converting the unsigned integer to the larger type and then comparing would avoid the branch.  I don't know enough about assembly to know if this is what already happens at that level when comparing integers of different sizes, but it feels like it ought to be.
There might be something to be said for always converting signed-unsigned pairs where the signed type isn't the larger type to an integer that's one level above it,  then comparing.  This would work for everything through 32 bits, though I imagine doing it from 64 to 128 might be prohibitively expensive.
The solution proposed in this RFC concerns me because it adds an invisible branch inside a comparison of primitive types.  Given that Rust is a systems language, being able to tell where your code might start causing tons of branch mispredictions is valuable for performance optimization.  This approach may also prevent performance of autovecctorization through obfuscation of those patterns.  It would be incredibly hard to teach people about this pitfall because we would have to explain these issues, neither of which are exactly newbie-level.  The only way to see that it's happening is to read assembly.  Putting it in the nomicon makes it hard to find.
If I had my way, I would like Rust to allow comparison and mathematical operations between all pairs of signed types and all pairs of unsigned types, but not to invisibly cross between them.  Essentially C's rules without the invisible viral infecting caused by unsigned.
I'm mostly playing devil's advocate.  This RFC would make my personal code more convenient.   Nonetheless I have done some high performance programming and SIMD, and having otherwise-invisible branches just show up like this concerns me.

It would be incredibly hard to teach people about this pitfall because we would have to explain these issues, neither of which are exactly newbie-level.

Micro-optimization of generated assembly is not exactly a newbie-level concept either. I think that if someone is advanced enough to care about branch misprediction, they can easily understand that u64 < i64 requires two branches to work correctly.
Other than that, most cases can be solved just by sign-extending both sides, and I don't see a reason why that wouldn't happen whenever possible.

If the signed integer in a signed-unsigned pair is the larger type, converting the unsigned integer to the larger type and then comparing would avoid the branch. I don't know enough about assembly to know if this is what already happens at that level when comparing integers of different sizes, but it feels like it ought to be.

You're right. Widening to signed will likely be faster up to machine word size.
Branch prediction will likely be bad regardless. In most cases there's already a branch there, after all.

Do not propose a particular implementation in the RFC and you’ll avoid the unnecessary yet infinite bikeshed. Instead list the requirements and all that sort of stuff.
Implementors will be able to figure out the best implementation for such a trivial feature themselves.

Also, PartialEq and PartialOrd are not exactly what is used to do comparisons on primitive built-in types. Instead the compiler translates the operations directly. This means that this RFC is only half-done if you are proposing an exact implementation.

Do not propose a particular implementation in the RFC and you’ll avoid the unnecessary yet infinite bikeshed. Instead list the requirements and all that sort of stuff.

You're probably right. I just felt that the fact that it can be done without overhead in many cases is important enough.

Also, PartialEq and PartialOrd are not exactly what is used to do comparisons on primitive built-in types.

Rust code snippets are just an illustration of approach, not an exact implementation.
I think it's quite obvious that this rfc changes the way built-ins comparisons are handled internally.

At first, I wanted to object to this, because I like how Rust prevents mixing integer types, and avoids automatic promotions/demotions, unlike C.  However, if the compiler only does safe comparisons, never any that could allow overflow or similar, then I don't have a fundamental objection, and I like the idea of helping the user do the right thing rather than forcing a potentially incorrect use of as.
What algorithm would this use to compare i64 and u64?

What algorithm would this use to compare i64 and u64?

It has to be something along these lines:
fn less_than(a: i64, b: u64) -> bool {
    if a < 0 {
        true
    } else {
        (a as u64) < b
    }
}

Not sure about exact asm implementation, but it will be more expensive than regular comparisons.

@le-jzr
I kind of disagree.  In C/C++, there are rules of thumb: don't put if statements inside for loops if you can avoid it, for instance.  Simple loops that don't do funny tricks are more likely to vectorize.  Etc.  You don't have to read assembly to take advantage of these ideas.  Benchmarks can show you if you're successful.
When looking at an integer comparison, it is useful to obviously know what is going on.  I don't like the idea of implementations that do potentially nonobvious things with primitive types that presumably map directly to the hardware.
Let's assume that I am advanced enough to read assembly.  Where do we document this?  How do I find out why my assembly is odd?  When I look at Rust vs. equivalent C and have the knowledge to know what kinds of patterns should be efficient, how do I find out what strange difference of Rust makes it not work?  How do I find the one spot that putting an explicit cast somehow has better performance than letting the compiler implicitly do it and understand why?
If we want to do this, Rust should develop and have clearly documented implicit integer conversion rules.  Dropping the implementation from the RFC is fine, just so long as what's going on remains as obvious as it does in C/C++ (or better, if we don't let unsigned start infecting and screwing up seemingly-straightforward computations).  Specifically, I'd advocate for dropping i64 to u64 and potentially not allow promotion to i128.  I wouldn't advocate for dropping implementation from the RFC or the discussion; this is the first time I've seen an RFC where I think that's actually important.

You can also go with (a < 0) | ((a as u64) < b).

@camlorn
Comparing any signed integer with register-sized unsigned integer needs more instructions. Using anything bigger than gp register (e.g. i128) needs more (or at least different) instructions. Those are your rules of thumb, if you need them. It has nothing to do with Rust in particular, it's just general knowledge.

@camlorn
It is especially worth pointing out that you are making the assumption that assembly translation is or should be obvious and 1:1 to language constructs. It is not, and it has never been. Not even in C. For example, any use of u64 on 32b platforms will result in more complex code. How do you know? You need to learn how translation to assembly works. Can't/don't want to learn it? Someone else did and wrote a book with those rules of thumb. So what if rules for Rust are slightly different from C? It's a different language, it needs different rules.

You can also go with (a < 0) | ((a as u64) < b).
There likely won't be any difference on asm level. Then again, I'm not proposing an exact asm implementation. The important part is that it will be more expensive than regular cast.

You can also go with (a < 0) | ((a as u64) < b).

There likely won't be any difference on asm level. Then again, I'm not proposing an exact asm implementation. The important part is that it will be more expensive than regular cast.

In this version, the two comparisons can be evaluated in parallel, so it's a bit better.

There's any number of ways to implement it, which is all the more reason not to judge the concept based on esoteric optimization arguments.
Just to illustrate, a single branch version:
fn less_than(a: i64, b: u64) -> bool {
    let ua = a as u64;
    (a >> 63) | (a < b)
}

| is branchless, are you thinking of ||?

I was considering < implemented as test instruction, which now that I think about it, might not be actual common practice.

We'd need a stable feature to turn these conveniences off so that any code exploiting them fails to compile.
We must avoid branches entirely when doing cryptographic primitives, but often that entails a performance hit, although maybe not here.  It'd be crazy easy for a hostile contributor to sneak in a non-constant time operation using these tricks, especially if they targets an upstream crate that you audited once but do not yourself maintain.
I'd think the type errors might help with optimizing code as well, so maybe a feature supporting different options for speed, constant-time, and super strict.

I'd think the type errors might help with optimizing code as well, so maybe a feature supporting different options for speed, constant-time, and super strict.

Constant time operations is a valid concern., but this operation can be branchless. The only way it can bite you is when your have two different comparisons in different branches and somehow manage to use different types. But then again, as soon as you have branches you should know what you're doing and probably should implement it in asm anyway.
As for the strictness I wouldn't call it any less strict. Allowing cross-type comparisons will likely not increase, but reduce count of hidden bugs. On top of that adding this option will split the language, because code written with and without it won't be compatible.

On top of that adding this option will split the language, because code written with and without it won't be compatible.

How would it split the language? "Code which works branchless" would be a subset of "Code where branching is allowed", so it'd be similar to no_std libraries.

Unless I really missed something, the idea was about getting "branchless code" an equivalent to "if you try to compile no_std code against a dependency which requires libstd, it will fail."

That's exactly how it is. Code written in "hetero-compare-less rust" won't be able to use code written in "hetero-compare-enabled rust". But it's not about being branchless (branches are not necessary to implement it), is about "strictness" and I think it's not worth it.

Making sure that the timings of comparisons are value-independent would certainly make it safer for crypto code, and note to that effect can (should?) be added to the RFC. The other concerns listed are not really in scope of this proposal, though.

You cannot simply say that crypto should be written in assembler.  People write crypto in any language they can get their hands on.
There is plenty of crypto that simultaneously benefits from constant-time operations, the borrow checker for memory management and/or threading, being cross platform, and various abstractions.  For sure, post-quantum public key exchanges like SIDH hit all these requirements hardest, and probably should not be implemented in assembler, but..
You cannot know if code is correct unless people read it.  Reading code is hard.  How many people will read a primitive implemented in Rust vs assembler?

Constant time operations is a valid concern, but this operation can be branchless. The only way it can bite you is when your have two different comparisons in different branches and somehow manage to use different types.

I'm doubt that this RFC can promise to always use a branchless comparison of signed and unsigned values.  How can you know if testing the high bit might be faster on some obscure platform?

Allowing cross-type comparisons will likely not increase, but reduce count of hidden bugs.

No.  If you turn this off, then you would do so for a reason and not just insert as willy nilly.  You'd likely just homogenize the types that you use in various places.
To be clear, we should add these comparisons because they will reduce errors from inexperienced or careless people inserting as willy nilly.  We do however need a way to turn of the signed vs unsigned comparisons for constant time operations.  Also, there are reasons to disable even more, if only temporarily to interactively explore how your code uses numerical types.

We do however need a way to turn of the signed vs unsigned comparisons for constant time operations.

And how exactly do you specify which operations get turned off? Pretty much every operator can be implemented with value-dependent timing on some platforms. Nobody is preventing Rust to be compiled for an 8-bit processor for example, where all the operators would be implemented in software.
It makes more sense to simply guarantee value-independent timing for all basic operations.

You cannot simply say that crypto should be written in assembler. People write crypto in any language they can get their hands on.

I was talking about situation when you already inside of a branch unrelated to comparison. The only reasonable way to ensure that both arms of a branch have constant execution time is to check assembly. The only reliable way to ensure they stay that way after compiler update is to write it yourself. But given that nowadays any branch opens you to branch predictor attacks I'd say it's not even worth discussing.

How can you know if testing the high bit might be faster on some obscure platform?

Arm is not an obscure platform by any means. Yet in general it doesn't even guarantee that multiplication is constant-time, let alone division. Do you have a problem with that?
Speaking constructively: I'm not an ASM guru, but it seems that everything is fine on x86, amd64, arm and arm64. Quick googling shows that it's likely to be fine for MIPS. No idea about SPARC or PowerPC. Arm thumb might have a problem with it.

If you have a comparison in a particular bit of code, there is no reasonable expectation that it is constant-time. There's nothing special about this RFC that warrants particular attention w.r.t. constant-time behavior or other crypto-specific issues. A good approach for crypto code is to use a new set of built-in types that are guaranteed to have only constant-time operations defined on them. If/when such things are spec'd and implemented, there will be special rules for these comparison operators and/or the comparison operators won't be included.

:+1: to https://github.com/rust-lang/rfcs/pull/2021#issuecomment-306821161:

I like the idea of helping the user do the right thing rather than forcing a potentially incorrect use of as.

Signed-unsigned comparison is a classic footgun in C++, and it not compiling in Rust isn't that much better than the warning in C++, since the usual result in both is an unchecked cast-and-hope.
The intent of the coder here is clear, so the compiler should just generate the unsurprising logic.  Without it, the correct version is substantially longer and more annoying to write out, which feels backwards.  The cast-one-side option will always be there for people who want it.
(On the implementation, I wonder what LLVM emits if one zext & sexts i32s to i33, then compares those...)

I kinda wary about this RFC, if we implemented it then we will have subtle different rule about integer promotion from C,
void main(){
    unsigned char a = 200;
    unsigned char b = 200;
    int c = 400;
    printf("%i", c == a+b); // print 1
}

fn main(){
    let a: u8 = 200;
    let b: u8 = 200;
    let c: i32 = 400;
    c == a + b; // compiler error now, integer overflow with this RFC
}

I rather have get compiler error rather than runtime error when porting some C code.

Doesn't this break type inference (cf rust-lang/rust#41336)?

I don't believe so. << operator admits arbitrary right-hand side type, and it works just fine.

subtle different rule about integer promotion from C

True, this RFC makes such errors more likely, but you still have this problem, even without comparisons:
fn main() {
    let a: u8 = 200;
    let b: u8 = 200;
    println!("{}", a + b); // overflow
    let c = a + b; // analogue of auto from c++, overflow
}

So you can't just copy-paste-fixup C/C++ code anyway.

Doesn't this break type inference

Yes, it might. It's noted in drawbacks.
On the other hand people don't usually use comparison the same way they use compound operators.
It's pretty unusual to have a very complex expression as an argument of comparison.
I expect that there won't be much problems with that.

It's probably true newtypes could cover the cryptographic concerns.

Yes, it might. It's noted in drawbacks.
On the other hand people don't usually use comparison the same way they use compound operators.
It's pretty unusual to have a very complex expression as an argument of comparison.
I expect that there won't be much problems with that.

The concern isn't complicated expressions, it's that x == 1_000_000_000_000 might now change semantics as the RHS would have to default to an i32.

The concern isn't complicated expressions, it's that x == 1_000_000_000_000 might now change semantics as the RHS would have to default to an i32.

Interesting. You're right.
I wonder how it works for for other binary operations.
For example, addition is defined for both values and references, yet if you pass a literal there, it's still able to infer its type.

For example, addition is defined for both values and references, yet if you pass a literal there, it's still able to infer its type.

But a 123 literal cannot be a reference, so it's sufficiently constrained.

This proposal would make Rust code safer and cleaner. Rust and C++ code that casts away sign or size differences is dangerous and ugly. Code that does care about doing safe comparisons today needs to rewrite the same boilerplate code, which leaves the possibility of bugs.
Implementing these heterogeneous comparisons in Rust core means that the code will be well-tested and may be able to use clever type- or architecture-specific implementations that are faster than the naive boilerplate code.
For developers that really don't want heterogeneous comparisons, Rust can add optional warnings, similar to gcc and clang's -Wsign-compare warning.

From the RFC:

Right now every comparison between different integral types requires a cast.

This isn't technically true. Here I implement all three of the comparisons in the example without casts, using From:
fn less_than_i8_i16(a: i8, b: i16) -> bool {
    i16::from(a) < b
}

fn less_than_i8_u16(a: i8, b: u16) -> bool {
    i32::from(a) < i32::from(b)
}

fn less_than_i64_u32(a: i64, b: u32) -> bool {
    a < i64::from(b)
}

fn main() {
    println!("{}", less_than_i8_i16(1, 2));
    println!("{}", less_than_i8_u16(1, 2));
    println!("{}", less_than_i64_u32(1, 2));
}

Play link: https://is.gd/umbiUq
Note how the (i64, u32) comparison is much simpler than what you suggest; it doesn't actually require a separate less-than-zero comparison like you prescribe. I think you meant for it to be a (i64, u64) comparison or a (i32, u64) comparison?
Also, we have to admit that the RFC will have limited utility unless/until there is a solution for comparing isize/usize against u16/u32/u64 values. Note that isize and usize doesn't implement From for most fixed-size types because it isn't clear what types should be implicitly convertible to isize/usize given differences in architectures. It is much more common for me to run into annoying comparisons of isize/usize against a fixed-sized type than it is for me to run into annoying comparisons between two fixed-sized types.
Anyway, I generally support this RFC but I think there errors and omissions that should be cleared up.

Note how the (i64, u32) comparison is much simpler than what you suggest

On 64-bit system you can widen both sides to i64, but not on 32-bit system. On second thought that was a bad example because i64 won't be native anyway. In any case, (i64, u64) comparison on 64-bit arch will have the same problem and will require negativity check.

RFC will have limited utility unless/until there is a solution for comparing isize/usize against u16/u32/u64 values

isize and usize won't be a problem. They should be treated in exactly the same way as correspondingly sized int/unit values.
On 32-bit arch (usize, i32) comparison will be exactly the same as (u32, i32) comparison. On 64-bit arch it will be the same as (u64, i32) comparison.
Note that this RFC does not propose any implicit conversions (which is problematic indeed). It just proposes to implement comparisons for all different pairs of integral types. I also don't expect for them to be implemented in rust. These comparisons will likely be builtins and will differ between archs.

Here I implement all three of the comparisons in the example without casts, using From:

From is slightly better than as, but it's still a cast.

isize and usize won't be a problem. They should be treated in exactly the same way as correspondingly sized int/unit values. On 32-bit arch (usize, i32) comparison will be exactly the same as (u32, i32) comparison. On 64-bit arch it will be the same as (u64, i32) comparison.

In the RFC, I suggest adding specific mention of isize. I also recommend comparing your approach to the From-based approach, and in particular point out that your approach works for (isize/usize, 'u16'/'u32'/'u64), whereas the From-based approach doesn't. This is a clear advantage to what you're suggesting over the From-based approach.

From is defined in exactly the cases where as cannot overflow. The RFC talks explicitly about the  problem of silent overflows in naive comparisons, which is a problem From naturally has no way of being relevant to, since it's not implemented for those types.

By the way, it's simpler to use a.into() instead of i16::from(a).

By the way, it's simpler to use a.into() instead of i16::from(a).

The compiler isn't able to infer the type when into() is used, when I tried to rewrite the from()-based code using into().

If we get a "number trait" in the future, this is the first step to polymophic, heterogenous, and safe number comparisons, which is great!

:-1:
The current strict rules teach an important lesson IMO, that different integer types are in fact different types. They have different places to overflow, and may be signed or not. This is not something you can just gloss over, and having a separation between the types provides you with a sound mental model, without having to wonder "which type is this? when can it overflow?".
The proposal adds many new ways to introduce bugs like when you do let f = 2000.0; if f as u8 > 1024u16 {...}. Right now that's a compile error, in the future it will be a bug. You can't warn for them per default as there might be false positives.
This doesn't just add the inconsistencies mentioned in the RFC, it also adds the inconsistency that auto comparison to and from floats doesn't work. Doing that auto comparison would be a far worse idea than what is proposed here, as floats are so totally wonky types, e.g. they don't have unique representations for integers throughout most of their covered range (let f = u64::max_value(); f as f32 == (f - 1) as f32 evaluates to true...).

Also, don't forget that rust automatically infers the type of integer literals and variables assigned to such, so that covers most cases already. In fact, having enforced checks pushes the user towards eliminating type annotations from such variables and literals, so without the RFC you might even have shorter and more understandable code. I just compare the situation after the RFC to C/C++ where you can intermix integer types happily and codebases do this everywhere, I definitely don't want Rust to end up like that.

The proposal adds many new ways to introduce bugs like when you do let f = 2000.0; if f as u8 > 1024u16 {...}. Right now that's a compile error, in the future it will be a bug. You can't warn for them per default as there might be false positives.

Having more versatile comparisons doesn't prevent the compiler from warning when a variable f as u8 is compared to a literal outside its range 1024u16.
I'd argue it's a much greater hazard to have an ecosystem of people constantly reinventing heterogeneous comparisons poorly.
Heck, I could see myself doing the casting incorrectly in a moment of inattentiveness or "As a former scriping language programmer, I think the need to explicitly cast here is stupid"-ity and I generally err on the side of care and caution. (I never program in C or C++, despite knowing how, because it's too stressful to live up my my standards.)
It's embarassing to admit, but, until this thread, it hadn't even occurred to me that, even in the intutiive case of "casting a negative signed value to unsigned always produces zero", a check is inherently required to distinguish real zeroes from "out-of-range".

separation between the types provides you with a sound mental model, without having to wonder "which type is this? when can it overflow?".

I'd argue it's other way around. Lack of ways to safely work with different integral types forces you to wonder "when can it overflow?" and do dangerous casts.

The proposal adds many new ways to introduce bugs like when you do let f = 2000.0; if f as u8 > 1024u16 {...}.

The problem here is obviously not comparison, it's the cast. Here's the same bug with current comparison rules: let f = 2000.0; if f as u8 > 100u8 {}.
This RFC won't make this case worse. In fact, if there were float/int comparisons this code would be both safer and cleaner (and bug-free).

Doing that auto comparison would be a far worse idea than what is proposed here, as floats are so totally wonky types

The thing is, you don't really have to convert one to another to compare them. You just have to check if exponent overflows (1 bit mask), then check if fractional part is non-zero (1 bit mask), then you can safely cast mantissa and compare. These three operations give you all information you need to compare float and int correctly.
It's just more expensive and I'm not sure it's worth it. Maybe as an option.

I just compare the situation after the RFC to C/C++ where you can intermix integer types happily and codebases do this everywhere

Mixing integer types isn't bad "just because". It's bad because it is unsafe. This RFC proposes to use safe and correct way all the time, lifting this burden from programmer.

I'm not convinced that anyone's made a good argument for why the comparison operators should be used for this, especially since using them would be an instantly stable* breaking change:
x == 1_000_000_000_000 would overflow and only produce a warning.
fn blah(x: usize) -> usize {
    let y = 3;
    if y == x {
        y.leading_zeros();
        y
    } else {
        x
    }
}

would stop compiling due to inference issues. You could argue that this should be fixed and block landing this feature I guess.
* I'm assuming that operators can bypass stability checks considering that the Carrier/Try implementations for Result are unstable, yet ? still works.

This RFC proposes to use safe and correct way all the time, lifting this burden from programmer.

Its safe and correct only if you believe that the type errors for comparing different integer types are never due to an error elsewhere in the program.

Its safe and correct only if you believe that the type errors for comparing different integer types are never due to an error elsewhere in the program.

Lack of ways to safely work with different integral types forces you to wonder "when can it overflow?" and do dangerous casts.

Then add those ways, but don't make them implicit. Create an explicit function instead. How is adding some implicit conversion that you dont know about when looking at the comparison without knowing the actual types (which are most likely inferred so they can be in totally remote locations), how is that more safe?
I'm all for having a good and safe way to compare unsigned <-> signed integers and to have an explicit upcasting conversion utility that warns if you compare ints of the same type, but it should be opt-in.

The thing is, you don't really have to convert one to another to compare them.

First, what you described gets very close to an actual conversion, second it misses the point that floats have vastly different properties than integers, like I've outlined. E.g. you still have the issue of the missing resolution.

This RFC proposes to use safe and correct way all the time

I really love the "type lego" pattern of strongly typed Rust. If you have a get_counter() function and it returns u32, and then you compare it with some cached value of some earlier call to check whether it increased, you will get an error if you swap the cached value with u64 from some get_timestamp() function.
C/C++ don't follow that approach and I don't really like that.

What @ssokolow said. Also, you can still accidentally confuse variables of the same type. I don't believe that the chance of making this mistake is correlated with their typing. You could make analogous argument in other areas e.g. by saying that disallowing loops in favor of goto would reduce loop related bugs. Unquestionably true, yet a completely wrong way to look at it.

How is adding some implicit conversion that you dont know about when looking at the comparison without knowing the actual types (which are most likely inferred so they can be in totally remote locations), how is that more safe?

When you write code using ints, most of the time you are not thinking in terms of finite fields and modular arithmetic. You are using them as a stand-in for abstract integer numbers. Each primitive integer type represents a different subset of numbers, but in terms of programmer intuition, they are all the same domain.

First, what you described gets very close to an actual conversion, second it misses the point that floats have vastly different properties than integers, like I've outlined. E.g. you still have the issue of the missing resolution.

Floats and ints, representation notwithstanding, all represent subsets of rational numbers with infinities. All comparisons are perfectly well defined except for NaN.

@matthewjasper

breaking change: x == 1_000_000_000_000

Yes, this change breaks type inference in some cases (even though I personally think that literal overflow should be an error, not a warning). It's simply a question of what's more useful: type inference in such cases or heterogeneous comparisons. I'd say I face heterogeneous comparisons much more frequently.

type errors for comparing different integer types are never due to an error elsewhere in the program

That's the difference: I don't think that different types in comparison constitute a type error. Type error means usually that some operation gives wrong result. It's this operation responsibility to fail, not comparison's. I don't think that comparison should be more strict to compensate for problems in other parts of code.
@est31

how is that more safe?

It always yields mathematically correct result, unlike casts. How can it be less safe?

it misses the point that floats have vastly different properties than integers

It does not, that's why you need to check exponent first. After checking exponent you know whether mantissa fits into your integer or not. If it doesn't, then you already know the result. If it does, then you can cast it.

I really love the "type lego"

That's rather subjective.

you will get an error if you swap the cached value with u64 from some get_timestamp() function

If I understand your example correctly, this catches an error when you mix-up comparison of semantically different types (as in yous should not compare counter and timestamp). If you really want this kind of safety, you should use separate type for timestamp (newtype u64?). Otherwise it's not reliable because counter can also be u64.
@le-jzr

All comparisons are perfectly well defined except for NaN

Yup! And that's what PartialOrd/PartialEq is for. =)

@le-jzr

When you write code using ints, most of the time you are not thinking in terms of finite fields and modular arithmetic. You are using them as a stand-in for abstract integer numbers.

This depends on domain and is wrong in general.
In my domain all numbers are have fixed limited width and I generally want to treat e.g. u8and u32 as distinct types, as different as struct S and struct Z, with accidental cross-type operations being detected and all "migrations" from u8 world to u32 world being explicit.
Rust, unlike e.g. C with its intermixable soup of types, gives me this ability and I consider it one of its selling points, one of those that I would advertise to colleagues. It would be really sad to lose this ability, so whatever result this RFC may end up, please make it optional.

@petrochenkov Could you elaborate on why? I feel like with overflow checking we already moved toward an interpretation of Rust's built-in numeric types as just different subsets of the full number line.

I generally want to treat e.g. u8 and u32 as distinct types, as different as struct S and struct Z

The question is: why? Sure, there are domains where it's useful (mostly low-level hardware interop and embed), but my guess is that the answer is right here:

C with its intermixable soup of types

The fact that C does it wrong doesn't meant it can't be done right.
I'm all for it being optional though.

In my domain all numbers are have fixed limited width and I generally want to treat e.g. u8and u32 as distinct types, as different as struct S and struct Z, with accidental cross-type operations being detected.

If your numbers are really distinct types with no overlap, then newtype wrappers seem like the most appropriate way to represent them. Using the builtin type for anything that remotely resembles an integer is a C pattern that should be killed and burried.

My understanding was that different sizes of integer and floating-point primitives existed in order to reliably control in-memory representations, both for efficiency and for FFI.
Comparisons have nothing to do with that and using that implementation quirk of numerics as a guard feels like it should be as un-idiomatic as using bool everywhere rather than two-element enums like the Env { Inherit, Clear } from Pascal Hertleif's talk.
(ie. I agree with @le-jzr that a newtype wrapper would be both more idiomatic and better communicate the intent to someone new who looks at the codebase.)

To be clear on my position, I'm against breaking comparison operators for this, not for having correct, easily usable heterogeneous comparison implementations in std.

It's simply a question of what's more useful: type inference in such cases or heterogeneous comparisons.

It's about whether we consider the convenience/discoverability/aesthetics of == worth such a breaking change. I know free functions aren't really Rust's style though, and I can already imagine the 'Why doesn't == do this?' threads. Maybe I'd feel better once we know what this actually breaks in practice.

I should myself clarify that I'm not in favor of breaking existing code. I just don't think the problem is significant (but that can only be decided by hard data, not anyone's opinion).
At the same time, I'm quite confident that the inference algorithm can be improved to work in backwards-compatible way with heterogenous operators, but that would be a matter for a different RFC.

@VFLashM

Sure, there are domains where it's useful (mostly low-level hardware interop and embed)

This is kinda what I do, unfortunately in C.
@glaebhoerl

Could you elaborate on why? I feel like with overflow checking we already moved toward an interpretation of Rust's built-in numeric types as just different subsets of the full number line.

This is just natural in lower level programming. Numbers have sizes, alignments, endiannesses, structures have fixed binary formats, there are no numbers in "mathematic" sense.
Ideologically, since I remember Rust it was positioned as a language targeting this niche and catering the needs of lower level programming, and it's its uniqueness and selling point, high level languages are in overabundance already. (If you want fast prototyping with big numbers, go write Python).
@le-jzr

If your numbers are really distinct types with no overlap, then newtype wrappers seem like the most appropriate way to represent them.

Wrappers can be used in two ways. 1) No "naked" built-in types, large number of wrapper types with semantics of a number represented by its type, so you can't write some nonsense like offset + priority. Usually this is just impractical, whole lot of newtypes and related boilerplate for both reading and writing the code for little gain. I'm happy every time I remove this kind of over-engineering from a code base. I'll also keep my bools, thanks. I agree though, it can (and sometimes needs to) be done in certain cases. 2) Just wrappers for the built-in types u32 -> struct U32. Why would I do this if built-in types are perfectly suitable for my task already.
Regardless of low level, if you have a type mismatch in an arithmetic operation, this is already suspicious and the solution is usually not adding as, but changing one of the types elsewhere. Unless you do a storage size optimization like usize -> u32, then write  a getter/setter accepting "the proper type" (usize) and storing "the smaller type" (u32) internally and be happy.
I don't write much Rust code outside of rustc, so it may not be representative, but I don't think I remember encountering signed-unsigned comparisons in particular. Maybe comparing usize indexes with isize offsets? (These need checked (panicking) casts instead, IMO.)

@petrochenkov

This is just natural in lower level programming. Numbers have sizes, alignments, endiannesses, structures have fixed binary formats, there are no numbers in "mathematic" sense.
Ideologically, since I remember Rust it was positioned as a language targeting this niche and catering the needs of lower level programming, and it's its uniqueness and selling point, high level languages are in overabundance already.

I strongly disagree. Binary formats are a necessity, but they don't form intuition of how the code works. Heck, after memory access, unexpected overflows are the next major source of bugs in C. Rust tries to be a safe systems language, and it won't be quite there until the gap between programmers (thinking in ℤ) and machine (computing in limited precision) is carefully guarded by compiler. Comparison operators doing "the right thing" is a step in that direction.

As an aside, I do think documentation should be adjusted to suggest using i32::from(), etc. instead of as.

In regards to the How We Teach This section, I would encourage you to reference the recently updated teaching template. Find the chapter in the book, or other reference, in which this is discussed, and provide what additional comments would need to address this feature. The code functionality is being changed in some way, so provide the template of what additional documentation could look like. Is this a continuation or new Rust pattern? This idea is not obvious to new Rust users, namely me. What names and terminology work best for these concepts? This may have been mentioned somewhere earlier in the RFC, but stating them here could improve clarity and understanding of the feature. It also provides a nice foundation for constructing teaching items.
I think it would be helpful to reference the previous code examples provided, perhaps adding another example to show off the feature. You could also provide an explanation of how this was done previously, and what could potentially be done with the addition of this feature. What do new users need to know about this? Are there any resources new users can consult to increase their understanding of this concept? Do current users need to change to accommodate this feature?

I just got a submission to Rustrations Club related to this RFC. The code snippet shows a benefit of accepting this RFC that I haven't seen mentioned explicitly; I think it's a good example of the advantages:
fn foo(a: isize, b: c_int) -> bool {
    a > b
}

The problem is that the programmer doesn't know whether isize is going to be larger than c_int or not, so writing this out to be correct would be annoying.
Assuming I'm understanding correctly that this RFC would just Do The Right Thing depending on whether you're compiling for 32 or 64 bit, I think this example is a strong point in favor of this RFC.

In regards to the How We Teach This section

I added a small section to RFC.
The basic idea is rather simple. I don't think that we need to add lots of documentation for it. It's probably enough to mention that Rust allows comparisons between different numeric types and that it returns mathematically correct result.
I'm not quite sure that implementation details should be covered in either "The Rust Programming Language" (which is a brief overview for beginners) or "Rust Reference" (which covers language itself). Actually, I don't know any suitable place for it. Maybe it's worth mentioning in "The Rust Programming Language" that comparisons of numeric types of sizes equal or larger than machine word will incur small performance penalty, but that's probably it.

Can this maybe get some libs-team attention under the umbrella of the ergonomics initiative before the impl period begins? (I see @aturon just self-assigned it - possibly with that intent?)

@glaebhoerl Yep, I will try to push on this. If anyone wants to summarize the current state (i.e. major open questions or tradeoffs), that'd be super helpful.
cc @scottmcm :-)

I think the major unknown here is still how to do this without huge inference breakage. To use an example from above, in x == 1_000_000_000_000 how can the rules still use the type information from x to know what the literal should be?  Defaulting the literal to i32 and changing behaviour due to truncation despite compiling is clearly unacceptable, worse even than compilation failure.
The main back-and-forth is essentially whether this is useful.  On one side is appreciation that this has intuitive behaviour and makes the safe-and-correct thing easy, since it's much easier to do this wrongly than correctly today, and comparison can be done without pitfalls like surprising overflows.  Simultaneously there's criticism that this hides mistakes elsewhere (that are compilation errors today), makes the machine code emitted by the operators less obvious, leads Rust towards C-style fuzziness about types, and that the correct thing to do is to change types elsewhere so that there isn't a type mismatch.

Providing a gist of my earlier comments:
Integer types are different. Some can be negative, some positive, they have different overflowing behaviours. This is not something you can gloss over.
I see the strong typing regarding to integer types as a feature of Rust, not a problem. This RFC would undermine that feature and is therefore bad.
This strong typing of integer types allows to play "type lego". If you have a get_counter() function and it returns u32, and then you compare it with some cached value of some earlier call to check whether it increased, it works. You will get an error if you swap the cached value with an u64 from some get_timestamp() function.
C/C++ doesn't follow that approach and I don't really like that.
Of course, you sometimes have cases where you actually want to compare integers of different types. Right now this is not easy to do, e.g. comparing usize to isize. There is definitely demand for that, and having some way to do these comparisons is better than forcing people to solve the issue badly (there is no good way to compare usize to isize with casting only). However, for these cases I'd like if there was an opt-in way to do it, as in you somehow explicitly state you want a comparison of different types.
End of gist.
As an alternative proposal, you could have an ComparableInt<T>(T); type which wraps an int and provides ComparableInt<u32> <-> ComparableInt<isize> and similar type comparisons (also possibly including ComparableInt<u32> <-> isize). The proposed way of obtaining a wrapped int is to call a comparable(self) function on it.

@est31 I very much like the idea of having a convenient way to explicitly say "I'd like to compare these two numbers, please DTRT", while otherwise preserving integer type distinctions.

Another alternative would be having the full set of less_than<T>(), less_eq<T>(), equal<T>(), etc. either as methods on integer types, or as functions in core::cmp. The compiler can then suggest use of these methods/functions on type-mismatched comparisons.

@scottmcm ( and this actually answers to most points from @est31 as well )

I think the major unknown here is still how to do this without huge inference breakage. To use an example from above, in x == 1_000_000_000_000 how can the rules still use the type information from x to know what the literal should be? Defaulting the literal to i32 and changing behavior due to truncation despite compiling is clearly unacceptable, worse even than compilation failure.

This is a serious concern indeed. In theory type of integral literal should be polymorphic "any integral type wide enough to contain value specified". In practice I'd rather require explicit types for integrals not fitting into i32. But then again, it will complicate type inference regardless of anything.

hides mistakes elsewhere (that are compilation errors today)

I'd argue that it's not. It does help sometime, when it prevents you from comparing values of semantically different types that happened to be implemented by different integral types (as in comparing seconds stored as i32 and milliseconds stored as i64), but it's more of a coincidence than the rule (it won't prevent you from comparing seconds and milliseconds if both are stored as i32). The correct way to avoid such errors is to create a new distinct type for each semantically different type. On top of that, in reality there almost always will be some other operation, which is totally incorrect for different types, and that operation will be caught by type system (cross-type assignment at the very least).

makes the machine code emitted by the operators less obvious

That's true. On top of that it's not only less obvious, but also less efficient.

leads Rust towards C-style fuzziness about types

Strictness is only useful because it helps finding problems early. If change enhances ergonomics and don't introduce new classes of errors, then I see no reason in strictness for sake of strictness.

correct thing to do is to change types elsewhere

The whole point is that cross-type comparison is mathematically "correct". It may reduce performance, but overall your code must have some other problem for it to be incorrect. For example, in most such cases you'll also have cross-type assignment, which is still a compilation error. The only case that won't be caught somewhere else is logical type mishap, but then again, there isn't much you can do about it anyway.

Thanks @VFLashM for the RFC and @scottmcm, for the summary, and others for adding their thoughts!
We discussed this RFC in the lang team meeting, and while there's continued interest in improving ergonomics around numerics (without sacrificing reliability), the key pitfall here is unknowns around type inference. In particular, it seems feasible that we could implement something like this RFC with some kind of inference fallback scheme, but such schemes in the past have caused headaches.
During the impl period, we will continue ongoing work overhauling the way type inference and the trait system work, one component of which is better support for "suggestions" as a general mechanism for fallback. At that point, we could experiment with adding more comparison impls with a designated "default" one to apply. Until then, though, we're really not in a position to make the proposed change.
In the meantime, in the interest of keeping our tracker clear, I'm going to:
@rfcbot fcp postpone

I understand that the inference aspects are tricky, and that we probably can't make this change until we have some way to say "but default them to being the same if there are no other constraints are in play."
That said, I have wanted this a lot considering the amount of Rust code I've written, and it's frustrating every single time because it just feels like the compiler is getting in my way for no reason. In every case, behavior described here is what I wanted, and it was quite annoying to have to jump through hoops to get it.
It also came up when I was trying to introduce a friend to Rust by showing how I would translate some Python code of theirs into Rust. It was rather embarrassing to explain why I had to write my own function just to properly compare a signed integer to an array index.
I would definitely rate this as one of my top paper cuts using the language, and I would rather have this before most if not all of the other currently proposed features (as much as I like some of them).

why I had to write my own function just to properly compare a signed integer to an array index.

Why did you have to write your own function? That is, isn't it an as?

Why did you have to write your own function? That is, isn't it an as?

It's been a while, but I believe it was because I was comparing an i32 to a usize, and needed to do the right thing if the i32 was less than zero. Thus, it was something like
if i32_val < 0 {
  return Less;
} else {
  return (i32_val as usize).cmp(&usize_val);
}

Now, I think in this particular case (again, it's been a while), it would have been okay to instead cast both numbers to isize, but that's not true in the general case, and it's annoying, nonetheless.

I'm personally pretty happy that this got postponed, because I think it shouldn't be done at all, at least not without an actual opt-in into the feature.

at least not without an actual opt-in into the feature

Well, technically it's just a trait implementation. It doesn't have to be imported by default. Manual import to opt-in is reasonable, even though I personally would rather have an opt-out.

It doesn't have to be imported by default.

You can't import trait impls, you get them all for free when you import the trait.

You can't import trait impls, you get them all for free when you import the trait.

Interesting. I thought that if impl is in a separate module, then it has to be imported. My bad.

@VFLashM To expand on it: impl doesn't have a name so there's nothing you could import.

Any concerns for threading? Aren't all primitive numeric types 'sync' and 'send'? Doesn't that mean I could send a primitive to another thread. Then couldn't that other thread change the value of the primitive between the checks and casts, etc? For example:
if ( someI64 < 0 ) {
    return true;
} else {
    (someI64 as u64) < someU64;
}

So, if another thread changes the value right after the first comparison, would that not potentially give the wrong result?

@gbutler69 That's not possible – Rust prevents mutable aliasing except for some special cases (Values inside UnsafeCell). Being Sync and Send doesn't change that.

@golddranks - Ah, yes! Thanks. I'm still solidifying my understanding of the Rust rules and what they do and don't allow. I figured there was something I was missing.

Closing as postponed -- thanks, all, for this discussion! We'll look forward to revisiting this topic after the dust settles with changes to type inference and the trait system during the impl period!


Cannot build ProjectSystem project

Windows Server 2012 R2, VS 2017 RC, current master:
"C:\git\vf\build-everything.proj" (default target) (1) ->
"C:\git\vf\vsintegration\fsharp-vsintegration-src-build.proj" (Build target) (10) ->
"C:\git\vf\vsintegration\src\FSharp.ProjectSystem.FSharp\ProjectSystem.fsproj" (Build target) (17) ->
(MergeCtoResource target) ->
  C:\git\vf\packages\Microsoft.VSSDK.BuildTools.15.0.25907-RC2\tools\vssdk\Microsoft.VsSDK.targets(906,5): warning VSSDK1011: obj
\release\net40\MenusAndCommands.cto has no valid Resource. [C:\git\vf\vsintegration\src\FSharp.ProjectSystem.FSharp\ProjectSystem
.fsproj]

"C:\git\vf\build-everything.proj" (default target) (1) ->
"C:\git\vf\vsintegration\fsharp-vsintegration-src-build.proj" (Build target) (10) ->
"C:\git\vf\vsintegration\src\FSharp.ProjectSystem.FSharp\ProjectSystem.fsproj" (Build target) (17) ->
(CoreCompile target) ->
  FSC : error FS0193: Could not find file 'C:\git\vf\vsintegration\src\FSharp.ProjectSystem.FSharp\obj\release\net40\ProjectResou
rces.rc.res'. [C:\git\vf\vsintegration\src\FSharp.ProjectSystem.FSharp\ProjectSystem.fsproj]

    1 Warning(s)
    1 Error(s)

This is not reproduced on a win 10 machine. When I cleaned up "Resource File" field in the setting above ^^^, the solution was built successfully. May it be the case that pointing to this resource file is redundant and should be removed?


Error when using env.render() along with stable-baselines3

Hello,
In the gym.Env class, the first argument is defined as the mode, which is either "human" or "rgb_array". In Crafter, the render function takes only one argument, size. This causes errors when using stable-baselines3 to evaluate policies and create videos since their helper functions assume envs follow gym.Env and have the first argument as the mode.
A fix would be to just add a dummy first argument mode to the render function
https://github.com/danijar/crafter/blob/e955b1135797d8ca783d5706e8876e0b3b8babb3/crafter/env.py#L120-L122

its didnt work for me

to solve this
recorder.py
`
def reset(self):
obs = self._env.reset()
self._frames = [self._env.render( size=self._size)]
return obs
def step(self, action):
obs, reward, done, info = self._env.step(action)
self._frames.append(self._env.render( size=self._size))
if done:
self._save()
return obs, reward, done, info
`
env.py
    self.metadata = {         "render_modes": [ "rgb_array"],         "render_fps": 4,     }
`
def render( self ,mode="rgb_array", size=None):
size = size or self._size
unit = size // self._view
canvas = np.zeros(tuple(size) + (3,), np.uint8)
local_view = self._local_view(self._player, unit)
item_view = self._item_view(self._player.inventory, unit)
view = np.concatenate([local_view, item_view], 1)
border = (size - (size // self._view) * self._view) // 2
(x, y), (w, h) = border, view.shape[:2]
canvas[x: x + w, y: y + h] = view
return canvas.transpose((1, 0, 2))

def _obs(self):
return self.render(None)
`
also delete pycache folder in crafter and gym

Thanks! I'll leave this open in case it's helpful for other people. I don't know if updating the env is worth it at this point since OpenAI seems to have already changed the Gym interface in the meantime.

The changed code provided here works well with latest sb3 and latest gym. What about merging the PR #25 ?


Question: model code and design choices

Hello! Thank you for your great paper and for publishing the code and checkpoints for the t2v models. While reading about how it all works, I had a number of questions. I hope you'll find some time to answer at least some of them. Feel free to direct me to your paper if it is already explained there :)

What is the reasoning behind using such a small patch size = 2? Usually, I see patch sizes of 16 or 8 used, especially when generating 512x512 images.
I see that you used LoRACompatible modules for linear projection. Have you thought about how this architecture could be expanded with LoRAs?
Have you thought about adding some image-specific positional encoding to appended images?
What is the purpose of args.fixed_spatial? In what cases would one want to train only spatial layers?
In the provided training script, the decay for EMA is set to 0. Does that mean that the provided checkpoint was trained without EMA? Link: here
Given that you are already passing "scaling_factor": 0.18215 to the VAE model, why do you scale it again in the training loop? Link: here
Given that you are already doing attention masking in the encode_prompt function, why are you passing attention_mask and encoder_attention_mask arguments to the model's forward method? I'm not sure if I'm right, but it seems that both of these arguments are never used.
How do you switch between using fp16 and fp32 in the training script?
Training the model for more than 16 frames often results in checkerboard artifacts and significantly reduced quality. Do you think this is a limitation of the Latte model's architecture? I've seen that you recommend looking into autoregressive video modeling, but still, how can we effectively scale the number of frames generated from 16 to 32 without changing the architecture or sampling method?
In the implementation of the BasicTransformerBlock, there is a lot of commented-out code with the cross-attention implementation. Does this mean that the pretrained checkpoint was trained without it?

Thank you again for your work, and I look forward to your answers!

Hello! Thank you for your great paper and for publishing the code and checkpoints for the t2v models. While reading about how it all works, I had a number of questions. I hope you'll find some time to answer at least some of them. Feel free to direct me to your paper if it is already explained there :)

What is the reasoning behind using such a small patch size = 2? Usually, I see patch sizes of 16 or 8 used, especially when generating 512x512 images.
I see that you used LoRACompatible modules for linear projection. Have you thought about how this architecture could be expanded with LoRAs?
Have you thought about adding some image-specific positional encoding to appended images?
What is the purpose of args.fixed_spatial? In what cases would one want to train only spatial layers?
In the provided training script, the decay for EMA is set to 0. Does that mean that the provided checkpoint was trained without EMA? Link: here
Given that you are already passing "scaling_factor": 0.18215 to the VAE model, why do you scale it again in the training loop? Link: here
Given that you are already doing attention masking in the encode_prompt function, why are you passing attention_mask and encoder_attention_mask arguments to the model's forward method? I'm not sure if I'm right, but it seems that both of these arguments are never used.
How do you switch between using fp16 and fp32 in the training script?
Training the model for more than 16 frames often results in checkerboard artifacts and significantly reduced quality. Do you think this is a limitation of the Latte model's architecture? I've seen that you recommend looking into autoregressive video modeling, but still, how can we effectively scale the number of frames generated from 16 to 32 without changing the architecture or sampling method?
In the implementation of the BasicTransformerBlock, there is a lot of commented-out code with the cross-attention implementation. Does this mean that the pretrained checkpoint was trained without it?

Thank you again for your work, and I look forward to your answers!

Hi, thanks for your interest.

Directly inherited from DiT and Pixart-alpha.
Not yet, but it should be easy, depending on what you want to do with this.
What's the positional embedding, for example? The spatial part is encoded with the absolute positional embedding.
Someone only wants to train the temporal module.
No, the setting of 0 here is just to synchronize the parameter values with the model at the beginning of training.
VAE itself does not multiply by this scaling factor.
attention_mask is used for training; encoder_attention_mask  is used fro both training and testing.
The corresponding parameters are controlled in config.
Training on longer frames, such as 32, I did not experience a serious drop in quality.
The autoregressive method is just a training-free method, and there are some training-free methods that can generate longer videos than the base model.
Yes, it is from diffusers and not used in Latte.


v1.0.0:SD_WU_6: hangs when try to open the shared URL on Firefox

Still an issue? Works for me

Closing since no response

Haven't tested on FireFox for a while.  I will check with Mike whether to support Firefox or not.

This should work fine. I develop in firefox usually.
If it's broken, reopen the ticket with more info


feat(Topology/KrullDimension): add invariance under homeomorphism theorem and auxiliary lemmas

Added some lemmas about the topological Krull dimension

Thanks for the reviews!
bors r+


config-example doesn't matches the one on the readme, new features are not there.

In the title.

confirmed - just came here to post this


Fallback for assets that do not have x-created header (we only have this for instances and modules)

Merging this right now as a hotfix for our deployed environments

in Realm.serveLocalFile() we are setting this header, we can't files not in the index not see this header?


Problem Code Igniter 3X

All is working 100% from the examples but when i try to open the same code from a codeigniter project the camera opens OK, but the QRcode cant be found, i point to the QRCode but the javascripts dont fill the input.
Any suggestions?
I'm out of ideas anymore.
Thanks.

@jeanpablojp I m not sure what is the issue here. Try debugging and see if the scan method is called and web worker file is loaded or not.

@jeanpablojp This is not related to Barcode Scanner. Hence closing this issue. Pls take a look into code ignitor and fix this issue. Thanks for reporting.


testings

Even worse then it was before lol

https://github.com/all-contributors please add @TechStudent11 to the doc for their contribution

@all-contributors please add @TechStudent11 to the doc for their contribution

@KendallDoesCoding
@TechStudent11 already contributed before to doc

so?

haha


HttpRequest params get duplicated

See angular #18812

Disabling locale interceptor request cloning as a workaround until this has been fixed.

Since the issue is still not fixed yet, a workaround has been implemented.

The angular issue is fixed with Angular 8. Removing blocker.

Resolved.


React-Scripts hangs on Sonoma

Does this issue occur when all extensions are disabled?: Yes

VS Code Version:  1.82.2
OS Version: Sonoma 14

Steps to Reproduce:

In a Create-React-App project, run npm start or npm build

This doesn't sound related to VS Code. Please file it against those projects or try asking on Stack overflow


[Basics] Switch IdentifiableSet to use OrderedDictionary

Explanation:
Turns IdentifiableSet into an ordered collection which should cut on flakiness in tests and other spots that expect certain ordering of elements.

Scope: All uses of IdentifiableSet i.e. package graph.

Main Branch PR: https://github.com/apple/swift-package-manager/pull/7630

Risk: Low

Reviewed By: @MaxDesiatov

Testing: No tests since the change is somewhat NFC.

(cherry picked from commit b0afde94a377a90c3226b4943de1f695f67529de)

@swift-ci please test

IIRC there was a test that was sorting because this wasn't sorting (that we can now remove). I ... do not remember it though 😅 @MaxDesiatov is your memory better than mine?

@swift-ci please test Linux platform


continuous deployment on main

Closes https://linear.app/pole-api/issue/API-3286/deploiement-automatique-sur-main

🎉


Enum values: SQLType and direction are not resolved

Unresolved references errors

Updated correctly in the 0.9.4 version


rapids_export version support expanded to handle more use-cases

The rapids_export command now supports the following features:
Explicit version argument option. This allows projects to specify a
version when calling rapids_export instead of having it inferred
from the project() call.
Disabling of version exporting by passing VERSION OFF. This
removes the generation of any version related information to allow
for projects that don't have API/ABI version matching requirements
Projects that only have a MAJOR version number now don't try
to match on the exact Major.Minor value but instead on Major only

rerun tests

rerun tests

@gpucibot merge


TCK won't pass on apache-cxf

There appears to be a difference in behaviour between the JAX-RS client from the Apache-CXF project.
When setting a request header e.g.
builder.header(LRA_TCK_HTTP_CONTEXT_HEADER, lraContext);

where builder is an InvocationBuilder, if the header value is a Java null, then Apache-CXF will set a header with a String literal value of 'null'.
Whilst I can't prove this on my setup, I believe that using resteasy, no header is set when the header value is null.
The result of this is that the TCK fails if you try to run on top of Apache-CXF, as TckContextTests sets a null value for a number of tests. When this request gets to the test resource, the Narayana LRA implementation falls over as it tries to interpret an LRA id of 'null'
I think the Narayana implementation ought to handle the situation better, but I think the TCK should probably not be setting null values either.

I've open pull request #328 with a possible fix for this

PR merged.


feat(backend): add services for managing RS grants

Changes proposed in this pull request

add auth server and grant services to backend
export and fix auth types

Context

progress towards #583
TODO: perform grant request on quote creation

Checklist

[ ] Related issues linked using fixes #number
[x] Tests added/updated
[ ] Documentation added
[x] Make sure that all checks pass

add auth server and grant services to backend

Is this actually moving auth into backend? I don't want to merge the two. The auth server should be plugable.

Is this actually moving auth into backend?

No, this is adding tables and services to the backend to manage:

Open Payments auth servers (other than its own) at which it has grants to make client requests
its grants

If we want, this pr could wait for:

https://github.com/interledger/rafiki/pull/727

and then be updated to fully resolve:

https://github.com/interledger/rafiki/issues/583

(and import types from open-payments instead of auth)

Converting to draft for :point_up_2:


chore(deps): upgrade configuration

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-configuration-k8s-27-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 2554

Questions ?
Please refer to the Backport tool documentation


Upgrade to ol 4.0.1

SDK-328

Coverage decreased (-0.03%) to 70.458% when pulling 9a9b22d4ebe95edc711d4ef04930142ebbdea627 on upgrade-ol into 9ce1c3e3889bbd2cc30d62af134b89afa74aea8e on master.


Added

I've removed pointerEvents="none" from the view since it created a situation where the backdrop was not consuming events event though it should have
Also added onReset property hence, once the reset method is called so will this callback

Added the desired propeties


Update GitHub Actions (bump versions, improve naming a bit)

What type of PR is this?

cleanup / CI

What this PR does / why we need it:
This PR updates all GitHub Actions we use to the latest versions. GitHub is phasing out Node.js 16 so actions have to be updated.
I also added the staticcheck linter, enabled. I've been using staticcheck for many years in my personal Go projects and it's a very useful tool. It also works great with golangci-lint.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
None
Testing
This is a change related itself to testing.
Release Notes
None.

Sorry about the conflict, @bartekpacia!

@meatballhat no problem, resolved it :)

@meatballhat "diffcheck" is failing. I suppose the action here is to update godoc-current.txt, right? The changes in this PR are not breaking, it's just some receiver/args renaming)

@meatballhat "diffcheck" is failing. I suppose the action here is to update godoc-current.txt, right? The changes in this PR are not breaking, it's just some receiver/args renaming)

Yep this is a bit clunky, but meant to guard against accidentally doing something not-semver. You can run make v3approve and commit + push the change if it looks good to you 👍🏼


TextInput textContentType not working with multiple inputs, depending on styles

Description
I'm having issue with TextInput textContentType
When I'm trying to setup "Password Autofill" on iOS, it auto-fills only one field, on which I have taped. It happened when my form aligned in the middle of the screen (you can see it in my snippet, I activated it by adding paddingTop 170 to the View). But, if I change the paddingTop property to 40 for example, or 470 (to make it aligned not in the middle of the screen, but on top/bottom), it works like expected and fills both fields correct during usage of "Password Autofill". I've tried many different combinations to replace paddingTop with something else (like empty images, flex styles, non-visible elements). It doesn't matter what is above the form, the problem appears always when fields are in the middle.
Also one interesting thing. I've noticed that if the screen with inputs, is the first screen in the stack, it works correctly. I'm using react-navigation v2.0.0-rc.1
React Native version:
System:
OS: macOS 10.15.5
CPU: (4) x64 Intel(R) Core(TM) i5-6267U CPU @ 2.90GHz
Memory: 207.17 MB / 8.00 GB
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 10.16.0 - /usr/local/bin/node
Yarn: 1.22.0 - /usr/local/bin/yarn
npm: 6.14.4 - /usr/local/bin/npm
Watchman: Not Found
Managers:
CocoaPods: 1.9.1 - /Users/kina/.rvm/gems/ruby-2.4.6/bin/pod
SDKs:
iOS SDK:
Platforms: iOS 13.4, DriverKit 19.0, macOS 10.15, tvOS 13.4, watchOS 6.2
Android SDK: Not Found
IDEs:
Android Studio: 3.5 AI-191.8<IP_ADDRESS>10548
Xcode: 11.4.1/11E503a - /usr/bin/xcodebuild
Languages:
Java: 13.0.2 - /usr/bin/javac
Python: 2.7.16 - /usr/bin/python
npmPackages:
@react-native-community/cli: Not Found
react: 16.13.1 => 16.13.1
react-native: 0.63.0 => 0.63.0
npmGlobalPackages:
react-native: Not Found
Expected Results
I expect that both fields will be auto-filled at one time, and it should not depend on inputs position on the screen. As it works now when inputs are moved to the top.
Snack, code example, screenshot, or link to a repository:
Here is a code snippet
<View style={{marginHorizontal: 15, paddingTop: 170}}>
        <TextInput
          textContentType='username'
          placeholder='Email'
          style={{
            minWidth: '100%',
            paddingVertical: 8,
            paddingHorizontal: 8,
            borderColor: '#D9D9D9',
            borderBottomWidth: 1,
            fontSize: 20,
            color: '#ffffff',
            ...Platform.select({
              ios: {
                marginBottom: 45,
              },
              android: {
                marginBottom: 35,
              },
            }),
          }}
        />
        <TextInput
          textContentType='password'
          placeholder='Password'
          style={{
            minWidth: '100%',
            paddingVertical: 8,
            paddingHorizontal: 8,
            borderColor: '#D9D9D9',
            borderBottomWidth: 1,
            fontSize: 20,
            color: '#ffffff',
            ...Platform.select({
              ios: {
                marginBottom: 45,
              },
              android: {
                marginBottom: 35,
              },
            }),
          }}
        />
      </View>

How it works now:

How it works if I move inputs to the top, and this is how I expect it to work in any inputs position:

Hi, any updates on this?
I have the same issue. Found few similar (but not exact) things in other issues, but nothing helps

weirdly enough I can only get textContentType to suggest autocompletes when i pass multiline to <TextInput>??

I have the same issue on react-native 0.63

weirdly enough I can only get textContentType to suggest autocompletes when i pass multiline to <TextInput>??

This fixed a similar issue for me, where after replacing one <TextInput textContentType="givenName"> with a different <TexInput textContentType=“familyName”>, it still wanted to autofill my first name.

Any news? I have these problems on iOS with textContentType password , then there is a suggestion of email adres in the keyboard. Only on the second (confirm) password field in the form

Hello! Any updates here? I am facing the similar issue on react-native 0.65

Any updates? I am facing a very similar problem in react-native 0.69.5