tabnine-vscode doesn't work

OS version: Win 10
Editor: vscode
Editor version: 1.44.2
Programming language: js
TabNine extension version: 3.4.2
Engine version (could be located within Tabnine Hub): Tabnine Hub also goes down

When type simple code, like log or something, no any suggestion shows, even the default.
I guess something goes wrong with Tabnine, and prevents all suggestions from prompting out.
 Hope they will fix it soon. I have tabnine pro and it's not even showing that i have pro version.

@MangoPomelo I think you should add bug label to this issue.

@matystu @MangoPomelo - can you please share the vscode console log (Help -> Toggle Developer Tools)?

@dimacodota here is screenshot, I hope this is enought, there is nothing more with tabnine.

@dimacodota

@boaz-codota I've tried to find ExtensionContext.globalStoragePath mentioned in the link with Ctrl + Shift + P and Developer Tool, but nothing found.

@MangoPomelo - see the following table to locate the globalStoragePath:
vscode globalStorage locations

OS
Path

Windows
%APPDATA%\Code\User\globalStorage

macOS
$HOME/Library/Application Support/Code/User/globalStorage

Linux
$HOME/.config/Code/User/globalStorage

I guess it has something to do with my proxy. However, nothing changed after resetting my http_proxy and https_proxy in the configuration.

@dimacodota It's not working for me either.

@matystu, can you please run the binary as @boaz-codota  suggested and share the output?

@dimacodota I'm using WSL remote, so I now tried to run it in windows without WSL, it worked. But when I loaded tabnine hub (worked from windows), there was everything setup like basic setup (no pro). Then when I turned on deep completition cloud and configure it back, it now worked in WSL without any error. Not even single log in developer console. Weird


Clarification on PSA key algorithm restriction for agreement/derivation

Description

Type: Inconsistency/Question

Question
PSA says (on the topic of key usage restrictions) :
In addition to the usage bitmask, a policy specifies which algorithm is permitted with the key. This specification only defines policies that restrict keys to a single algorithm, which is consistent with both common practice and security good practice.
This is implemented super strict inside of psa_crypto.c, and I'm wondering why it does so. Consider a key used for ECDH, stored non-exportable persistent. The algorithm declared when generating the key needs to match strictly with the algorithm the key is used for.

If one wants to use the key with psa_raw_key_agreement(), it needs to be defined with PSA_ALG_ECDH, and the core doesn't care what happens with the shared secret.
If one wants to use the key with psa_key_derivation_key_agreement(), then it needs to be defined with PSA_ALG_KEY_AGREEMENT(PSA_ALG_ECDH, PSA_ALG_xKDF(PSA_ALG_xHASH)), all depending on which KDF is used. The key is thus bound to one specific combination of both agreement, derivation and hash primitive algorithms.

The question then begs: a key declared for use with PSA_ALG_ECDH, shouldn't that be allowed to be presented to psa_key_derivation_key_agreement for use of a combined agreement/derivation operation? Since it is under-specified in a way?
I assume this'll be a larger problem when porting the TLS portion on top of PSA Crypto with long-term keys. If you have an ECDH key, and didn't specify a restriction on derivation algorithm, it really shouldn't matter for the usage restriction which derivation algorithm you're using after the agreement step.

Yes, this makes sense. The PSA interface aims at keeping key policies simple (in particular we rejected policy expressions such as A or B), but there is a precedent for a policy “wildcard” (signature key that allows any hash), and it makes sense similarly to have PSA_ALG_ECDH be a “wildcard” that allows either raw key agreement or key agreement combined with any KDF.
This is a backward compatible extension so it can be added to the PSA Crypto specification in a 1.x version.

On the same note: calling psa_key_derivation_key_agreement doesn't currently 'unlock the permission to output to a key object'. I assume that's a bug?

Sorry, I don't understand 'unlock the permission to output to a key object'.

operation->can_output_key is not being set if a key is added to the derivation operation through psa_key_derivation_key_agreement, meaning psa_key_derivation_output_key will refuse to output a key if the derivation is key agreement based.

Ah ok. That would indeed be a bug. Please file it separately.


Bug: instanceof Element check fails

Describe the bug
The instanceof Element checks in the library fails (e.g. at src/utils/stringifyNode.ts or src/utils/isElement.ts).
Because of that e.g. the wrapper.find method always returns an empty array and wrapper.html adds xmlns="http://www.w3.org/1999/xhtml" to every root element.
Related information:

@vue/test-utils version: 2.0.0-rc.20
Vue version: 3.2.32
node version: v17.7.2
npm (or yarn) version: 8.5.5

Additional context

I noticed this by using the debugger.
At the bottom you can also see that even element instanceof element.ownerDocument.defaultView.Element returns false.
I run the tests with this command: vitest --environment jsdom
I think the only thing special is that I have the canvas package installed.

I'm sorry I don't understand what your issue is. Can you provide us a minimal reproduction on GitHub with a simple component and a failing test?

I have created a repository where i can reproduce this: https://github.com/Derviloper/instanceof-fails
If you npm run test:unit you can see that the WelcomeItem.test.ts can't find a h3 element when it should.
And if you also look at the WelcomeItem.test.ts.snap you can see that the root element has this xmlns="http://www.w3.org/1999/xhtml" which shouldn't be there.
This is because the instanceof Element checks returns false when it should be true.
If you look at my screenshot on the top you can see the the element currently is a HTMLDetailsElement which normally extends Element but here it returns false.

