search

danipen / TextMateSharp

A port of tm4e to bring TextMate grammars to dotnet ecosystem
MIT License
87 stars 15 forks source link

Trimming and NativeAOT compatible #42

Closed hez2010 closed 1 year ago

hez2010 commented 1 year ago

Making TextMateSharp trimming and NativeAOT compatible.

image

danipen commented 1 year ago

@hez2010 first of all thanks for the contribution.

Question: do we need to change something in the NuGet package generation?

danipen commented 1 year ago

I'm just wondering just for clarity when reading the code, if we can set the attribute DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.All) in each class itself (GrammarDefinition, Repository, Contributes, etc ... ) instead of defining the KeepType in the InitializeAvailableGrammars.

What do you think?

hez2010 commented 1 year ago

I'm just wondering just for clarity when reading the code, if we can set the attribute DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.All) in each class itself (GrammarDefinition, Repository, Contributes, etc ... ) instead of defining the KeepType in the InitializeAvailableGrammars.

What do you think?

Unfortunately, DynamicallyAccessedMembers doesn't work in that way.

danipen commented 1 year ago

Sorry I'm getting this in the demo application when testing you PR :-\ Not sure what's wrong. image

hez2010 commented 1 year ago

Sorry I'm getting this in the demo application when testing you PR :-\ Not sure what's wrong. image

It seems that you are running as a x86 process? I changed the default architecture to x64 on Windows, so on x86 the onigwrap.dll won't be copied to the artifact directory in the development environment.

danipen commented 1 year ago

Also, it seems that the tests in the CI pipeline are hanging due to the x68/x64 issue.

danipen commented 1 year ago

Now all passed green!

danipen commented 1 year ago

Well I'm running "Debug" and "Any CPU" environments, but it seems that VS wants x86 not sure why, let's keep this for compatibility since x86 is compatible with both but the other way around ;-)

danipen commented 1 year ago

Unfortunately, DynamicallyAccessedMembers doesn't work in that way.

No worries, we can leave it as it.

hez2010 commented 1 year ago

To test NativeAOT, you can change the demo project to net7.0 and use dotnet publish -c Release -r win-x64 /p:PublishAot=true. Note that by default the x86 onigwrap.dll will be copied to the publish directory and results in architecture mismatch, you need to copy the x64 onigwrap.dll to the publish directory manually. (This only happens in the development environment and won't affect the published nuget package).

But I'm thinking that maybe we can reimplement the searcher using built-in Regex instead of oniguruma in the future?

danipen commented 1 year ago

But I'm thinking that maybe we can reimplement the searcher using built-in Regex instead of oniguruma in the future?

It would be great to have 100% managed code and get rid of native deps!

I'm not sure how hard it would be. Currently, grammar definition files (which have been taken from Visual Studio code) talk Oniguruma dialect, so I don't know how hard would be to write a mechanism that converts those regexes to something understandable by C# built-in regex syntax.