@tannergooding@dotnet.social avatar

tannergooding

@tannergooding@dotnet.social

Dev on .NET Libraries team working on Hardware Intrinsics and Numerics. They/Them.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

bradwilson, (edited ) to dotnet
@bradwilson@mastodon.social avatar

This is super duper extra important.

C# Nullable Reference Types are a compile-time thing, not a runtime thing. "string?" and "string" are both just "string" at runtime.

This means:

  • Always guard against your users passing null even for types that shouldn't allow it, because it's not a runtime guarantee.

  • You can't create overloads that differ only on nullability (i.e., Method(string) vs. Method(string?)) because they're the same type at runtime.

tannergooding,
@tannergooding@dotnet.social avatar

@khalidabuhakmeh @bradwilson That was the !! feature that got pulled.

You don't want it to be implicit because it would kill perf for all the internal APIs where the validation was already done or the unsafe APIs that explicitly want the first null deref to throw.

tannergooding,
@tannergooding@dotnet.social avatar

@agocke @khalidabuhakmeh @bradwilson I expect C# LDM wouldn't go for a global switch. That immediately starts looking like a language dialect which always gets strong opposition.

Maybe a preprocessor directive would be ok, but it's a one liner per argument (ArgumentNullException.ThrowIfNull(x)) to make it very clear/apparent and overall improves the readability and debuggability of your code.

tannergooding,
@tannergooding@dotnet.social avatar

@agocke @khalidabuhakmeh @bradwilson Wasn't one of the core design principles of NRTs that it didn't change codegen (in part to avoid creating a dialect)? So a new switch on nullable would violate that, no?

tannergooding, to random
@tannergooding@dotnet.social avatar

If you've not seen it, C# 10/.NET 6 introduced support for interpolated string handlers which allows string interpolation to be used efficiently with things like loggers: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/interpolated-string-handler

It's definitely worth checking out and seeing if your logger of choice has updated to support it yet.

tannergooding,
@tannergooding@dotnet.social avatar

@bitbonk Not sure, that's a bit higher up in the stack than I normally work.

@davidfowl or @damianedwards might be better people to ask.

At a glance, it looks like "no", which might be due to it being oriented around an interface and pre-dating the feature.

I do know that Debug.Assert, Debug.WriteIf, Debug.WriteLineIf, span.TryWrite, stringBuilder.Append, stringBuilder.AppendLine, Utf8.TryWrite, and a number of string and other APIs all use the feature.

eniko, to random
@eniko@peoplemaking.games avatar

Encountered a shader compiler that complained that it can't do a multiply between float and const int and like... come on! How bad does your compiler have to be that it can't handle that?

Anyway. After adding ".0" to every integer in Kitsune Tails' shaders the problem is now solved, but jesus christ

tannergooding,
@tannergooding@dotnet.social avatar

@eniko I’d understand if it was some int that wasn’t exactly representable (like greater than 2^24) but 2 not working is just ridiculous 😂

Was this glsl or hlsl or something else?

tannergooding, to random
@tannergooding@dotnet.social avatar

We approved some new vector helpers in API review today: https://github.com/dotnet/runtime/issues/98055

These will be Any(vector, value) and AnyWhereAllBitsSet(vector). Plus similar pairs for Count, IndexOf, and LastIndexOf.

These allow for performing common checks efficiently when working with variable length vectors (like Vector<T>) or when working on platforms without ExtractMostSignificantBits like Arm64 (this API functionally matched the movmsk instruction available on x86/x64)

https://github.com/dotnet/runtime/issues/98055

khalidabuhakmeh, to godot
@khalidabuhakmeh@mastodon.social avatar

Spent some time changing a to a class. They look identical, but it seems the same hardcoded values work differently in GDScript vs. C#.

Does anyone want to have a look? I can't see what I did differently.

C# code

tannergooding,
@tannergooding@dotnet.social avatar

@khalidabuhakmeh worth noting that if the Godot Vector2 has any kind of SIMD support, directly mutating Y tends to be a bad idea anyways.

SIMD backed vectors should be viewed as primitives and you want to do something like Velocity += Vector2.UnitY * (JumpHigh * speed * (float)delta); instead

There are potentially better ways too, but it depends on knowing more about the code

tannergooding,
@tannergooding@dotnet.social avatar

@khalidabuhakmeh Whether its better or worse just depends on if Godot has it as a naive user-defined struct or if it's SIMD accelerated like System.Numerics.Vector2 is on .NET Framework and modern .NET [Core]

