If we wanted to avoid making users use fixed, we could have a constructor that would allow them to a

If we wanted to avoid making users use fixed, we could have a constructor that would allow them to allocate unmanaged memory, and then dispose it. behind the scenes.

khitiara•10/20/23, 2:06 AM

what span did before ref fields was an intrinsic that behaved like a ref field that got substituted out by the runtime

CCurin If we wanted to avoid making users use fixed, we could have a constructor that w...

Maxine•10/20/23, 2:06 AM

bad idea

CurinOP•10/20/23, 2:07 AM

yeah not my favorite idea, but it would avoid the need for fixed statements.

Perksey•10/20/23, 2:08 AM

you can technically achieve what Span.DangerousCreate did before it was removed by calculating the ref offset from its owning object, creating a GCHandle to the object that owns the ref, and then reapplying that offset

CurinOP•10/20/23, 2:09 AM

okay so the major problem is how do we consume span<T>, array[][], string[], etc. preferably implicitly.

khitiara•10/20/23, 2:09 AM

span used to use a compiler-substituted primitive struct called ByReference<T>ByReference<T> which was internal

Perksey•10/20/23, 2:09 AM

yeah I know that

khitiara•10/20/23, 2:09 AM

just providing context in case others dont

khitiara•10/20/23, 2:10 AM

i dont believe that can be replicated nowadays though

Perksey•10/20/23, 2:10 AM

it can, it’s called a ref field

Perksey•10/20/23, 2:10 AM

but before fast span was a thing you couldn’t create a heap ref without providing the owning object

khitiara•10/20/23, 2:10 AM

well yeah

PPerksey but before fast span was a thing you couldn’t create a heap ref without providin...

Perksey•10/20/23, 2:10 AM

this was what DangerousCreate did, and was removed as soon as humanly possible

khitiara•10/20/23, 2:10 AM

my point was more you cant use the sneaky way to circumvent this ref field to ref struct issue

Perksey•10/20/23, 2:11 AM

yeah sure

PPerksey this was what DangerousCreate did, and was removed as soon as humanly possible

Maxine•10/20/23, 2:12 AM

what if

Perksey•10/20/23, 2:12 AM

I also don’t know any way that doesn’t involve fixed, refs, or sentinels to track a heap pointer

Maxine•10/20/23, 2:13 AM

weak table?

Perksey•10/20/23, 2:13 AM

that would be the sentinel

Perksey•10/20/23, 2:13 AM

and you’d have to have a secondary object to act as the sentinel

Perksey•10/20/23, 2:14 AM

because if you create a single CWT (aka DependentHandle) with a sentinel freeing the GCHandle upon collection and you use the GCHandle target as the sentinel itself, it’ll never get collected

Perksey•10/20/23, 2:14 AM

you can’t have an object manage its own lifetime in a managed to native transition without fixed or refs

Perksey•10/20/23, 2:15 AM

technically we could make it so the user can opt into manually managing their heap memory, but that sucks

Maxine•10/20/23, 2:15 AM

call into internal coreclr methods

Maxine•10/20/23, 2:16 AM

there must be one of them

CurinOP•10/20/23, 2:22 AM

Here's a question, currently the SilkX code uses Unsafe.AsPointer to cast a ref variable to a related pointer. What happens if the GC moves the value between us getting the pointer and using it in native code?
Does Unsafe.AsPointer fix the object so the GC can't move it?

Perksey•10/20/23, 2:22 AM

nope, that’s why I wanted to make sure that you made the operators that use Unsafe.AsPointer explicit instead of implicit

Perksey•10/20/23, 2:22 AM

because it’s basically only safe for stack refs

Perksey•10/20/23, 2:23 AM

or struct this refs

Perksey•10/20/23, 2:23 AM

although even that can be unsafe

Perksey•10/20/23, 2:23 AM

basically only use it if you know it ain’t moving

