multiple versions of Python

Please confirm these before moving forward

[X] I have searched for my issue and have not found a work-in-progress/duplicate/resolved issue.
[X] I have tested that this issue has not been fixed in the latest (beta or stable) release.
[X] I have checked the FAQ section for solutions.
[X] This issue is about a bug (if it is not, please use the correct template).

UniGetUI Version
3.1.2
Windows version, edition, and architecture
Windows Profession x64 24H2 (OS Build 26100.2161)
Describe your issue
When I run a search for Python i get a list of many previous Python versions (see attachment).
Is this correct?
I currently have Python 3.13 as my latest version.
Steps to reproduce the issue
Select "Discover Packages", enter "Python" as the search item.
UniGetUI Log
[10/25/2024 2:08:53 AM]    __  __      _ ______     __  __  ______
                          / / / /___  (_) ____/__  / /_/ / / /  _/
                         / / / / __ \/ / / __/ _ \/ __/ / / // /
                        / /_/ / / / / / /_/ /  __/ /_/ /_/ // /
                        \____/_/ /_/_/\____/\___/\__/\____/___/
                            Welcome to UniGetUI Version 3.1.2
[10/25/2024 2:08:53 AM]
[10/25/2024 2:08:53 AM] Version Code:  3.12
[10/25/2024 2:08:53 AM] Encoding Code Page set to 437
[10/25/2024 2:08:54 AM] Using bundled GSudo at C:\Program Files\UniGetUI\Assets\Utilities\gsudo.exe
[10/25/2024 2:08:55 AM] Loaded language locale: en
[10/25/2024 2:08:56 AM] Randomly-generated background API auth token for the current session: zgzqjx1s5vxmnc8k08te417tm9lhrn3eymxa3o4gpl0zo957zdib7gj5aiv0yv82
[10/25/2024 2:08:56 AM] Api running on http://localhost:7058
[10/25/2024 2:08:56 AM] Lang files were updated successfully from GitHub
[10/25/2024 2:08:56 AM] UniGetUI is up to date
[10/25/2024 2:08:56 AM] Downloaded new icons and screenshots successfully!
[10/25/2024 2:08:56 AM] ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
                        █▀▀▀▀▀▀▀▀▀▀▀▀▀ MANAGER LOADED ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
                        █ Name: Npm
                        █ Enabled: True
                        █ Found: False
                        █ THE MANAGER WAS NOT FOUND.  All managers loaded. Proceeding to interface.
[10/25/2024 2:09:05 AM] Found 0 available updates from .NET Tool
[10/25/2024 2:09:05 AM] Found 0 available updates from Cargo
[10/25/2024 2:09:05 AM] Found 7 installed packages from Cargo
[10/25/2024 2:09:05 AM] Ignored updates database was never loaded, so it is going to be loaded now
[10/25/2024 2:09:06 AM] Dependency cargo-update for manager Cargo is present
[10/25/2024 2:09:07 AM] Found 13 installed packages from Pip
[10/25/2024 2:09:07 AM] Found 1 installed packages from .NET Tool
[10/25/2024 2:09:08 AM] Dependency .NET Tools Outdated for manager .NET Tool is present
[10/25/2024 2:09:10 AM] Found 0 available updates from Pip
[10/25/2024 2:09:11 AM] Found 0 installed packages from PowerShell7
[10/25/2024 2:09:11 AM] Found 0 available updates from PowerShell7
[10/25/2024 2:09:12 AM] Found 58 installed packages from PowerShell
[10/25/2024 2:09:13 AM] Found 1 available updates from Winget
[10/25/2024 2:09:13 AM] Found 289 installed packages from Winget
[10/25/2024 2:10:03 AM] Error finding updates on manager PowerShell
[10/25/2024 2:10:03 AM] System.TimeoutException: The operation has timed out.
                           at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.GetAvailableUpdates() in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 199
[10/25/2024 3:08:56 AM] UniGetUI is up to date
[10/25/2024 3:10:05 AM] Found 0 available updates from .NET Tool
[10/25/2024 3:10:05 AM] Found 0 available updates from Cargo
[10/25/2024 3:10:07 AM] Found 0 available updates from Pip
[10/25/2024 3:10:07 AM] Found 0 available updates from PowerShell7
[10/25/2024 3:10:17 AM] Found 1 available updates from Winget
[10/25/2024 3:11:04 AM] Error finding updates on manager PowerShell
[10/25/2024 3:11:04 AM] System.TimeoutException: The operation has timed out.
                           at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.GetAvailableUpdates() in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 199
[10/25/2024 4:08:56 AM] UniGetUI is up to date
[10/25/2024 4:11:05 AM] Found 0 available updates from .NET Tool
[10/25/2024 4:11:05 AM] Found 0 available updates from Cargo
[10/25/2024 4:11:07 AM] Found 0 available updates from Pip
[10/25/2024 4:11:07 AM] Found 0 available updates from PowerShell7
[10/25/2024 4:11:09 AM] Found 1 available updates from Winget
[10/25/2024 4:12:04 AM] Error finding updates on manager PowerShell
[10/25/2024 4:12:04 AM] System.TimeoutException: The operation has timed out.
                           at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.GetAvailableUpdates() in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 199
[10/25/2024 5:08:56 AM] UniGetUI is up to date
[10/25/2024 5:12:05 AM] Found 0 available updates from .NET Tool
[10/25/2024 5:12:07 AM] Found 0 available updates from Pip
[10/25/2024 5:12:07 AM] Found 0 available updates from Cargo
[10/25/2024 5:12:07 AM] Found 0 available updates from PowerShell7
[10/25/2024 5:12:09 AM] Found 1 available updates from Winget
[10/25/2024 5:13:04 AM] Error finding updates on manager PowerShell
[10/25/2024 5:13:04 AM] System.TimeoutException: The operation has timed out.
                           at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.GetAvailableUpdates() in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 199
[10/25/2024 6:08:56 AM] UniGetUI is up to date
[10/25/2024 6:13:05 AM] Found 0 available updates from .NET Tool
[10/25/2024 6:13:05 AM] Found 0 available updates from Cargo
[10/25/2024 6:13:07 AM] Found 0 available updates from Pip
[10/25/2024 6:13:08 AM] Found 0 available updates from PowerShell7
[10/25/2024 6:13:09 AM] Found 1 available updates from Winget
[10/25/2024 6:14:04 AM] Error finding updates on manager PowerShell
[10/25/2024 6:14:04 AM] System.TimeoutException: The operation has timed out.
                           at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.GetAvailableUpdates() in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 199
[10/25/2024 7:08:57 AM] UniGetUI is up to date
[10/25/2024 7:14:05 AM] Found 0 available updates from .NET Tool
[10/25/2024 7:14:05 AM] Found 0 available updates from Cargo
[10/25/2024 7:14:07 AM] Found 0 available updates from Pip
[10/25/2024 7:14:08 AM] Found 0 available updates from PowerShell7
[10/25/2024 7:14:12 AM] Found 1 available updates from Winget
[10/25/2024 7:15:04 AM] Error finding updates on manager PowerShell
[10/25/2024 7:15:04 AM] System.TimeoutException: The operation has timed out.
                           at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.GetAvailableUpdates() in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 199
[10/25/2024 8:08:57 AM] UniGetUI is up to date
[10/25/2024 8:15:06 AM] Found 0 available updates from .NET Tool
[10/25/2024 8:15:06 AM] Found 0 available updates from Cargo
[10/25/2024 8:15:09 AM] Found 0 available updates from PowerShell7
[10/25/2024 8:15:10 AM] Found 0 available updates from Pip
[10/25/2024 8:15:12 AM] Found 2 available updates from Winget
[10/25/2024 8:16:04 AM] Error finding updates on manager PowerShell
[10/25/2024 8:16:04 AM] System.TimeoutException: The operation has timed out.
                           at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.GetAvailableUpdates() in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 199
[10/25/2024 9:08:57 AM] UniGetUI is up to date
[10/25/2024 9:14:08 AM] Found 7 installed packages from Cargo
[10/25/2024 9:14:08 AM] Found 1 installed packages from .NET Tool
[10/25/2024 9:14:08 AM] Found 13 installed packages from Pip
[10/25/2024 9:14:11 AM] Found 0 installed packages from PowerShell7
[10/25/2024 9:14:13 AM] Found 289 installed packages from Winget
[10/25/2024 9:14:13 AM] Found 58 installed packages from PowerShell
[10/25/2024 9:16:05 AM] Found 0 available updates from .NET Tool
[10/25/2024 9:16:06 AM] Found 0 available updates from Cargo
[10/25/2024 9:16:08 AM] Found 0 available updates from Pip
[10/25/2024 9:16:08 AM] Found 0 available updates from PowerShell7
[10/25/2024 9:16:11 AM] Found 1 available updates from Winget
[10/25/2024 9:17:05 AM] Error finding updates on manager PowerShell
[10/25/2024 9:17:05 AM] System.TimeoutException: The operation has timed out.
                           at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.GetAvailableUpdates() in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 199
[10/25/2024 9:18:19 AM] Found 7 installed packages from Cargo
[10/25/2024 9:18:19 AM] Found 1 installed packages from .NET Tool
[10/25/2024 9:18:19 AM] Found 13 installed packages from Pip
[10/25/2024 9:18:22 AM] Found 0 installed packages from PowerShell7
[10/25/2024 9:18:22 AM] Found 289 installed packages from Winget
[10/25/2024 9:18:22 AM] Adding missing package ScooterSoftware.BeyondCompare.5 to installed packages list
[10/25/2024 9:18:22 AM] Adding missing package MSIX\Microsoft.Winget.Source_2024.1025.1328.52_neutral__8wekyb3d8bbwe to installed packages list
[10/25/2024 9:18:22 AM] Adding missing package MSIX\ScooterSoftware.BeyondCompare.5.ShellExt_<IP_ADDRESS>256_x64__jqqn6e1xs0kqt to installed packages list
[10/25/2024 9:18:25 AM] Found 58 installed packages from PowerShell
[10/25/2024 10:08:58 AM] UniGetUI is up to date
[10/25/2024 10:17:06 AM] Found 0 available updates from Cargo
[10/25/2024 10:17:08 AM] Found 0 available updates from .NET Tool
[10/25/2024 10:17:11 AM] Found 0 available updates from PowerShell7
[10/25/2024 10:17:11 AM] Found 0 available updates from Pip
[10/25/2024 10:17:23 AM] Found 1 available updates from Winget
[10/25/2024 10:18:05 AM] Error finding updates on manager PowerShell
[10/25/2024 10:18:05 AM] System.TimeoutException: The operation has timed out.
                            at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.GetAvailableUpdates() in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 199