This sharplab link shows some basic differences, where you can see a SIMD accelerated version (M1/2/3) has to use insertps to mutate Y directly since both X and Y are in 1 register, while the naive version (N1/2/3) has 2 separate registers (and more operations):
https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEBDAzgWwB8ABAJgEYBYAKGIAYACY8gOgDkBXfGKASzFwBuGsQDMTUgwDCDAN40GipuIBqMMBmiSAsuQAUajVoYA3GABsIYXhgCeaBgDNL2DAwBWXAA4AJXgHMACwdnCFcGXC8YGAATBxiIDmBzGAYYiwxsAEo5BSV8s0trOxYATQYAagBeD28/IIYAKgio2KaGPVDXLPTzTOFqfPziAHZTCysbWwH8gF88xQXlBkNNKB1SA3U1yULJuxCXN098XwDgpyOW6Li0xOTU3syc+UGhxVHxoqnKle2tFgAVQAdjZys09Cczg1mpEbu1OkcehlsjMlPM3otMctVsZtKItkZ1l99vZLmFjnVzocKddYvF7ik0iiXkthmM9sVbL9gTAAO5/ImbOgOKH1QLtOFtCFdDDIvqopYY/JLMQMNjYXhmXHEtj6DVamA63YTLk08Ji6nk8JS24JJJMp7ZXLYgqmqZlSo1S0wukxBGy+X9NlKT6cqZoxTKpSq8QG7X/XWbeNGxMm74Ha2U07i81uW0Mh2PFku94fDnuuy/FPGoGgjDgjo+iWw1r+mVIp1ZSMMaNY4ZxzUJoXqgk1tMks1Z2o5q2yv2Fh7MhWs12hisZ7kVBi8gXjoV6EUz6Etv0BzssnsYjEicS4DBQDgadVD1NCmivAfTgAaDlKPdjJhyCQF9DWNBgQTBBgqgAPh3flQOHHZDwcchuyWQD92Q+cEDzBhbCyJZPzLb9oIYBAe3ycoammJUMOxNVmBArDjAgKIoFcaBKj0FjiXMQJcAcXjJCgATCOxYj3k+XdELfZD+NwFhSO3UTFN/BgFM9FSBLKdDsT7BhAKY2TwLYnhOKgJoeNfcCFLw1TxPySShmkhDhL0TTSOaVSHE0xsHKvGhZiAA==

tannergooding,
@tannergooding@dotnet.social avatar

@khalidabuhakmeh So no acceleration for it I take it then?

That's unfortunate, they could do acceleration even if it wraps the Godot primitives. But, probably not too meaningful at the end of the day.

tannergooding, to random
@tannergooding@dotnet.social avatar

I took third (out of four) for Adult High Beginner Group A at Pacific Coast Adult Sectionals

Next year I hope to have passed the tests so I can compete at the qualifying levels

tannergooding,
@tannergooding@dotnet.social avatar

I got the video of my performance back: https://1drv.ms/v/s!AqkbTWoBajq8htoEP7Eur2Eu9YNzRg?e=4kPjma

I definitely got nervous and had problems (looking down too much, forgetting to smile, not landing my jumps with my leg properly extended, etc), but I'm still glad I went and overall with how I did for my first competition and level I went at ⛸️

khalidabuhakmeh, to random
@khalidabuhakmeh@mastodon.social avatar

