Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 22:29
    MihaZupan commented #73907
  • 22:28
    MihaZupan commented #73907
  • 22:19
    MihaZupan synchronize #73907
  • 22:08
    aromaa commented #67193
  • 22:08
    hoyosjs commented #73885
  • 22:07
    hoyosjs commented #73885
  • 21:49
    msftbot[bot] unlabeled #73804
  • 21:49

    BruceForstall on main

    Fix arm64 scalar intrinsic use … (compare)

  • 21:49
    BruceForstall closed #73804
  • 21:49
    BruceForstall closed #73876
  • 21:48
    hoyosjs edited #73908
  • 21:35
    teo-tsirpanis closed #40074
  • 21:28
    vcsjones edited #73864
  • 21:24
    vcsjones commented #73864
  • 21:23
    msftbot[bot] commented #73908
  • 21:23
    msftbot[bot] labeled #73908
  • 21:23
    dotnet-issue-labeler[bot] labeled #73908
  • 21:23
    ayakael opened #73908
  • 20:57
    Seabizkit commented #73900
  • 20:55
    Seabizkit commented #73900
Andrew Matthews
@aabs
thanks, yeah, that's what I did. I was just hoping initially to be able (in the platform independent way) to install ilasm/ildasm as global dotnet tools that I could reference via process invocation.
Stephen A. Imhoff
@Clockwork-Muse
... what do you mean by "platform independent" here?
Andrew Matthews
@aabs
My initial first pass of the code compilation has nasty stuff like this in it:
                    var ilasmPath = @"C:\Windows\Microsoft.NET\Framework\v4.0.30319\ilasm.exe";
                    var (result, stdOutputs, stdErrors) = GeneralHelpers.RunProcess(ilasmPath, ilFilename,
                        "/DEBUG",
                        "/EXE",
                        "/NOLOGO",
                        $"/OUTPUT={assemblyFilename}");
re platform independence - I want this little compiler to work on Windows as well as Linux, so I'd like not to have hard coded package references like these knocking around:
    <PackageReference Include="runtime.linux-x64.Microsoft.NETCore.ILAsm" Version="6.0.0"  GeneratePathProperty="true" />
Stephen A. Imhoff
@Clockwork-Muse
You can make package references conditional based on the platform, but I'd check and see if one of the base ilasm/ildasm packages will do that for you.
Andrew Matthews
@aabs
nice. I think I can see how I could make that work
Stephen A. Imhoff
@Clockwork-Muse
That aside, that ilasmPath isn't even safe on windows, because it's pinned to a specific framework version (and you're trying to use a net core version, anyways).
Ideally, you're grabbing the path from the nuget package, which there's probably an easy way to get it, but I'm tired and don't know it.
Andrew Matthews
@aabs
I know - I was struggling with getting decent IL generated. So I just needed something working quickly, so I could at least get some errors out of ilasm. It was never intended to survive for long. (honest)
thanks for your help!
Alexander Köplinger
@akoeplinger
@aabs if you have .il files you can also use the Microsoft.NET.Sdk.IL, just add this into a .ilproj next to an .il file and rundotnet build:
<Project Sdk="Microsoft.NET.Sdk.IL/6.0.0">
  <PropertyGroup>
    <OutputType>Library</OutputType>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>
</Project>
AraHaan
@AraHaan

So, anyone online and able to mark this as ready for review (I think I been waiting since the new year vacation for it to be marked for review). I have some Impl that has been waiting for it to be reviewed (and hopefully approved) for .NET 7: dotnet/runtime#62113

prereq (something similar to this): https://github.com/dotnet/runtime/issues/42820#issuecomment-980830626
Funny story on the prereq: The only diff between Deflate, Zlib, and GZip is the Window Bits so I made them into classes as structs cannot inherit from other structs which was the original design of that part.

If approved into .NET 7, .NET will gain an ZlibEncoder and ZlibDecoder that can handle Deflate, Zlib, and GZip all in one due to the options types that I created in the prereq which gives the ability to use those compression algorithms without streams (span based).
Andrew Matthews
@aabs
@akoeplinger - this is a compiler - it is generating the IL as a by-product of the compilation process. The IL isn't known ahead of time.
I have a partially working solution, but it still has some issues I'm struggling with...
msedi
@msedi
Does someone know how I can pin a Span<T>?
Antony Male
@canton7
@msedi .GetPinnableReference()? Although the docs say it's not for user code
From the docs here: https://docs.microsoft.com/en-us/dotnet/api/system.span-1.getpinnablereference?view=net-6.0 it looks like you can just use a span in a fixed statement
msedi
@msedi
@canton7 : Thats exatcly my problem. I was trying to use GC.Alloc, but the reference is boxed in the call and therefore pins the boxed reference but not the reference itself.
Antony Male
@canton7
I'm not sure what GCHandle will do if you give it something on the stack...
msedi
@msedi
Thats a good point. I assume it will pin but if it gets out of scope there will be garbage. Fortunately I do not have data from the stack (everything is unamanaged memory or regular heap memory). But still I cannot get a pointer to it.
Antony Male
@canton7
Add in a sprinkling of Unsafe.AsPointer?
msedi
@msedi
RIght. FOr unmanaged memory this would be OK, but for managed heap memory this will get a problem sooner or later if I cannot pin it, right?
Antony Male
@canton7
There's MemoryMarshal.GetReference as well
I mean with GCHandle.FromIntPtr. But I guess that's racey -- the GC could kick in between you getting the pointer, and pinning it
I'm not actually sure if GCHandle supports interior pointers either
msedi
@msedi
Yes. Thats what I also assume but it seems there is currently no way to pin a Span<T> other than using fixed. But I need a longer lifetime of the pin and therefore I cannot use it.
Antony Male
@canton7
Ah, GCHandle.FromIntPtr wouldn't work, of course
dotnet/corefxlab#1287 looks relevant
Ah, that's used by Memory<T>.Pin
msedi
@msedi
Thats exactly the point ;-) It all turns around Span<T> and Memory<T> they seem to be mutually exclusive and Memory<T> is not able to hold an unmanaged memory (here: MemoryMappedFiles).
Antony Male
@canton7
This is all making me think that GCHandle doesn't support interior pointers, but I'd have to re-read my copy of Pro .NET Memory Management to be more sure
Wait, how exactly are you using a span there?
msedi
@msedi
Allright. Thanks for the discussion, I also have to dig deeper.
AraHaan
@AraHaan
Sad there is no gitter for dotnet/arcade.
Steve
@hez2010
Hello, is there a nuint version of Span<T>?
If not, how can I use Span to safely access a NativeMemory which contains more than 2^31 elements?
Antony Male
@canton7

