whoops might be my setup, I didn't install C++ workload
whoops might be my setup, I didn't install C++ workload
Pon a scale of 1 to 10 how easy was it to figure out that that’s the issue
PI’ve been trying to improve that
Cpretty easy once it was going. There was a message I just had to read through the log.
CShort of stopping there and going in big red text, I don't think it could be much more clear
Cso if 1 is easy and 10 is hard, probably like a 2 or 3
Pawesome, glad about that
Pgiven that this is intended to be consumable by people who aren’t Silk.NET maintainers I’m trying to make it as usable as possible!
CIt may be worth stopping at that step then. Just so it is crystal clear and they don't get half baked output
CSo far, looks like the pointer types are up and running. Some changes had to be made to fix the fact that some names changed, but otherwise I've got it building. I'll run the tests and then hopefully have a PR up in a little bit
Lsaving this list so i know what to update
Lim not sure what this means, do we git-version some of our native packages?
Psee
common.props, there's logic in there that gets the date of the most recent commit in the submodules and uses that for the versionLoh
Pbut i have a feeling that hasn't been working as we'd intended for a while given that we don't clone the submodules in CI haha
Li think if we
git submodule init all of them but not update them i think that would work?Pshould do, just make sure we don't init recursively
Potherwise we'll run out of space
Ltesting rn, making a simple clone of silk.net
L
P
Lnope git init alone doesnt work
Lthe subfolders arent considered "repos" yet
Pcan we do a non-recursive update then?
Li'll see how big a non-recursive shallow clone is
Kcan you not just get the submodule version from the gitmodules file?
Ki thought that is kept up to date
Pthe SHA is checked into the repo in the form of the submodule pointer, but we still need the history to get the date
Pwhich involves cloning
Koh right yeah
Kright yeah its stored elsewhere and also not the date
Ljeez even a shallow clone takes a million years
Kif there was some way to get a bare clone of the submodules thatd be nice
Klike just the git stuff no checkout
Lthats what i thought git submodule init did
Lbut nope
Lshallow clone not recursive of Silk.NET is 4.3GiB
Lthat should be fine
Li would add this to
build.yml right?Pyup
CPR up for the pointer generation, took a little longer than expected. I forgot about adding the extension methods, but it is all in now.
C@Perksey 2 questions regarding your comments:
For the single dimensional generics being generated with IL-Weaving. Initially I assumed IL weaving would be necessary, but if we store ref T instead of ref byte it should be easy enough. Is that how you would prefer it?
As for the public InteriorRef constuctor, there isn't any need for it to be public. Would you prefer it to be private?
For the single dimensional generics being generated with IL-Weaving. Initially I assumed IL weaving would be necessary, but if we store ref T instead of ref byte it should be easy enough. Is that how you would prefer it?
As for the public InteriorRef constuctor, there isn't any need for it to be public. Would you prefer it to be private?
CAlso several MutTests break when we remove string conversion for mut types, not a big deal but those tests are no longer valid.
Pyeah storing the ref in its "true form" is best where possible
Ptechnically even when storing it as a byte you could just use Unsafe.As, but it's far easier to just use the true ref
Cgreat, I've already started work on changing that and fixing up some more fallout I found after the other changes.
Psorry i haven't been working on silk much, been feeling crappy today
Ltis all good, take all the time you need
Live been busy with a bad case of "writing unit tests" all day
DNot unit tests?! 