I was able to run the tests successfully by removing the vitest threads: false option from vite.config.ts. Also I had no issues when using jest with --runInBand option. IMO this might be an issue with vitest

Ho good catch @freakzlike ! Yes there are several issues with threads: false with vitest (some I opened myself on the vitest repo). They are working on it, but in the meantime, I recommend to stick to the threaded mode
Let's close then, and we'll revisit if this is still an issue when the vitest team fox these issues on their side

I set threads: false because of the node-canvas package I installed (see https://github.com/vitest-dev/vitest/issues/740). So yes I'll guess I have to with the issues than.


[fix] Resolves #31

As explained in #31, using the length of a string to get a character's index don't work with character of other languages such as Spanish. Because this scenario only works with 1-byte characters (English alphabet).
So, OteraEngine returns an error when rendering templates that have 2-byte characters, such é or ñ (In spanish).
Solution:
Replace the while loop + lenght() with a for loop and eachindex() function to get the index of each character correctly :+1:

I checked your change. I think for loop works in most cases, but it fails to parse when a template using + token with the control block.
So, I will decide whether merge this PR or not(and implement by myself) after I try some test.

This is fixed by myself. So close this PR.
Thank you for your cooperation.


Additional Schedule Finder refactors

Related to: Schedules | Add inputs to schedule finder modal
These are a couple of other refactors that were left on Cristen's schedule-finder-inputs branch (see also #404). Since they are mostly independent of the feature work, and in the interest of keeping changes small and easily reviewed, I've separated them out.

I added another small refactor onto this, based on some weirdness I discovered on the way to implementing the schedule finder inputs.


dnx ef migrations add System.TypeLoadException: Could not load type 'Microsoft.Data.Entity.Internal.CoreStrings'

Beta 7 works fine. Beta 8 running:
dnx ef migrations add InitialMigration
Generates:
System.TypeLoadException: Could not load type 'Microsoft.Data.Entity.Internal.CoreStrings' from assembly 'EntityFramework.Core, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null'.
at Microsoft.Data.Entity.Utilities.Check.NotEmpty(String value, String parameterName)
I've cleaned solution, restored, deleted migrations folder, tried many other things. Nothing does anything. Same error all the time.
Calling dnx ef migrations shows the help listing commands like add, remove, script etc...
Running dnx ef migrations remove also throws exactly the same error.

I fixed that if I explicitly specified beta8 for references.
{
"tags": [ "" ],
"projectUrl": "",
"licenseUrl": "",
"dependencies": {
"EntityFramework.SqlServer": "7.0.0-beta8",
"EntityFramework.Commands": "7.0.0-beta8",
"EntityFramework.Core": "7.0.0-beta8",
"Microsoft.AspNet.Identity": "3.0.0-beta8",
"Microsoft.Framework.Configuration.Json": "1.0.0-beta8",
},
"frameworks": {
"dnx451": {
"dependencies": {
"EntityFramework7.Npgsql": "3.1.0-beta8"
}
},
"dnxcore50": {
"dependencies": {
"Microsoft.CSharp": "4.0.1-beta-",
"System.Collections": "4.0.11-",
"System.Linq": "4.0.1-",
"System.Runtime": "4.0.21-",
"System.Threading": "4.0.11-*"
}
}
},
"commands": {
"ef":  "EntityFramework.Commands"
}
}
However then once it generates the migrations file it no longer builds as the migrations file fails as the generated file is invalid, it contains the following for table ID values for example:
migrationBuilder.CreateTable(
name: "AspNetUsers",
columns: table => new
{
Id = table.Column<IEquatable`1>(nullable: false),
},
And fails to build as '1 doesnt exist.
It also states CS0115 '.Down(MigrationBuilder)': no suitable method found to override	...\Migrations\20151026080531_InitialMigration.cs	137... and that function is:
    protected override void Down(MigrationBuilder migrationBuilder)
    {
        migrationBuilder.DropTable("AspNetRoleClaims");
        migrationBuilder.DropTable("AspNetUserClaims");
        migrationBuilder.DropTable("AspNetUserLogins");
        migrationBuilder.DropTable("AspNetUserRoles");
        migrationBuilder.DropTable("AspNetRoles");
        migrationBuilder.DropTable("AspNetUsers");
    }

Also if I manually change the generated migration files, removing where it added IEquatable'1 ID values to the actual real model values (string), the migration files then work fine and everything works.
So it seems the issue is with the EF Commands library not creating the migrations files correctly for ID properties. That is all it affects.

It sounds like there is an issue with miss-matched versions of assemblies. Are you able to reproduce this with a project created from scratch (if so can you post the detailed steps so that we can reproduce and debug it). If not, is it possible to give us access to the project that is failing?

Just tried it again and its working. Must of been some kind of temporary or cached references as I havent added, removed or edit any references only wrote more code and rebuild a few times.

@angelsix thanks for confirming


Textbox Grid Question Type

Hi,
How can i support a grid type with Text box.
Please see the below attached screen of what i am expecting
Plz help me.

Hi,
I have just added support for configuring grid cell input type, available types:

radio
checkbox
text
number
date
time