[10/25/2024 11:08:58 AM] UniGetUI is up to date
[10/25/2024 11:18:07 AM] Found 0 available updates from Cargo
[10/25/2024 11:18:08 AM] Found 0 available updates from .NET Tool
[10/25/2024 11:18:08 AM] Found 0 available updates from PowerShell7
[10/25/2024 11:18:08 AM] Found 0 available updates from Pip
[10/25/2024 11:18:12 AM] Found 2 available updates from Winget
[10/25/2024 11:19:06 AM] Error finding updates on manager PowerShell
[10/25/2024 11:19:06 AM] System.TimeoutException: The operation has timed out.
                            at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.GetAvailableUpdates() in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 199
[10/25/2024 11:29:52 AM] Found 13 installed packages from Pip
[10/25/2024 11:29:53 AM] Found 7 installed packages from Cargo
[10/25/2024 11:29:54 AM] Found 1 installed packages from .NET Tool
[10/25/2024 11:29:56 AM] Found 289 installed packages from Winget
[10/25/2024 11:29:56 AM] Adding missing package MSIX\Microsoft.Winget.Source_2024.1025.1509.8_neutral__8wekyb3d8bbwe to installed packages list
[10/25/2024 11:29:56 AM] Found 0 installed packages from PowerShell7
[10/25/2024 11:29:56 AM] Loaded operation parameters for package id=Microsoft.OneDrive on manager Winget and operation Update: update --id "Microsoft.OneDrive" --exact --source winget --accept-source-agreements --disable-interactivity --silent --include-unknown --accept-package-agreements --force
[10/25/2024 11:29:58 AM] Found 58 installed packages from PowerShell
[10/25/2024 11:49:40 AM] Found 13 installed packages from Pip
[10/25/2024 11:49:42 AM] Found 7 installed packages from Cargo
[10/25/2024 11:49:44 AM] Found 1 installed packages from .NET Tool
[10/25/2024 11:49:46 AM] Found 289 installed packages from Winget
[10/25/2024 11:49:46 AM] Adding missing package Microsoft.OneDrive to installed packages list
[10/25/2024 11:49:46 AM] Adding missing package MSIX\Microsoft.OneDriveSync_24192.923.6.0_neutral__8wekyb3d8bbwe to installed packages list
[10/25/2024 11:49:46 AM] Adding missing package MSIX\Microsoft.WidgetsPlatformRuntime_<IP_ADDRESS>_x64__8wekyb3d8bbwe to installed packages list
[10/25/2024 11:49:46 AM] Adding missing package MSIX\Microsoft.Winget.Source_2024.1025.1609.36_neutral__8wekyb3d8bbwe to installed packages list
[10/25/2024 11:49:47 AM] Found 0 installed packages from PowerShell7
[10/25/2024 11:49:48 AM] Found 58 installed packages from PowerShell
[10/25/2024 11:50:17 AM] Command parse_pip_search.exe was not found on the system
[10/25/2024 11:50:18 AM] Error finding packages on manager Pip with query git
[10/25/2024 11:50:18 AM] System.AggregateException: One or more errors occurred. (An error occurred trying to start process 'parse_pip_search.exe' with working directory 'C:\WINDOWS\system32'. The system cannot find the file specified.)
                          ---> System.ComponentModel.Win32Exception (2): An error occurred trying to start process 'parse_pip_search.exe' with working directory 'C:\WINDOWS\system32'. The system cannot find the file specified.
                            at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
                            at System.Diagnostics.Process.Start()
                            at UniGetUI.PackageEngine.Managers.PipManager.Pip.FindPackages_UnSafe(String query) in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.Managers.Pip\Pip.cs:line 95
                            at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.<>c__DisplayClass52_0.<FindPackages>b__0() in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 165
                            at System.Threading.Tasks.Task`1.InnerInvoke()
                            at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
                         --- End of stack trace from previous location ---
                            at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
                            at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
                            --- End of inner exception stack trace ---
                            at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
                            at System.Threading.Tasks.Task.Wait(TimeSpan timeout, CancellationToken cancellationToken)
                            at System.Threading.Tasks.Task.Wait(TimeSpan timeout)
                            at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.FindPackages(String query) in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 165
[10/25/2024 11:50:21 AM] Found 100 available packages from .NET Tool with the query git
[10/25/2024 11:50:21 AM] Found 17 available packages from PowerShell7 with the query git
[10/25/2024 11:50:22 AM] Found 17 available packages from PowerShell with the query git
[10/25/2024 11:50:23 AM] Found 203 available packages from Winget with the query git
[10/25/2024 11:50:32 AM] Found 0 available packages from Cargo with the query git
[10/25/2024 11:51:49 AM] Command parse_pip_search.exe was not found on the system
[10/25/2024 11:51:51 AM] Error finding packages on manager Pip with query Pytjon
[10/25/2024 11:51:51 AM] System.AggregateException: One or more errors occurred. (An error occurred trying to start process 'parse_pip_search.exe' with working directory 'C:\WINDOWS\system32'. The system cannot find the file specified.)
                          ---> System.ComponentModel.Win32Exception (2): An error occurred trying to start process 'parse_pip_search.exe' with working directory 'C:\WINDOWS\system32'. The system cannot find the file specified.
                            at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
                            at System.Diagnostics.Process.Start()
                            at UniGetUI.PackageEngine.Managers.PipManager.Pip.FindPackages_UnSafe(String query) in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.Managers.Pip\Pip.cs:line 95
                            at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.<>c__DisplayClass52_0.<FindPackages>b__0() in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 165
                            at System.Threading.Tasks.Task`1.InnerInvoke()
                            at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
                         --- End of stack trace from previous location ---
                            at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
                            at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
                            --- End of inner exception stack trace ---
                            at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
                            at System.Threading.Tasks.Task.Wait(TimeSpan timeout, CancellationToken cancellationToken)
                            at System.Threading.Tasks.Task.Wait(TimeSpan timeout)
                            at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.FindPackages(String query) in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 165