Is the advice in https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient?view=net-6.0 about re-using instances of HttpClient still correct?

HttpClient is intended to be instantiated once and re-used throughout the life of an application. Instantiating an HttpClient class for every request will exhaust the number of sockets available under heavy loads. This will result in SocketException errors. Below is an example using HttpClient correctly.

I thought SocketsHttpHandler fixed all of that back in .NET Core 2.1?

you can use the DefaultHttpClientFactory from Microsoft.Extensions.Http to deal with the issue
Antony Male
@canton7

Tough this class implements IDisposable, declaring and instantiating it within a using statement is not preferred because when the HttpClient object gets disposed of, the underlying socket is not immediately released, which can lead to a socket exhaustion problem. For more information about this issue, see the blog post You're using HttpClient wrong and it's destabilizing your software.

That blog post is from 2016, and my understanding was that SocketsHttpHandler solves that problem. That was the entire point of it.

Alexander Köplinger
@akoeplinger
as far as I know the DNS issue still exists even with SocketsHttpHandler unless you manually configure PooledConnectionLifetime: https://www.meziantou.net/avoid-dns-issues-with-httpclient-in-dotnet.htm
Antony Male
@canton7
Right, but the DNS issue arises if you keep the HttpClient alive for too long, not if you new one up each time
Alexander Köplinger
@akoeplinger
ah I see what you mean. no idea then, might be worth filing an issue to get a clarification from the networking owners
Antony Male
@canton7
Yeah, hence my question here
masonwheeler
@masonwheeler

I've got a program that uses the Boo interpreter under the hood. It breaks on updating to .NET 6, because of a breaking change that causes strong name signing to throw an exception. The following code will always throw, even if the public key value is null:

            var assemblyName = new AssemblyName();
            assemblyName.Name = GetAssemblySimpleName(outputFile);
            assemblyName.Version = GetAssemblyVersion();
            if (Parameters.DelaySign)
                assemblyName.SetPublicKey(GetAssemblyKeyPair(outputFile).PublicKey);
            else
                assemblyName.KeyPair = GetAssemblyKeyPair(outputFile);
            return assemblyName;

Is there any way to fix this behavior without 1) modifying the compiler's code or 2) reverting back to .NET 5 and losing some important .NET 6 benefits I'd prefer to keep?

CyrusNajmabadi
@CyrusNajmabadi
@masonwheeler likely best to file issue at dotnet/runtime
masonwheeler
@masonwheeler
wizardars
@wizardars
How to get HeapCount used by ServerGC in .NET 6 ? Looks like it impossible, right ?