wasm woes
also I think the whole "oh look how cool on browser (on other platforms go fuck yourself) you can just include your C file and then do DllImport with the C files name" thing is just a lie
39 Replies
what have you hit this time?
well I think that really it just is part of a new thing they secretly added to the default AssemblyResolver
which it is this
i.e. what error or behaviour is it you're getting from this secret addition
no error or stuff
I'm talking about <NativeFileReference>
which supposedly has some magical wiring that allows a native file reference with file name "test.c" to be referenced by a DllImport by filename "test".
But really it's just part of the runtimes default assembly resolver
huh
so we can use a regular pinvoke override?
or no pinvoke override at all?
no pinvoke override at all I hope
THIS NEXT EXPERIMENT IS
VERY
VERY
INTERESTING
I'll fucking murder whoever thought of this workflow
NuGet packages can contain native dependencies for use on WebAssembly. These libraries and their native functionality can then be used from any Blazor WebAssembly app. The files for the native dependencies should be built for WebAssembly and packaged in the browser-wasm architecture-specific folder. WebAssembly-specific dependencies won’t get referenced automatically and need to be referenced manually as a NativeFileReference.So you're saying this is just a fancy feature that just doesn't work in libraries??? Currently downloading the emscripten SDK to manually compile
wtf?
most of that quote indicates we can put it in
runtimes/browser-wasm/native and it just work but that last bit says not automatically?forgot to put the last sentence in there
Package authors can choose to add the native references by including a .props file in the package with the references.
hrng
I think it's saying that <NativeFileReference> doesn't work across packages
but putting it in the folder manually works
well it's the case for iOS so whatever i guess, we can just add a .targets
the thing is, why doesn't <NativeFileReference> work also???
No I think we should just manually compile and ship the compiled binary
cause what <NativeFileReference> does is literally just compile, then reference the file
I don't know why it can't just put the compiled file in that folder on Pack, but that's how it is
Also to download the Emscripten SDK you literally need
- Git
- GitLFS
- NodeJS
- Python
- vcredist140
Just to then figure out the URL on some google server to download the actual binary
??? Why ???
just make a static link I can click
what the hell
hrmf this makes me uncomfortable
it's dangerous, but it looks like we could do
we'd probably want to add a msbuild target to tell us off when that breaks though
Copy Pasting that
I have no idea how you found that
but
eh
let me know if that works
cache : warning : Accessing the Emscripten cache at "C:\Program Files\dotnet\packs\Microsoft.NET.Runtime.Emscripten.2.0.23.Sdk.win-x64\6.0.0\tools\emscripten\cache" is taking a long time, another process should be writing to it. If there are none and you suspect this process has deadlocked, try deleting the lock file "C:\Program Files\dotnet\packs\Microsoft.NET.Runtime.Emscripten.2.0.23.Sdk.win-x64\6.0.0\tools\emscripten\cache\cache.lock" and try again. If this occurs deterministically, consider filing a bug. [C:\Silk.NET\src\Lab\Experiments\EmscriptenInteropGL\EmscriptenInteropGL.csproj]Narrator: There was no file It seems* this fucks the cache. Can we somehow copy the file somewhere else and then pack that?
what happens if you change it to
what changed 🤔
oh I see
doesn't seem to change anything
ugghhh
Wasn't there like a copy thing in MSBuild?
NOW I DON'T EVEN DO ANYTHING AT ALL
I REMOVED ALL THE CODE
AND NOW IT STILL HITS A CACHE PROBLEM
this advice was offered "as is" and without any warranty, express or implied
Apparently you somehow managed to trick my PC into bricking itself
that's not good
what
also this error message is brought to you by Python™️
I think it bricked the wasm-tools installatin
Python-in-NodeJS actually 👀
w h a t
ok I have proven that the new workload experience is very fragile
I deleted like one folder
and now it has bricked itself
with every run it recursively deletes one folder up lmao
here I deleted the .cache file - it deleted the above /cache folder
here I re-ran without modification and it deleted the whole eccm folder
I wonder if I rerun it 5 times, will it delete C:/ 
cache : warning : Accessing the Emscripten cache at "C:\Program Files\dotnet\packs\Microsoft.NET.Runtime.Emscripten.2.0.23.Sdk.win-x64\6.0.0\tools\emscripten\cache" is taking a long time, another process should be writing to it. If there are none and you suspect this process has deadlocked, try deleting the lock file "C:\Program Files\dotnet\packs\Microsoft.NET.Runtime.Emscripten.2.0.23.Sdk.win-x64\6.0.0\tools\emscripten\cache\cache.lock" and try again. If this occurs deterministically, consider filing a bug. [C:\Silk.NET\src\Lab\Experiments\EmscriptenInteropGL\EmscriptenInteropGL.csproj]Do I dare actually filing a bug 🤔
errrr
commit what you're building somewhere
then yeah i guess
well shit
@Perksey remember when we talked about mono asserts always being really helpful? I just encountered this https://github.com/mono/mono/blob/e100285775e333c2cc66dca29e990b616c352509/mono/metadata/custom-attrs.c#L596
GitHub
mono/custom-attrs.c at e100285775e333c2cc66dca29e990b616c352509 · m...
Mono open source ECMA CLI, C# and .NET implementation. - mono/custom-attrs.c at e100285775e333c2cc66dca29e990b616c352509 · mono/mono
what does that even do???
ah
in C literally anything can be put into an if
I know, and iirc it's > 0 then
yeah
so it just asserts that
out_obj is not null
how does this make any sense
like
and then later assert that this has not happened
how am I supposed to figure what this does
(╯°□°）╯︵ ┻━┻
(not actually expecting you to know, just remembered we talked about that)