[10/25/2024 11:51:52 AM] Found 0 available packages from Cargo with the query Pytjon
[10/25/2024 11:51:54 AM] Found 0 available packages from .NET Tool with the query Pytjon
[10/25/2024 11:51:55 AM] Found 0 available packages from Winget with the query Pytjon
[10/25/2024 11:52:17 AM] Command parse_pip_search.exe was not found on the system
[10/25/2024 11:52:18 AM] Error finding packages on manager Pip with query Python
[10/25/2024 11:52:18 AM] System.AggregateException: One or more errors occurred. (An error occurred trying to start process 'parse_pip_search.exe' with working directory 'C:\WINDOWS\system32'. The system cannot find the file specified.)
                          ---> System.ComponentModel.Win32Exception (2): An error occurred trying to start process 'parse_pip_search.exe' with working directory 'C:\WINDOWS\system32'. The system cannot find the file specified.
                            at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
                            at System.Diagnostics.Process.Start()
                            at UniGetUI.PackageEngine.Managers.PipManager.Pip.FindPackages_UnSafe(String query) in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.Managers.Pip\Pip.cs:line 95
                            at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.<>c__DisplayClass52_0.<FindPackages>b__0() in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 165
                            at System.Threading.Tasks.Task`1.InnerInvoke()
                            at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
                         --- End of stack trace from previous location ---
                            at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
                            at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
                            --- End of inner exception stack trace ---
                            at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
                            at System.Threading.Tasks.Task.Wait(TimeSpan timeout, CancellationToken cancellationToken)
                            at System.Threading.Tasks.Task.Wait(TimeSpan timeout)
                            at UniGetUI.PackageEngine.ManagerClasses.Manager.PackageManager.FindPackages(String query) in C:\SomePrograms\WingetUI-Store\src\UniGetUI.PackageEngine.PackageManagerClasses\Manager\PackageManager.cs:line 165
[10/25/2024 11:52:20 AM] Found 0 available packages from PowerShell7 with the query Pytjon
[10/25/2024 11:52:20 AM] Found 0 available packages from PowerShell with the query Pytjon
[10/25/2024 11:52:23 AM] Found 100 available packages from .NET Tool with the query Python
[10/25/2024 11:52:23 AM] Found 88 available packages from Winget with the query Python
[10/25/2024 11:52:31 AM] Found 1 available packages from Cargo with the query Python
[10/25/2024 11:52:52 AM] Found 18 available packages from PowerShell7 with the query Python
[10/25/2024 11:52:54 AM] Found 0 available packages from PowerShell with the query Python

Package Managers Logs
Manager WinGet with version:
System WinGet CLI Version: v1.9.1981-preview
Using Native WinGet helper (COM Api)

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListSources
Process start time: 10/25/2024 2:08:57 AM
Process end time:   10/25/2024 2:08:57 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged subprocess-based task on manager Winget. Task type is RefreshIndexes
Subprocess executable: "C:\Users\murra\AppData\Local\Microsoft\WindowsApps\winget.exe"
Command-line arguments: " source update --disable-interactivity"
Process start time: 10/25/2024 2:09:03 AM
Process end time:   10/25/2024 2:09:04 AM

-- Process STDOUT
 ...

Return code: SUCCESS (0)

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListInstalledPackages
Process start time: 10/25/2024 2:09:03 AM
Process end time:   10/25/2024 2:09:13 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListUpdates
Process start time: 10/25/2024 2:09:05 AM
Process end time:   10/25/2024 2:09:13 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListSources
Process start time: 10/25/2024 2:09:05 AM
Process end time:   10/25/2024 2:09:05 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged subprocess-based task on manager Winget. Task type is RefreshIndexes
Subprocess executable: "C:\Users\murra\AppData\Local\Microsoft\WindowsApps\winget.exe"
Command-line arguments: " source update --disable-interactivity"
Process start time: 10/25/2024 3:10:04 AM
Process end time:   10/25/2024 3:10:04 AM

-- Process STDOUT
 ...

Return code: SUCCESS (0)

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListUpdates
Process start time: 10/25/2024 3:10:04 AM
Process end time:   10/25/2024 3:10:17 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged subprocess-based task on manager Winget. Task type is RefreshIndexes
Subprocess executable: "C:\Users\murra\AppData\Local\Microsoft\WindowsApps\winget.exe"
Command-line arguments: " source update --disable-interactivity"
Process start time: 10/25/2024 4:11:04 AM
Process end time:   10/25/2024 4:11:05 AM

-- Process STDOUT
 ...

Return code: SUCCESS (0)

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListUpdates
Process start time: 10/25/2024 4:11:05 AM
Process end time:   10/25/2024 4:11:09 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged subprocess-based task on manager Winget. Task type is RefreshIndexes
Subprocess executable: "C:\Users\murra\AppData\Local\Microsoft\WindowsApps\winget.exe"
Command-line arguments: " source update --disable-interactivity"
Process start time: 10/25/2024 5:12:04 AM
Process end time:   10/25/2024 5:12:05 AM

-- Process STDOUT
 ...

Return code: SUCCESS (0)

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListUpdates
Process start time: 10/25/2024 5:12:05 AM
Process end time:   10/25/2024 5:12:09 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged subprocess-based task on manager Winget. Task type is RefreshIndexes
Subprocess executable: "C:\Users\murra\AppData\Local\Microsoft\WindowsApps\winget.exe"
Command-line arguments: " source update --disable-interactivity"
Process start time: 10/25/2024 6:13:04 AM
Process end time:   10/25/2024 6:13:05 AM

-- Process STDOUT
 ...

Return code: SUCCESS (0)

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListUpdates
Process start time: 10/25/2024 6:13:05 AM
Process end time:   10/25/2024 6:13:09 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged subprocess-based task on manager Winget. Task type is RefreshIndexes
Subprocess executable: "C:\Users\murra\AppData\Local\Microsoft\WindowsApps\winget.exe"
Command-line arguments: " source update --disable-interactivity"
Process start time: 10/25/2024 7:14:04 AM
Process end time:   10/25/2024 7:14:07 AM

-- Process STDOUT
 ...

Return code: SUCCESS (0)

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListUpdates
Process start time: 10/25/2024 7:14:07 AM
Process end time:   10/25/2024 7:14:12 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged subprocess-based task on manager Winget. Task type is RefreshIndexes
Subprocess executable: "C:\Users\murra\AppData\Local\Microsoft\WindowsApps\winget.exe"
Command-line arguments: " source update --disable-interactivity"
Process start time: 10/25/2024 8:15:04 AM
Process end time:   10/25/2024 8:15:07 AM

-- Process STDOUT
 ...

Return code: SUCCESS (0)

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListUpdates
Process start time: 10/25/2024 8:15:07 AM
Process end time:   10/25/2024 8:15:12 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListInstalledPackages
Process start time: 10/25/2024 9:14:07 AM
Process end time:   10/25/2024 9:14:13 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged subprocess-based task on manager Winget. Task type is RefreshIndexes
Subprocess executable: "C:\Users\murra\AppData\Local\Microsoft\WindowsApps\winget.exe"
Command-line arguments: " source update --disable-interactivity"
Process start time: 10/25/2024 9:16:05 AM
Process end time:   10/25/2024 9:16:06 AM

-- Process STDOUT
 ...

Return code: SUCCESS (0)

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListUpdates
Process start time: 10/25/2024 9:16:06 AM
Process end time:   10/25/2024 9:16:11 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListInstalledPackages
Process start time: 10/25/2024 9:18:18 AM
Process end time:   10/25/2024 9:18:22 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged subprocess-based task on manager Winget. Task type is RefreshIndexes
Subprocess executable: "C:\Users\murra\AppData\Local\Microsoft\WindowsApps\winget.exe"
Command-line arguments: " source update --disable-interactivity"
Process start time: 10/25/2024 10:17:05 AM
Process end time:   10/25/2024 10:17:09 AM

-- Process STDOUT
 ...

Return code: SUCCESS (0)

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListUpdates
Process start time: 10/25/2024 10:17:09 AM
Process end time:   10/25/2024 10:17:23 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged subprocess-based task on manager Winget. Task type is RefreshIndexes
Subprocess executable: "C:\Users\murra\AppData\Local\Microsoft\WindowsApps\winget.exe"
Command-line arguments: " source update --disable-interactivity"
Process start time: 10/25/2024 11:18:05 AM
Process end time:   10/25/2024 11:18:08 AM

-- Process STDOUT
 ...

Return code: SUCCESS (0)

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListUpdates
Process start time: 10/25/2024 11:18:08 AM
Process end time:   10/25/2024 11:18:12 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListInstalledPackages
Process start time: 10/25/2024 11:29:51 AM
Process end time:   10/25/2024 11:29:56 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListInstalledPackages
Process start time: 10/25/2024 11:49:40 AM
Process end time:   10/25/2024 11:49:46 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged native task on manager Winget. Task type is FindPackages
Process start time: 10/25/2024 11:50:18 AM
Process end time:   10/25/2024 11:50:23 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged native task on manager Winget. Task type is FindPackages
Process start time: 10/25/2024 11:51:50 AM
Process end time:   10/25/2024 11:51:55 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Logged native task on manager Winget. Task type is FindPackages
Process start time: 10/25/2024 11:52:19 AM
Process end time:   10/25/2024 11:52:23 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Relevant information
No response
Screenshots and videos

If you go to Windows Settings -> Installed apps, do they appear  there?

Marti:
Not all of them, see attachment.
Murray

From: Martí Climent @.>
Sent: Friday, October 25, 2024 12:36 PM
To: marticliment/UniGetUI @.>
Cc: MurraySobol @.>; Author @.>
Subject: Re: [marticliment/UniGetUI] multiple versions of Python (Issue #2892)
If you go to Windows Settings -> Installed apps, do they appear there?
—
Reply to this email directly, view it on GitHubhttps://github.com/marticliment/UniGetUI/issues/2892#issuecomment-2438282797, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJWUNK6QJC3DZEFXYW6NLRDZ5JXQ5AVCNFSM6AAAAABQTSPNEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZYGI4DENZZG4.
You are receiving this because you authored the thread.Message ID: @.***>

But how many of them?


Error: Cannot find module<EMAIL_ADDRESS>

Hi Kevin,
FYI: I updated one of my MS sites and now when I run
"build": "microbundle --target node --no-sourcemap -f cjs,esm --strict --generateTypes=false"
I get this error:
><EMAIL_ADDRESS>watch
> nodemon metalsmith.js

[nodemon] 2.0.21
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): src/**/* templates/**/*
[nodemon] watching extensions: js,css,scss,njk,json,html,md
[nodemon] starting `node metalsmith.js`
node:internal/modules/cjs/loader:499
      throw e;
      ^

Error: Cannot find module<EMAIL_ADDRESS>    at createEsmNotFoundErr (node:internal/modules/cjs/loader:983:15)
    at finalizeEsmResolution (node:internal/modules/cjs/loader:976:15)
    at resolveExports (node:internal/modules/cjs/loader:493:14)
    at Function.Module._findPath (node:internal/modules/cjs/loader:533:31)
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:942:27)
    at Function.Module._load (node:internal/modules/cjs/loader:804:27)
    at Module.require (node:internal/modules/cjs/loader:1028:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/Users/wernerglinka/Documents/Projects/Metalsmith/>>>components/metalsmith.js:10:17)
    at Module._compile (node:internal/modules/cjs/loader:1126:14) {
  code: 'MODULE_NOT_FOUND',
  path<EMAIL_ADDRESS>}
[nodemon] app crashed - waiting for file changes before starting...
[Browsersync] Access URLs:
 -------------------------------------
       Local: http://localhost:3000
    External: http://<IP_ADDRESS>:3000
 -------------------------------------
          UI: http://localhost:3001
 UI External: http://localhost:3001
 -------------------------------------
[Browsersync] Serving files from: build
[Browsersync] Watching files...

I checked the node_modules/@metalsmith/postcss/lib folder and I see a fileindex.d.ts but no index.cjs.

@wernerglinka that's weird, when you look at the latest release on NPM's code tab, then open the lib folder, you will see it is included: https://www.npmjs.com/package/@metalsmith/postcss?activeTab=code.
So I'd suggest rm -rf'ing node_modules or reinstalling the plugin. FWIW this path looks really weird with the 3 >>>:
/Users/wernerglinka/Documents/Projects/Metalsmith/>>>components/node_modules

PS: could you refer to me using the @webketje handle on Github instead of my name thx

Thanks, @webketje. The >>>are part of the file name on my Mac. I already removed the node_modules folder and package-lock.json but no deal. I'll update this issue when I find what causes this.
Werner Glinka
@.***
650 867 0778

On Mar 21, 2023, at 6:56 PM, Kevin Van Lierde @.***> wrote:
@wernerglinka https://github.com/wernerglinka that's weird, when you look at the latest release on NPM's code tab, then open the lib folder, you will see it is included: @.***/postcss?activeTab=code.
So I'd suggest rm -rf'ing node_modules or reinstalling the plugin. FWIW this path looks really weird with the 3 >>>:
/Users/wernerglinka/Documents/Projects/Metalsmith/>>>components/node_modules
PS: could you refer to me using the @webketje https://github.com/webketje handle on Github instead of my name thx
—
Reply to this email directly, view it on GitHub https://github.com/metalsmith/postcss/issues/2#issuecomment-1478740042, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACUQAGGYNXKCQ4TK5WOESDW5I53PANCNFSM6AAAAAAWDDMECA.
You are receiving this because you were mentioned.


Language Identification Quality Threshold exposed?

Is your feature request related to a problem? Please describe.
When testing Language Identification in the java SDK, we seem to get a reasonable number of "no match results"
Describe the solution you'd like
Is there a quality threshold that determines the difference between perhaps a low confidence language result and a noMatch language result?
Is this threshold exposed in any way for the customer to set, perhaps through the setServiceProperty in SpeechConfig?
Related: Is there a list of all the properties which can be set with Speechconfig.setServiceProperty?

Hi @aargreen , thank you for posting these questions.
If you can share an example of an audio file for which you are getting NoMatch, but expect a valid Language ID result, we can run it on our side and have a look. It does take a few seconds of speech to get reliable Language identification.
Speech SDK does not expose a "quality threshold" now, but we are working at the moment on updating the Language ID feature to allow more choices by the developer. This will probably address your request.
Regarding SpeechConfig.setServcieProprty, those properties are mostly meant for internal usage and a few configuration options of new service features in public preview. When relevant, they will be shown in sample code in this repo of on docs.microsoft.
Darren

Thanks @dargilco for the responses.  I think will hold off on providing examples for now, but may look into it in the future.  Ok to close the ticket from my end.


The index documents are usually kept in-memory, but they are also persisted and cached into the disk. This is because the index documents can take up a lot of memory and so might not be good to keep them all in memory (Java projects can huge, mind you, especially if using 3rd party libraries). Also having index documents persisted in a file, means they can be loaded quicker when the IDE restarts. (that is quicker than re-indexing the source file)
Also, the reason the index is divided into documents that correspond to the source file they originate from, is because it makes it easier to update them (the index documents). When a user types some text, it invalidate the index for the source file being edited. This is also why an entry such as <REF, 8:12, "foo"> for say source file "file_A.rs" does not contain the fully qualified name/id of the element "foo" the reference points at. Because such resolution could become invalid if a source file other than "file_A.rs" is edited. In this way, the index documents are designed so that their entries only depend on the source file they originate from, not other source files.

Now, I'm not saying this is the architecture that RLS should have.
What I'm saying is that this details with some precision how the data structures for an IDE/oracle engine are structured, how they are updated in face of user editing, how queries use them, etc.. In the RFC it is not clear at all what the suggested design is (at least I cant figure it out).
Some points I think this should bring up:

We should make a distinction, at least conceptually, between compilation-analysis data and query-analysis data.
How is compilation-analysis data structured, in such a way that allows for incremental compilation. I think this a very important consideration that should be kept in mind at all times, because incremental compilation is going to be very useful, if not crucial, for RLS.
How much overlap should exist between compilation-analysis data and query-analysis data? Should a user query use both, or just the query-analysis data? For example if a user asks "what definition is pointed to at location X?", does that use the same data structures that an incremental compiler would use, or does it use a separate query-analysis data stored in a different format? (I think it should be the former case)
Should the compilation-analysis data be structured in a SQL database, or a simpler data structure, closer to the AST/MIR?

@bruno-medeiros FWIW the compiler no longer works on the AST but HIR, which started out as being identical to the AST but is getting differential improvements, e.g. Items are no longer nested in terms of ownership, i.e. an ItemMod effectively containing a vector of Item IDs, instead of the Items themselves.
There have also been suggestions along the lines of having a HIR format which can be memory-mapped from metadata found in crates.

What again is the save-analysis?

It's @nrc's pass to convert from Rust's internal representations into some textual DXR-friendly format (based on CSV atm AFAIK).
IMO save-analysis is a massive bodge and all of the work it does could be abstracted into a nicer internal compiler API, on top of which RLS could be built.
There are 0 uses for having a textual format for storing any kind of metadata at any point during RLS' operation.

Should the compilation-analysis data be structured in a SQL database, or a simpler data structure, closer to the AST/MIR?

I believe it should be using the HIR: not something like the HIR, and not the HIR alone, but a layer on top of the HIR.
The HIR and the existing side-tables form the data store, while the RLS database is a layer of indexes which the compiler itself doesn't already have, or does have but doesn't lend itself to RLS queries (such as fuzzy searches).

In this way, the index documents are designed so that their entries only depend on the source file they originate from, not other source files.

This is solved by building RLS on top of incremental compilation instead of overengineering it.
Given the flexible and automatic approach @nikomatsakis took for tracking dependencies between compiler passes, for incremental recompilation, it should be possible to also track RLS indexes using the same mechanism and recompute them as necessary.

@bruno-medeiros @eddyb to clarify, when I say save-analysis API I do not mean the csv dump, I mean the API (which is WIP) that provides some of the services as functions, see trans::save::get_item_data, etc. This is just an API for the compiler to provide information about it's data without exposing its internals. There is no textual representation anywhere.
Note that interaction with the save-analysis API uses the AST, not the HIR because the HIR is meant to be private to the compiler, whereas the AST is public API.
I intentionally left the specification of the database vague. I don't believe it will benefit from too much up-front planning. A relational SQL database is what I have in mind, but I know there are many options (DXR for example use ElasticSearch, but I don't think that would be useful for the RLS since it will be doing mostly relational, not textual, queries).
@bruno-medeiros, that's a lot of info, thanks! It'll take me a little while to chew that over. In the mean-time, I'll answer the questions that I can:
For incremental compilation, the compiler will return a set of code which is invalidated, either by span in the source or by node id. We can then query the db using this set and delete all records from the DB.
In the alternatives section, I discuss a little bit the option of using incremental compilation data rather than our own DB layer. All other things being equal, I would prefer to just use the data we have, rather than stick a DB on top. However, I see two big points in favour of the DB: first is timing - incremental compilation data will not support this out of the box - the starting point is not to keep data for function bodies, only items. So if incremental compilation is fast enough, it is not clear when (if ever) we'll get the required data for the RLS. It is certainly not as simple as serialising the HIR or MIR.
Secondly indexing: I hope that we could actually be quick enough to use the 'raw' data without indexing. The only query which requires non-local data is find-all-references, which is not expected to be instantaneous. I believe one could read and search the data for references, without indexing, in a few seconds for the largest programs. However, for more sophisticated searches we would need indexing, and maybe even for find-all-references if that was not fast enough. As soon as we get into managing indexes ourselves, I would rather outsource this to a general purpose database. This stuff is hard to do and there is no point in us rolling our own. I believe that is the more complex solution.
@eddyb I see using a database to abstract away questions about indexing, when to read data from disk, etc., as a simplification. The "HIR alone" + layers on top + indexes seems more complex to me, especially as we would need to heavily modify the HIR first. The only advantage of not using the DB is that invalidation is easier.

(disclaimer: racer maintainer!)
Personally I'd like to see this RFC focus on compiler changes to enable IDE functionality, rather than building an RLS server product. I think originally the proposal was called 'Changes to the compiler to support IDEs' and that is more where I think this should go.
The big problems blocking the analysis required for good IDE functionality are:

how to generate analysis information for pieces of code, fast. (interactive compile)
how to analyze unfinished or incomplete code

These require an official rust-team backed proposal because they involve changes to the rust compiler and so need coordination and to be blessed by rust teams. There is only one rust compiler.
The other stuff is much more speculative - we are talking about how an ide should be wired together and what functionality it should have.
There can be many solutions here, and specifying one - the RLS (and implicitly giving it rust team blessing) will discourage the community from taking up future projects in this area.

To clarify: I'm not saying we shouldn't discuss this stuff and build software as part of this effort. In fact this is required to drive out the necessary compiler changes. However only the compiler changes require official rust-team blessing.
Moreover:

Having an official Rust Language Server program as the only stable interface to the compiler means all future ide functionality involving analysis would also have to be specified and built into it.

It has a narrow vertical interface. The RLS is saying 'here's how completion and navigation functionality will work in an ide'.

I would like to see: 'here's how to get analysis information out of the compiler, fast and for incomplete code'.

I completely agree with @phildawes here. I don't think rustc should be in the business of dictating the details of how editors should access completion/semantic info. We need a stable library to access this data; no more, no less. Again, look at libclang.

@phildawes, I think (hope) we are more in agreement than it would appear. Maybe the choice of names and the use of requirements are misleading. I'll try and clarify.

how to generate analysis information for pieces of code, fast. (interactive compile)

this is discussed in the RFC. To summarise, start with incremental compilation, then extend with lazy compilation keeping the compiler in memory.

how to analyze unfinished or incomplete code

I decided this stuff was unrelated to the rest of this RFC and removed it. It is still a priority. Some is implemented already. What remains is error recovery in the parser. This may or may not be in an RFC, but it will be a separate one if it gets one. It might be simple enough to just implement.
On the question of doing too much  of the IDE's work, let me revisit two of the requirements. I do want to only supply the data from the compiler and let the IDE do the rest, I certainly don't want to constrain innovation in the IDE or other tools. By choosing these requirements I'm just picking some things an IDE might want to do in order to ensure the RLS meets those needs. I'm not saying an IDE must do them or must do them in the way suggested.

highlight all references to an item on the page

The RLS here is just returning a list of references to the IDE. I.e., a lookup and a reverse lookup in the name resolution tables. The data is limited to a single file. The important thing is that data is limited to one crate (which makes the search easier for the RLS).
The IDE is free to use that information however it likes. It could use it to highlight the other uses on the screen/in the file. The RLS is not doing this though.

code completion

Here, the RLS is taking a cursor position and a compiled file and returning a list of fields or methods that could be called. It is explicitly not doing full code completion. In particular the IDE (or Racer) would need to filter this list according to what is typed, possibly applying spelling correction, etc. The list would also be structured data giving information about the fields and methods such as types and where they are defined. It is up to the client to decide how to present this data (just names, or more info). This seems the minimal information that the compiler could provide.
I feel like maybe the name and the mode of operation (daemon process, etc.) are distracting from the information presented. Again, this is a low level library, simply presenting the compiler's data in an easy to consume way. What data is exposed is a separate issue to how it is exposed, and I believe here that presenting an IPC API is a convenience for clients (note in addition to a standard, in-process library API for those who choose to access it that way).
@Valloric to address the libclang alternative approach. Having a stable interface to compiler internals is somewhat orthogonal to providing a nice interface for IDEs. In some ways it is a much harder question, because we would want to expose much more of the compiler and that risks de-facto stabilisation of some parts. There are plans in this area - the save-analysis API is a low-level library for accessing compiler internals without exposing implementation details. It is WIP. In the longer run, we will probably design some kind of compiler plugin API.
However, even if we concentrated on this approach it is not suitable for an IDE. One point is speed. The RLS as proposed takes care of managing compilation, this is necessary especially for fast compilation models in the future. This work would be identical between IDEs, so there seems no point in making them duplicate it. Second point is that for searching you need access to the whole program, not just a single crate. The compiler only has access to the current crate and item signatures in upstream crates. For searches, the IDE needs function bodies for all crates. Managing that is tricky and again is something that all clients must do, so it makes sense to provide it in the RLS.

Hi @nrc! Sorry I don't think I made myself clear. I'm arguing for just the analog of the 'save-analysis' api to be specified here. The way to extract analysis information from the compiler, fast and for incomplete code. This requires agreement and rust-team blessing to progress because it requires changes to rustc.
Not 'code-completion', 'find-references', 'find-definition'.

I think one thing that is clear is that the means by which the IDE and RLS
communicate is beyond the scope of this RFC.  The optimum mechanism will
likely be IDE- and possibly platform- specific and I doubt that plaintext
HTTP will be the answer (noteably, it is a poor choice on multi-user
systems because if the server dies a local attacker can replace it and
cause an information leak at a minimum).  Something based on Windows named
pipes and Unix domain sockets is far more satisfactory from a security
perspective.  HTTP may require TLS with cert pinning.
On Jan 18, 2016 2:14 AM, "Phil Dawes"<EMAIL_ADDRESS>wrote:

Hi @nrc https://github.com/nrc! Sorry I don't think I made myself
clear. I'm arguing for just the analog of the 'save-analysis' api to be
specified here. The way to extract analysis information from the compiler,
fast and for incomplete code. This requires agreement and rust-team
blessing to progress because it requires changes to rustc.
Not 'code-completion', 'find-references', 'find-definition'.
—
Reply to this email directly or view it on GitHub
https://github.com/rust-lang/rfcs/pull/1317#issuecomment-172447806.

I still think a full relational database seems overkill. Mostly because virtually all of the IDE queries will be relatively simple in structure. But anyways, this ultimately is an RLS implementation aspect, and I think it's of limited value to be discussing upfront design for implementation aspects of RLS (even though I did just that before :sweat_smile: ).  Also, not to mention this a feature that depends on other more essential features to be implemented first.
Of more importance are the functionality goals and general design principles of RLS, and in this I agree with @phildawes and @Valloric too: it is best to focus on incremental improvements to rustc that would make it more amenable to use by IDEs and RLS. I'd rather see API being gradually introduced (even if very unstable API), than no API at all. But rustc would have to be fully committed to this design objective, not just do things half-way. Otherwise it might make things hard for RLS, hard to a point that RLS might have been better off just using the rustc parser, and then working with the AST on it's own (which is essentially, what Racer does currently, correct?).

@phildawes ah, so maybe not so much agreement :-) Let's look at a higher level: to get IDE (and IDE-like support) we need three pieces - the compiler, middleware, and the editor. I don't intend doing any planning in the editor space, it seems implementation is well under way. The compiler needs some work - it must be faster and more robust. Work is already underway on incremental compilation, lazy compilation may be built on top of that, but I don't think we can spec it in much detail until incremental compilation is further along. Furthermore, incremental compilation alone will get us a long way - from impossible to use to either annoyingly slow or good enough, so I don't consider faster compilation too important right now. On the robust-ness front, I think that the only big issue is error recovery in the parser - I do want to get into that, but it seems pretty orthogonal to this RFC.
So that leaves the middleware and that is what I am trying to plan in this RFC. I think this is necessary because there is a lot of work in getting data from the compiler to an IDE, and it is work that must be done by all IDEs and (although a bit complex) doesn't offer any room for innovation. The work required is managing compilation, preservation of data between compiler runs, and some cross-referencing of that data.
I'm not really sure what you are objecting to - you seem to be saying that we should not be planning the middleware at all, rather than that the plan should change. To me, the middleware seems to be the most important thing to plan right now.
There will be RFCs for some compiler issues at some point (lazy compilation in the future, perhaps error recovery soon), but for now I think the middleware is more important.
I also want to push back on the the idea that we are providing a high level service here. The data we're providing is low level data - "find all references" is really just find all identifiers with the same definition id, this is just simple cross-referencing of the compiler data (complexity comes from the fact that the data is from multiple crates). "Code completion" is find all fields and methods that are allowed after a dot, this requires post-processing before presenting to the use (by an IDE, not the RLS) and I can't think of a lower-level request to the compiler which would allow you to do type-based code completion that this.

@drbo this is not clear to me. We are designing the RLS, and how the RLS communicates with its clients seems to be a core part of that design. The fact that it is being discussed means it is an important part of the design, not that we should ignore it.
AIUI, securing an HTTP server is pretty much a solved problem. The solution may be complex, but it is known. I would worry far more about securing a new or custom protocol.

@bruno-medeiros I think I answered your comment in the reply to Phil above. But in case not, could you be specific about what you think needs to change in rustc? When you say API, what kind of API are you talking about? My understanding is that the middleware is more of an unknown at the moment than the compiler is.

@bruno-medeiros (in reply to your comment from 3 days ago). Running the compiler in 'compile-anlaysis' is possible today, either from the command line or via the driver API. It is used for example in cargo check. I don't believe there is more to do in this area.
Thanks for the explanation of JDT. What is the advantage of splitting the index data from the compilation data? I see a few - no duplication of the compilation data, smaller index data, easier updating, perhaps the index data can be used without the compile data for some things? The first few don't seem very important today (maybe on low powered hardware), I don't know about the last.
The Rust equivalent of compilation data will exist in the incremental compilation data. However, that will not contain enough information (initially) to re-compile inside a function body. It will probably not be optimal for searching (this might be solvable with indexes over the data, etc., but compelxity). I'm also keen not to constrain evolution of the compiler at this stage. So, I think it is best for the RLS to keep its own copy of compilation data. Given that, it seems simplest to combine the index and compile data that the RLS holds.
For me, the simplest solution to managing this data is just to dump it into a relational database. Let the db manage when to read from disk, manage indexes, etc. These are hard problems and I don't see how we can do better by doing it ourselves (without an awful lot of effort). I also don't see this as complexity - clearly there is complexity but it is isolated and abstracted in the database.
Querying data (for search-like queries) is trivial. Looking up potential methods and fields is probably best answered from the compiler directly, rather than via the db since it needs some non-trivial computation.
Invalidating data is slightly more complex, but still fairly straightforward - the compiler will inform the RLS of spans in the (old) source code which are invalid, we then delete any data from the db within these spans.

Hi @nrc, Thanks for replying, sorry if my comments are coming over a bit snarky.
I do think we should be talking about middleware, how it can work, what will be required by clients and from the compiler. However I think saying there will be one official rust program to provide all the analysis operations for IDEs, and that it will be the only way for an clients to perform these operations is a bit far.
It worries me because it affects racer, racerd and other future community projects. My initial reaction to RLS is 'if at some point there is going to be an official rust language server then I should probably stop working on racer'.
I do view the RLS operations as high level, as with no other way to extract analysis information from rustc they dictate the only operations an IDE can provide. There is a strong burden to support every operation an IDE could conceivably want to do.
For example,

"Code Completion" is find all fields and methods that are allowed after a dot:

is this all the currently legal fields/methods?
What about currently private fields?
What about non-imported modules?

I don't want that every time an IDE wants to do something new or slightly different it requires adding a new operation or additional functionality to the RLS.
If an IDE or client tool wants to add refactoring functionality - e.g. Extract Method, does it have to wait for the right operations to be added to RLS to support this?
Instead I'm advocating getting the compiler analysis extraction interface right. I think the save-analysis information in a library form is a good starting point.
There are tradeoffs involved in the RLS design, both implementation tradeoffs (relational db?, separate process? http?, up-front caching vs lazy? per-ide? per-workstation?) and functional tradeoffs (which operations?). Saying there will be one official program providing all the operations assumes we can nail a set of tradeoffs that will be right for all IDEs and tooling. I think this is unnecessarily restrictive and I don't think we need to do this to succeed.

Hi @phildawes, so let me take a step back. First off, I don't think there should be one piece of official middleware for ever. I hope that both the interface presented by the middleware to the IDE and the compiler's API will both be stable and specified so we can have alternative implementations. There is a lot of tricky, inter-related levers here, it is an area I don't know much about, and at the compiler end there is a moving target, so I doubt we'll get it right the first time. Furthermore, I don't even think that there is one ideal middleware solution - different tools will want very different levels of abstraction.
I envisage the RLS fitting in between heavyweight IDEs and the compiler. For more lightweight editors and other tools, I don't think that will be ideal. There perhaps the stack is compiler, Racer, editor, or compiler, RLS (without the daemon stuff), Racer, editor.
I think the code completion example is useful for explaining where the RLS fits in - the RLS will return all fields and methods, given what the type will allow (this is still a bit handwavery, but basically what the compiler sees at type checking time). The data returned for each field (and likewise for methods) will be something like an id, a name, a type (possibly both generic and specific), privacy information, attributes, a span for the definition, whether the field is accessible from the current cursor position, and so forth.
The client is then responsible for what to show to the user, whether the client is an IDE or Racer (or other middleware that lives on top of RLS). So the bullet points you suggest are things the client filters on, not the RLS - if the client wants to show inaccessible fields, they can, if they want to add more fields (such as from non-imported modules) they can.
It seems to me that there is a lot of room for innovation in the client here, but not so much in the RLS - it just spits out what the compiler knows
On refactoring, I don't think this should be done by the RLS, the IDE or a refactoring tool should do it. That tool will probably need information that the compiler doesn't provide, so we'll need to add APIs to both the compiler and RLS to expose the low-level data, but I'm assuming that would be an API to check "is this name currently used in this scope", or similar things, not high level things like extract a method. So, "kind of" is the answer, but they'd have to persuade the compiler team first in any case.
Finally, I'd like to push back on the idea that he RLS precludes APIs in the compiler. It does not. We can still (and will) have public APIs in the compiler that tools can use. The RLS is just another point on the spectrum - if you want really low level data - ask the compiler, really high level data - ask Racer, somewhere in between - ask the RLS. In particular, I see the RLS as a convenience to allow asking questions about a whole program, whereas the compiler will only ever allow asking questions about a single crate.
I'm keen to start with the RLS rather than the compiler APIs because I'm more sure of what they should look like and they will help inform what the compiler APIs look like.
To emphasise, I don't see the RLS as a replacement for Racer, but as a tool to help Racer, IDEs, and other tools to have easier access to the compiler's data. Put another way, the vision for the RLS is not to be a tool that uses the compiler, but to lower the bar to entry for tools that want to use the compiler.

@drbo this is not clear to me. We are designing the RLS, and how the RLS communicates with its clients seems to be a core part of that design. The fact that it is being discussed means it is an important part of the design, not that we should ignore it.

Hum, the format of the messages is an important part of the design, but whether the messages are delivered via HTTP, plain TCP sockets, stdin, or something else, not so much. Not until you want to take security into consideration, but it shouldn't affect the operation of the RLS itself (or of the IDE).
Is security the reason why people (@Valloric @jwilm, etc.) where suggesting using HTTP as a base for the RLS communication?

@bruno-medeiros I think I answered your comment in the reply to Phil above. But in case not, could you be specific about what you think needs to change in rustc? When you say API, what kind of API are you talking about? My understanding is that the middleware is more of an unknown at the moment than the compiler is.

I don't have specific sugestions, as I'm not familiar with rustc internals. What I was saying in general about the API, is that the API should allow RLS (the middleware) to build on the compiler and answer all sorts of interesting questions for an IDE, like "find all references to element foo", or "is this name currently used in this scope?". Like you said later on, "we'll need to add APIs to both the compiler and RLS to expose the low-level data". It's a shift to designing a compiler (rustc) as a library for all sorts of purposes, not just compilation into binaries. I'm not familiar with libclang, but I think this is what @Valloric said when he suggested rustc should evolve to be more libclang. (and then RLS would build on top of that)

It is used for example in cargo check

cargo check does nothing on my machine, is this something currently available only on nightly ?

Thanks for the explanation of JDT. What is the advantage of splitting the index data from the compilation data?

Like you said, easier updating/invalidation, but also, I think because it is very easy to persist the index data to disk, because it consists of only plain textual (or number) data. There are no references to other objects (unlike the compilation-data which has lots of references between itself, complex data structures, etc.).

For me, the simplest solution to managing this data is just to dump it into a relational database. Let the db manage when to read from disk, manage indexes, etc. These are hard problems and I don't see how we can do better by doing it ourselves (without an awful lot of effort).

I'm not saying we should write our own code to handle disk/memory caching, etc. (although I don't think it would be that hard of a problem, for the purposes of RLS usage alone). There might be some other libraries that help with that already. What about using a no-sql database? That might a better choice. To be honest it's not an area I'm familiar with, so I don't know what could be good choices here. On top of that we are also constrained a bit by how easy it would be to use such libraries/databases in Rust (ie, if there is already Rust code to interact with the library/database or not).

@phildawes

I don't want that every time an IDE wants to do something new or slightly different it requires adding a new operation or additional functionality to the RLS. E.g. If an IDE or client tool wants to add refactoring functionality - e.g. Extract Method, does it first have to convince the RLS team to add the right operations to RLS?

Hum, yes. Or the IDE developers have to modify RLS themselves to do that. I mean, RLS will be an open-source project, so it will be easy to add patches (or even fork/mod).
You seem to not like this scenario, but what alternative could there be? The other alternative I can think of is not practical: to have RLS submit all sorts of low-level compiler data to the IDE, and then IDE try to figure things for itself. Mind you, the IDE would be a different process, and likely written in a different language (C, Java, etc.), so you are talking about marshaling very complex Rust data structures to a different language.

@nrc I still don't understand why you would ever use an external database, and here's why:
We already have a highly specialized & efficient pure Rust relational database; we call it "librustc"
Our on-disk metadata format already has a hash index, but even ignoring that:
Incremental recompilation will also require us to have on-disk formats which support (amortized) O(1) insertion, removal and lookup.
So why use a relational database, when you have all of that infrastructure?
Why spend time binding to some C library and writing all of the transformations from our structures to something dumb enough for it to understand?
Relational databases certainly aren't magic and a lot of the complexity they have is around handling arbitrary data in arbitrary ways.
We have specialized data and special needs, therefore a relational database is not only overkill, but potentially harmful.
And I haven't really touched the save-analysis stuff: are you seriously suggesting that we dump all the compiler data in bulk into some stringly-typed mush?
How will that scale to very large crates like the compiler itself?
That's where I most need an IDE, and your plan seems to cripple that usecase.
In any case, my prediction, were this plan of yours to be put in practice, is that at some point, someone will rewrite all of that unnecessary abstraction, reducing code size and eliminating one (or more) non-Rust dependencies.
You will have an increase in performance and anyone looking at the diff will wonder why it was so complicated in the first place.

@eddyb
sqlite is quite nice as a file storage format, though I am not sure how capable it will be of handling rustc's very chatty reads.

In any case, my prediction, were this plan of yours to be put in practice, is that at some point, someone will rewrite all of that unnecessary abstraction, reducing code size and eliminating one (or more) non-Rust dependencies.

That might very well be true and I'd like to point out that it is a good thing!
"When designing a new kind of system, a team will design a throw-away system (whether it intends to or not). This system acts as a "pilot plant" that reveals techniques that will subsequently cause a complete redesign of the system." - https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_pilot_system

Relational databases certainly aren't magic and a lot of the complexity they have is around handling arbitrary data in arbitrary ways.
We have specialized data and special needs, therefore a relational database is not only overkill, but potentially harmful.

Relational databases are self-docummenting. You have a table, you can always look it up, see what columns, expression indexes, foreign keys it has, browse the data, make some slight modifications necessary for debugging, etc. It's like always having an UML diagram on hand.
In my experience, and I worked with both the relational and the key-value (LevelDB, LMDB, Riak, Cassandra, Voldemort) databases, the relational side is much easier to prototype with. And as you've noted youself, they're interchangeable, what you keep in a relational database you can keep in key-value store and vice versa, so if the compiler can use a specialized structure then it can use the relational database as well. The nice property of relational databases is that you don't have to maintain the index integrity or even the referential integrity by yourself. You don't have to reinvent the necessary abstractions. Want to upgrade your data to a different format? It's a matter of several SQL queries and not of writing a whole program just to make that tiny upgrade possible, or maintaining the code of the old model in order to be able to access that old format during the upgrade.
Eventually both approaches have their gotchas and shortcuts to efficient use. And both can fail miserably. It all depends. That's why I think that picking one over another shouldn't be a part of this RFC but rather an implementation detail left out to implementors and what they're most familiar and comfortable with.

@bruno-medeiros I agree we don't need to go in to too much detail - but whether we use a library or IPC seems important.

Is security the reason why people (@Valloric @jwilm, etc.) where suggesting using HTTP

I believe ease of use is a more important reason. Security has been mentioned as a reason not to use HTTP.

cargo check does nothing on my machine, is this something currently available only on nightly ?

Not exactly sure which version of Cargo is required, but it is fairly recent.
It may be better to use NoSql rather than an SQL db, I'm not an expert in the space. I know DXR uses ElasticSearch, but that is more to support fancy text searching. I've found old school SQL dbs to be quite a good match for PL stuff in the past - the data is very homogeneous, cross-referencing by id fits the relational paradigm nicely, etc.

@eddyb all things being equal I would like to re-use the compiler's data, there are a few reasons not:

it's not usable now. Incremental compilation data isn't done and it's likely to change a fair bit even once it is done.
metadata and planned incremental compilation data does not store any info about function bodies - we would have to serialise all this extra info. It will probably not be used for anything else, so it would be just for the RLS. We would want to not emit it in other cases, because it would be a large amount of data.
none of this data is designed to be used by anyone except the compiler - sure it can be used, but it will not be trivial. In the compiler the functions for reading the data are tightly coupled to how the data is used, if we want to use it in other ways we need to implement that.
stability - this is all compiler-internal stuff which we might change at any moment.
complex searches, in the future we might want to add sophisticated searches like 'find all impls of this trait' - each search like this would mean adding another index over the data and thus more and more complexity.
concurrent access - if we're rebuilding (assume non-incremental for whatever reason) we can't query the data.

It still seems reasonable to argue that using the compiler's data is a better approach, but is definitely not as clear cut as you make out. It may well be that we choose the db path and in some time the incremental compilation stuff has settled and we have function body data and we can get rid of the db, that seems fine to me. But I don't think we can implement this today without the db.

And I haven't really touched the save-analysis stuff: are you seriously suggesting that we dump all the compiler data in bulk into some stringly-typed mush?

No I am not. I think you missed my reply to you above where I make a distinction between the save-analysis data dumps (data in bulk) and the save-analysis API which is more typed, allows access to data on a fine-grained basis, and is basically just a future-proof wrapper around the compiler's data.

@ArtemGr

Want to upgrade your data to a different format? It's a matter of several SQL queries and not of writing a whole program just to make that tiny upgrade possible,

Rust has a homegrown basically-relational-database metadata format (we can't use an SQL database there because rustc is way too chatty). Many parts of rust source fit there nicely. However, one of the most important things - types - is a very poor fit for a relational database because of the tree-structure.

SQLite virtual tables could potentially be used to provide a SQL interface to compiler metadata without needing to go through the overhead of updating physical tables: https://www.sqlite.org/vtab.html.
The question of if the metadata is reasonably representable in SQL would still stand, of course.

Hi Nick, Thanks for your reply, I'm glad the compiler api is not out of scope - I was under the impression that with this new cut-down proposal the compiler api wasn't deemed necessary because the RLS would provide the public interface.
I would however still like to argue that the compiler-api be the focus and priority

I'm skeptical about the big-database-of-code approach, and want the door left open for alternatives

I'd also like to see (and have a go at) projects to bring refactoring to rust

I think the api could be as straightforward as a focused save-analysis-style api (e.g. analysis-for-function / analysis-for-item, crate top-level-analysis (no function bodies)).

To elaborate on the compiler api:

racer currently uses syntex-syntax for parsing rust code snippets, and this works surprisingly well. The api changes frequently (because it tracks the compiler libsyntax api), but keeping up with it is pretty ok and allows racer to be a crates.io project that can be built with rust stable. I don't think we need an alternative stable api for parsing at this point.

The new analysis api could start by mapping expression spans to type and definition paths. This is along the same lines as the save-analysis output, but I'm advocating that there be an rustc api for generating small pieces of this data (e.g. at the Item (function) level as a start). In order to keep things simple the input to this analysis api could be the same arguments you would pass to the compiler.

I think (guess!) the combination of these two could be enough to feed the RLS and enable it to be a crates.io project rather than something that must be shipped with the compiler. It also would leave the door open for alternative approaches and other tools that are currently out of scope for RLS.

Hi @bruno-medeiros.
(Re: refactoring)

Hum, yes. Or the IDE developers have to modify RLS themselves to do that. I mean, RLS will be an open-source project, so it will be easy to add patches (or even fork/mod).

The problem is when you want to add something contentious to support some niche tooling, or try something experimental that might not pay off. Forking a project is a socially aggressive action, and it is a shame to have political fallout and hurt over some small technical point or direction. (we all saw it a couple of times on contentious rust PRs)
Also without a compiler-api RLS will probably need to be shipped with rustc making it hard to build an alternative tool.

You seem to not like this scenario, but what alternative could there be?

The alternative I'm advocating is that there be a compiler-analysis api to extract the analysis information. (the analysis information is not dissimilar to the JDT/CDT index-document you described. Rustc has something similar as a way to get information into DXR, although I think it might be partially broken at the moment).

So, I've been sort of half-following this thread, but I wanted to throw in some thoughts. Sorry for not having read every comment in detail, I'm sure I'm repeating things that have been said. What's worse, I'm going to ask some questions at the end that have probably been answered. Humor me. :)
In general, I think that the idea of having an oracle process that serves as a kind of database for Rust metadata makes a lot of sense. The current compiler data strutures are not designed to support IDEs or random queries, and I don't feel like I would want that as a constraint on how the compiler is structured internally. In particular, the compiler as it is today was really written to be a simple batch compiler a la gcc. It expects to compile a single crate and generate some output. We're working on changing that model, via incremental compilation and other things, but it's going to be a long road I think.
In the meantime, I think it makes sense to have a second layer that aggregates the output of multiple compilations (e.g., for multiple crates) and keeps a coherent view of things. This would keep that data indexed however it makes sense to have the data be indexed and be able to answer queries like "what was the type of the expression here" or "what traits are implemented for this type" and so forth. Obviously I'm glossing over a ton of details here. This layer is more-or-less what I thought the Oracle is.
To me, it doesn't matter so much if this layer is actually a process that communicates via IPC, or some shared libraries that everybody uses. I sort of prefer processes for various reasons, but whatever. If it's some shared libraries, we'll presumably need some file locking or other mechanisms to cope with the scenario where the compiler is trying to update some shared repository of information and the IDE is trying to read it.
Over time, I could see that this oracle layer and the compiler move closer together, and maybe the compiler eventually becomes a nifty library that can be integrated more closely into IDEs. In that case the "oracle" would just be various APIs, and not really much in the way of code.
Does this overarching thought make sense? @nrc, is this roughly what you were thinking with RFC, or am I totally off base? If it doesn't make sense, what are the major alternatives?

@nikomatsakis spot on.

@phildawes my intention is for the RLS to live outside the Rust repo and use the compiler as a library, like any other tool. Clearly it is going to be unstable for a long time (which is another good reason to put it in its own process instead of linking it).
My current model for a compiler API is that the tool uses libsyntax to parse source code, and then has the AST. You can then use AST nodes (currently by node id; spans have issues with macros) to query the compiler about types and so forth. This works pretty well, however, we might do better, for example by giving a synthetic 'AST' which also includes type information, etc. (the HAIR approach). We should have a discussion about how best to do this, but not here.
I have no idea what functions should be presented by the API, I've been adding stuff in a pretty ad hoc basic to the save-analysis API (note, the API, not the dumps, which are both working fine, btw). My plan for the API is more to just implement anything anyone wants (and is possible) until we have a good idea of the use cases, then make an RFC to stabilise some of it. If there are specific things you want, please let me know and/or file issues (or PRs) on the Rust repo.

@nrc, @nikomatsakis
Hi Niko, Hi Nick,

In general, I think that the idea of having an oracle process that serves as a kind of database for Rust metadata makes a lot of sense.

Personally I'm wary of the database-of-code metaphor. I think it hides the two hard problems of rust code completion, and instead encourages thinking about indexing and cache invalidation. As I see it, the two hard technical problems that need solving are:

complete-as-you-type requires rustc to get involved in the hot path.

type inference of the expression-being-completed can't be pre-cached. (database is no help here)
rustc must be capable of delivering the type (of the bit before the dot) in <100ms

complete-as-you-type requires processing incomplete/broken code

the crate isn't semantically complete or compileable  (again, database is no help here)

I don't think a code index is a requirement for fast completion. This is counter-intuitive, but racer specifically avoids doing it on grounds of simplicity and is fast, even for big multi-crate projects. (some discussion here).
I also don't think a database is required for find-references, but I have no evidence for this, only intuition

Hi @phildawes,
1 I agree, I probably wouldn't use the database at all for code completion info - that is a purely local query so can work straight off the compiler (on a slightly separate note, I see the compiler/RLS only returning info after the ., updating the actual code completion suggestions based on what is being typed is the code completion tool's job).

I don't think this is an issue. The compiler will process broken code (I've been working on more support for that this week). Code that has changed is invalidated from the DB, parts of code that we can type check are added, the rest is ignored. E.g., if the user types x.f; but there is only a foo field, the DB will have info about x but will ignore the f (we might even record that there is a field access, but the field name is unknown, if that is useful).

Find references is definitely the motivation for using a DB.

Personally I'm wary of the database-of-code metaphor. I think it
hides the two hard problems of rust code completion, and instead
encourages thinking about indexing and cache invalidation.

This makes a lot of sense. I certainly agree that adding an oracle
doesn't get us fast code completion for free -- that seems to require
not just incr. comp., but also a bit more work towards lazy
compilation and better error recovery (some of which is ongoing, as
@nrc notes). It does seem like an oracle would help for Find All
References, and I'm not sure what else.
Still, it seems to me that even in code completion, there is perhaps a
role for an oracle. In particular, you talk about wanting to determine
the type of the receiver of a method, but once you know that receiver,
you still want to figure out things like "what are the set of traits
that are implemented for that type?" (and note that those traits may
not be imported, so the compiler might not consider them
normally). This might be an ideal place for an oracle to come in.
Moreover, some completion scenarios don't necessarily require knowing
the full type, e.g., if I write some_fn(, then you can likely
resolve some_fn to a specific item (but in fact you really want to
be resolving some_fn all along to potential matches, even before
I've finished typing it).
Maybe there's another way to say what I'm saying. It seems clear that
"ideal IDE integration" is going to be a long time coming, and we're
going to be evolving how rustc works for some time. But in the short
to medium time frame, I expect you are going to want to do fast,
approximate queries across several crates, and it seems like we can
get that more easily through some spearate oracle (you will also
want to be able to ask rustc for stuff and get back a fast answer, of
course).
And if in the future it happens that rustc gets fast enough that we
don't need a database to answer those queries, we can just recompute
the data, that's fine, right? All the old code that expected
potentially stale answers should be fine when their answers are 100%
up to date?

https://crates.io/crates/syntex_syntax/

Speaking of, who maintains this project? Are the Rust developers involved?
I think changes and improvements to the Rust parser would a nice incremental step and starting point to improving the toolchain, with regards to how it's used by IDEs or IDE related tools (like Racer).
I've been working on one such tool, https://github.com/RustDT/Rainicorn (formerly called rust-parse-describe, I mentioned in a previous comment some weeks ago), also using syntex_syntax, and I can see some avenues for improvement already. For starters a panic-less parser would be nice, the way the parser currently works makes my code a bit more complicated than would otherwise be necessary.

Forking a project is a socially aggressive action, and it is a shame to have political fallout and hurt over some small technical point or direction.

I didn't mean forking as in a divergent, or organizational fork (duplication of efforts, vastly incompatible code baselines, no communication, development heading in different directions, etc.).
I meant fork as in the Git way: a clone/branch that you create, you make some modifications or additions, but it doesn't diverge that much from the upstream source, and you try to merge updates from the upstream source regularly. And occasionally you might submit patches to upstream as well.

@bruno-medeiros syntex is maintained by @erickt, who is a core member of the community (community and moderation teams, as well as just being generally involved), but not part of the compiler team. It is pretty much just a straight clone of libsyntax from the compiler, so improvements to the compiler's parser show up in syntex quite quickly.
Part of the plan with procedural macros/syntax extensions is to present a stable interface for them to work on, at which point syntex gets a lot less necessary (only useful for tools). In the long term I'd like to stabilise enough of libsyntax that tools don't need it either.
There is work going on to make the parser panic-less, it no longer panics on error. I've also been doing some work on error recovery, for example https://github.com/rust-lang/rust/pull/31065 adds some error correction for missing identifiers. Ideally it should be panic-free under normal use and recover from most errors within the next few months.

@nikomatsakis I did not intend the DB to be used for the code completion suggestions. It is useful for find all references, also queries like find all impls of a given trait, find all sub-traits, etc.

Still, it seems to me that even in code completion, there is perhaps a role for an oracle

Just to be clear, the Oracle, as in, "the resident process that is responsible for serving requests of various sorts to the IDE", it should handle code completion as well. Even if the data structures that are used to determine the results of code completion are entirely different from the data structures used for say, find-references, it makes no sense for this to be two different processes, or two different tools. This is because at the very minimum, these two operations can share cached AST data, not to mention that eventually (and sooner that later) we will want the Oracle to support functionality to manage/supply dirty editor buffers (ie, use a document that is being edited in memory in an IDE, but has not yet been persisted to disk). Even the functionality I'm coding in the Rainicorn tool should ideally also eventually be integrated into an oracle.
Of course, as an early prototype, it's okay for different operations to be handled by different tools, etc. but the end goal should be to integrate everything in the oracle, all-knowing that it is. :wink:  (gotta hand it to the Go guys, they choose the perfect name - apart from the trademark thing.. :stuck_out_tongue_closed_eyes: )
@nrc BTW, I was just looking at the Nim language, and to my surprise found out they have an "oracle" tool already: http://nim-lang.org/docs/idetools.html
And by the looks of it quite more advanced than the Go-oracle, it actually seems to achieve all those key aspects that were mentioned before:

Handles incorrect/incomplete code well
Is a resident process
Supports managing dirty buffers
Supports all sorts of IDE query operations in a single tool: resolve-definition ("Definitions"), code-completion ("Suggestions"), find references ("Symbol usages"), etc.. (Something like parse-analysis seems to be missing though)

Ideally it should be panic-free under normal use and recover from most errors within the next few months.

Sweet :+1:

:bell: This RFC is now entering its two-week long final comment period :bell:

Don't know if it is of any help but I will throw it out there.
QtCreator(mainly C++ IDE) has a plugin that uses Clang to offer C++ code completion.
Here is the code:
http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/clangbackendipc
http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/clangcodemodel
QtCreator also has an older custom C++ code model(that is being replaced by the clang one) that was a lot faster and seems like it is accepted in the community that the code model that uses the compiler will be considerably slower, but it offers more information and is more accurate.
I mention the speed because I saw @phildawes mentioning the hard requirements on the compiler to deliver the information in <100ms and I am not sure if we should expect it to be fast.

@lilianmoraru The reason the compiler needs to deliver the information so quickly is that the GUI is waiting on it.  The user is expecting the completion to appear as soon as the user presses . and that requires the compiler to respond fast.

I'm in favor of accepting this RFC. The approach seems worth exploring and it does not preclude improving the compilers amenability for being used as a library. On the contrary, I think the compiler's APIs will benefit from trying to build the RLS on top of it and it can only help if people on the compiler team are actual clients of their own APIs. The RFC leaves many open questions when it comes to specifics and we just need a prototype implementation and the experience that comes from building that in order to decide how to proceed further. Worst case, we'll learn a bunch of stuff on what doesn't work :)

1-based line numbers and 0-based column numbers please.

@erkinalp why?

@erkinalp why?

I was wondering the same, why is a mixed format being used (1-based in one, and 0-based for the other)

Emacs uses 0-based column numbers.

@erkinalp That's a perfect reason for not doing that :stuck_out_tongue_winking_eye: .

@nrc @bruno-medeiros: And it uses 1-based line-numbers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165#c21

afaik, there is no standard for editors to use 1-based line numbers. Having both 0-based seems like the least confusing thing to do, it's easy enough for editors to add one to each line number.

Compilers (including rustc) tend to use 1-based line and column numbers in their error messages. Following that standard seems like the least confusing thing to do. I certainly wouldn't expect 0-based line numbers.
But the concepts of "line" and "column" are ill-defined anyways.
Does a vertical tab (\v) count as a new line? What about form feed? What about all the other exotic Unicode newlines?
Does a tab count as N columns (where N is configurable; usually 4 or 8?), does it advance to the next multiple of N columns, or does it count as only 1 character?
Are full-width characters like 'ｘ' one or two columns wide?
Or does the editor count each Unicode codepoint as 1 column? Maybe a 'column' really is a UTF-8 byte offset within the line? Maybe it's measured in UTF-16 code units? Grapheme clusters?
It's difficult to find two editors that agree in their line/column counting for all possible input files.

I've integrated 5+ semantic engines in ycmd, and the only thing that makes sense is 1-based line and column numbers. Columns are byte offsets in UTF-8. Done.

it's easy enough for editors to add one to each line number.

But why should they? Line & column numbers coming from your oracle will be shown to the user and they expect 1-based numbering.

there is no standard for editors to use 1-based line numbers.

And yet they ~all do use 1-based numbers in the user interface. When you put your caret on the first line in the file, the editor doesn't say the line number is 0, it says it's 1. Same for columns.

Vertical tab means skip one line below and continue from same column offset.
CR, CR+LF, LF, LS and NEL are regular line feeds.
FF and PS count as two lines instead of one.

I've integrated 5+ semantic engines in ycmd, and the only thing that makes sense is 1-based line and column numbers. Columns are byte offsets in UTF-8. Done.

Why byte offsets and not Unicode character offsets? It's not like an error or position for a Rust symbol will ever start in the middle of a Unicode character.

there is no standard for editors to use 1-based line numbers.

And yet they ~all do use 1-based numbers in the user interface. When you put your caret on the first line in the file, the editor doesn't say the line number is 0, it says it's 1. Same for columns.

Because the internal API for lines and columns can be 0-based, despite the UI being 1-based. This is certainly the case for Eclipse, for IntelliJ, and probably for most IDEs/editors out there. It would not surprise me if Vim is the odd one out...  :laughing:

Keep it simple. Just use 0-based for lines and columns.

This RFC was discussed during the tools team triage today and the decision was to merge. This RFC is still at a somewhat high level and some minor details can continue to be ironed out in the implementation over time, but there seems to be widespread agreement about the body of the RFC here.
Thanks again for the discussion everybody!


Sabau/2088 faucet button

Closes #2088
Description:

Add Faucet button that make a GET request on our faucet with your address
not working on localhost

Thank you! 🚀

For contributor:

[ ] Added entries in CHANGELOG.md with issue # and GitHub username
[ ] Reviewed Files changed in the github PR explorer
[ ] Attach screenshots of the UI components on the PR description (if applicable)
[ ] Scope of work approved for big PRs

For reviewer:

[ ] Manually tested the changes on the UI

not working on localhost

then we should disable it on devMode imo

https://codecov.io/github/cosmos/voyager/commit/8061a45f0961208204b5e04c29efea94603bef2e

I tried to run three time but codeconv still refuses to put the link here, so I'll do it manually :)

@fedekunze that's controversial.
In theory it's a feature that should never exists in production, but available on staging to play around. In this moment we have a single flag to handle dev features but in this case it won't fit for all three cases: Dev/Staging/Production.
staging is being built with production setup, on pourpose to test the environment we will end up having in production, what I could do is having an the FAUCET environment variable set to empty and so disable that button for localhost, what do you think?

sounds good to me

Tomorrow morning first thing :+1:

We have the faucet prop in the config. How about only showing the faucet button if the prop is available?

Ok so locally we will have a button that ping caddy, but does not give money, on staging we'll have the real one

let's style this a little

share a screenshot!


Pokemon's HP???

Hi, where is the pokemon's HP?
It's server side?

PokemonData.stamina --> Current HP
PokemonData.stamina_max --> Max HP
There's also individual_stamina but that refers to the pokemon IVs

thanks so much


Following link in output window with split view, chooses active view instead of the view with the file selected.

When using split view with two views, and I click on Follow Link to go to the file and line number,
it opens the link in the last active view, instead of the other view which contains the file.

VS Code Version:  1.73.1
OS Version: Win10 x64

Steps to Reproduce:

Open two split views, one for the file containing the problem, and another different file.
Press Ctrl + click on any link in the output window to follow

Expected Behavior:
vscode should prioritize opening the link in the view with the same file, not the last active view.

You can configure this via workbench.editor.revealIfOpen setting.

We closed this issue because it is a question about using VS Code rather than an issue or feature request. Please search for help on StackOverflow, where the community has already answered thousands of similar questions. You may find their guide on asking a new question helpful if your question has not already been asked. See also our issue reporting guidelines.
Happy Coding!


Add register_database method

I would like to register a single database and not the entire glue catalog

The following functions are already available:
/// Register all tables in the given glue database
pub async fn register_tables(&mut self, database: &str) -> Result<Vec<Result<()>>> {

/// Register the table with the given database and table name
pub async fn register_table(&mut self, database: &str, table: &str) -> Result<()> {

@timvw Ah sry I should have looked at the signatures closer. Thanks!

You're welcome ;)


Remove invalid topics from targetTopics on INVALID_TOPIC_EXCEPTION

Fixes #665

Mostly FYI: It seems I'm able to hit a lock timeout for this new lock in our production environment. What is worrying here is the number of "waiting locks" in the log messages goes continuously up, starting from 2 to 1789 after several hours when I finally killed the process.