I think the updated tags are a bit harsh. I made some tweaks.

  • Drop the “.NET” and “.NET Framework” (We get it, it's all .NET)
  • Less distracting colors
  • Smaller size

Tweaked version

tannergooding,
@tannergooding@dotnet.social avatar

@khalidabuhakmeh Some of this may notably come from an accessibility PoV.

Important information that people are frequently seeking needs to be more visible and at the right contrast ratios.

The "new version" here fails the minimum contrast ratio requirements (both AA and AAA) for normal text and fails WCAG AAA requirements for large text.

The grey on white just below it passes WCAG AA requirements everywhere and passes AAA reqs for large text (14pt+ bold or 18pt+ non-bold).

tannergooding,
@tannergooding@dotnet.social avatar

@khalidabuhakmeh That's definitely fair, and I think that's the more important feedback to give.

Specifically that the package title is "less visible" than the "supported frameworks tags", while being more important information

tannergooding, to random
@tannergooding@dotnet.social avatar

.NET 9 Preview 1 is out: https://github.com/dotnet/core/discussions/9167

eniko, to random
@eniko@peoplemaking.games avatar

Omg. List<T>.AddRange allocates. Of course it fucking does, it only takes IEnumerable<T>, but I never stopped to think about it. Oh my god I hate this so much 😬

tannergooding,
@tannergooding@dotnet.social avatar

@eniko It should only allocate enough to grow the backing array to fit the items, and it should do that efficiently (one growth and a direct copy) if the enumerable is actually an ICollection&lt;T&gt; (at least on .NET Core: https://source.dot.net/#System.Private.CoreLib/src/libraries/System.Private.CoreLib/src/System/Collections/Generic/List.cs,e569d850a66a1771)

tannergooding,
@tannergooding@dotnet.social avatar

@eniko I don't think I quite understand...

List<T>.AddRange is part of the core library and has been built in since .NET Framework 2.0

So if the calling assembly was .NET Core, it should resolve to [System.Collections]System.Collections.Generic.List<T>.AddRange

khalidabuhakmeh, to dotnet
@khalidabuhakmeh@mastodon.social avatar

It's strange seeing folks suggest you implement a finalizer on objects. My understanding has always been that finalizers are a carry over from C++ and shouldn't be implemented when working with managed objects.

Am I missing something?

tannergooding,
@tannergooding@dotnet.social avatar

@khalidabuhakmeh Most types should never implement a finalizer.

However, if you're implementing IDisposable (such as because you directly wrap native resources), then you should also implement a finalizer to ensure that nothing leaks: https://learn.microsoft.com/en-us/dotnet/api/system.idisposable?view=net-7.0#implementing-idisposable

In the ideal world, the finalizer is never called because users are utilizing patterns like using (var x = new SomeDisposable()) and Dispose is then calling GC.SuppressFinalization(this)

1/

tannergooding, to random
@tannergooding@dotnet.social avatar

https://devblogs.microsoft.com/dotnet/dotnet-8-hardware-intrinsics/

eniko, to random
@eniko@peoplemaking.games avatar

making a dictionary type isn't that hard but making one that implements all the random stuff you need to be compliant with the relevant C# interfaces is a lot of work 😒

tannergooding,
@tannergooding@dotnet.social avatar

@eniko which bits are annoying to implement right now?

I wonder if there’s anything we can provide to help simplify some of it…

tannergooding, to random
@tannergooding@dotnet.social avatar

I took and passed my "Adult Pre Bronze Moves in the Field" test for US Figure Skating today!

eniko, to random
@eniko@peoplemaking.games avatar

okay so im confused. if you cant use reflection in NativeAOT, does that mean you can't use custom attributes like, at all? cause that's a pretty big limitation if so? O_o

tannergooding,
@tannergooding@dotnet.social avatar

@eniko NAOT supports a lot of reflection just fine. It's only certain types of reflection which may depend on dynamic codegen that doesn't work.

You may need to use additional attributes or annotations to ensure the relevant dynamically accessed methods aren't trimmed, but otherwise even things like Type.GetType("MyType").GetMethod("MyMethod").Invoke(...) works just fine

https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/docs/reflection-in-aot-mode.md has some details on how this all works and briefly the experimental reflection free AOT mode

tannergooding,
@tannergooding@dotnet.social avatar

@eniko There's definitely places where the trimmer isn't as smart as we'd like it and where you have to do extra to make it happy.

If you could share a snippet of the warnings you're getting, I can try to help point you towards the right way to handle them

Otherwise https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/incompatibilities has some of the known trimming limitations

and https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=net7%2Cwindows#limitations-of-native-aot-deployment has some info on the NAOT limitations

tannergooding,
@tannergooding@dotnet.social avatar

@eniko I think in part because you frequently don't own the types being reflected or only want a subset of members.

If you have particular areas that you'd like to see improved I'd highly recommend logging a small issue over your experience

We try to catch a lot of the obvious cases, but open generics are hard since the potential input domain is "any type" in the worst case. If you can constrain it to use interfaces and new features like static virtuals, that can help a ton and avoid the issue

tannergooding, to random
@tannergooding@dotnet.social avatar

I have determined that if C# had a mascot, I would want it to be a hedgehog.

They are small/cute.
They can roll into a ball (which some might describe as a dot)
They are "sharp" and are known for their ability to stay safe

They could be best friends with Ferris

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • anitta
  • thenastyranch
  • rosin
  • GTA5RPClips
  • osvaldo12
  • love
  • Youngstown
  • slotface
  • khanakhh
  • everett
  • kavyap
  • mdbf
  • DreamBathrooms
  • ngwrru68w68
  • megavids
  • magazineikmin
  • InstantRegret
  • normalnudes
  • tacticalgear
  • cubers
  • ethstaker
  • modclub
  • cisconetworking
  • Durango
  • provamag3
  • tester
  • Leos
  • JUstTest
  • All magazines
    •