CurinOP•10/20/23, 2:26 AM

so in practice is this usable to take my vertex array or descriptor table data and pass it into commandlists? Data most likely put on the heap.

Perksey•10/20/23, 2:28 AM

the current implementation is yeah as you won’t have Unsafe.AsPointer in the loop

Perksey•10/20/23, 2:29 AM

the ref will remain tracked until it’s fixed by the generated code

CurinOP•10/20/23, 2:35 AM

Is the plan for users to use these objects in place of an array or object all the time or just to be silently converted to when you pass in an object into a Silk function?

Perksey•10/20/23, 2:35 AM

it’s only intended to be an interchange type

Perksey•10/20/23, 2:35 AM

so when you need to pass something to native or read something from native

Perksey•10/20/23, 2:35 AM

basically what’s in Playground

tannergooding•10/20/23, 2:43 PM

did I get pinged?
discord said there was one here, but nothing in the inbox or that I can find

Ttannergooding did I get pinged? discord said there was one here, but nothing in the inbox or t...

Perksey•10/20/23, 2:44 PM

yeah, I pinged you a while ago wrt porting silk.net.maths to generic maths. One sec

Perksey•10/20/23, 2:45 PM

conversation starts from here team-talk

Volte•10/20/23, 2:45 PM

perksey#0000

@266043404398493696 i don't suppose over the years you've come up with some smart ideas for Vector2<T>? we're looking into moving to generic maths, and obviously there's loads of cases that Silk.NET supports today that would be silly in a generic maths world (e.g. you can do SinSin on a bytebyte).

we can go with use case parity with 2.X, even if it doesn't make sense, but i figured given you'll have to be tackling this problem eventually maybe you have some loose thoughts knocking about in that noggin.

Original Message

Click here

Quoted by perksey#0000

tannergooding•10/20/23, 2:48 PM

I see, I see. I wonder why it only showed me the ping today

tannergooding•10/20/23, 2:48 PM

Vector2<T>Vector2<T> supporting only floating-point vs supporting integers in general is something I've struggled with finding the right balance for/around

tannergooding•10/20/23, 2:50 PM

When you consider some of the most core APIs that a "euclidean vector" needs to provide
then, in general, there are a lot of concepts that simply don't work with integer types
for example, you really can't even do something as basic as normalize the vector or get a valid length
but you can still do some things that somewhat make sense, such as get a rounded distance

tannergooding•10/20/23, 2:52 PM

now, you could argue that at the most basic level, it is fine for Sin(x)Sin(x) for an integer to work much as x / yx / y does
which is to say, it does the computation and rounds it to the nearest representable result using some specified rounding direction

but, this gets problematic when needing to consider the algorithm generically and version it over time
because while you could give an approximation of Sin(x)Sin(x) for floating-point, as you can say that PiPi can be loosely represented
you can't do the same with integers and things trend towards 0 or 1 for all answers

tannergooding•10/20/23, 2:53 PM

----------------
so, the closest thing I've determined to "correct" here is that Vector2<T>Vector2<T> should only be where T : IFloatingPoint<T>where T : IFloatingPoint<T> (or IFloatingPointIeee754<T>IFloatingPointIeee754<T>)
and that the concepts where you want to support integers as well are more limited and should be a separate type Point2<T>Point2<T>

tannergooding•10/20/23, 2:56 PM

that way you can still do basic arithmetic operations and concepts like distance between two pointsdistance between two points where-as that can be made to makes sense
(distance can be represented, not as straight line distance, but rather as a pair representing the lengths of the two sides, rather than hypotenuse; for example)

tannergooding•10/20/23, 2:57 PM

without having to pessimize the type in general for the core concepts that do need to be supported when you have floating-point types

Perksey•10/20/23, 2:58 PM

Huh yeah makes sense, I hadn’t considered making a basic type

If we wanted to avoid making users use fixed, we could have a constructor that would allow them to a

Similar Threads