Comments (12)
In order to have a productive discussion I think the first bit would be to gather/summarize what's provided/required in a wasm environment, as opposed to something like wasi or whatever distinctions that might exist, at which point we can figure out what sort of approach to take.
Generally speak reviews and some guidance aren't an issue. There are two things that become costly:
- If one or more of us need to spend time developing significant wasm/wasi expertise on an ad-hoc basis. It's a lot of context, unstructured fact finding, etc.
- Testing, not just writing them but good reliable harnesses, clear and organized description of specifications and requirements, and finally minimal examples
In some ways the above are the same thing, the first more theory and docs, while the second is more practice and code.
from nimskull.
After discussing further with @zerbina here in matrix, a revised approach:
- setup the following
--os:wasi
and--cc:empscripten
- testament can do this if we have a
wasi
target, needs to be added os:wasi
implies using thewasi
interface, not emscripten's own thing
- testament can do this if we have a
- make a trivial test(s) for emscripten work with testament, the bigger lift here will be CI
- incrementally add support for the
wasi
target
to various stdlib tests, until the category can be enabled- use
wasi
defines to appropriately enable disable various API - the
wasm
distinction can be added later
- use
from nimskull.
Sounds like a good plan. Thanks @saem . I'll start taking a look at testament sometime next week
from nimskull.
My understanding is that it should only be defined for Windows targets
The Tm
is a type imported from the posix <time.h>
header, but when building for non-Windows targets, the type is provided by the posix
module.
Currently, the times
module doesn't account for --os:any
, and thus you're seeing "undeclared identifier" errors when importing it. What should happen instead is that either:
- the procedures requiring some form of OS interaction or system headers are not defined at all when using
--os:any
- said procedures are stubs that report an error at run-time
If you want to use the times
module, I think at the moment your best bet is to build with --os:linux
, though there might still be the problem that emscripten doesn't implement all necessary functions from the type.h
header.
from nimskull.
Okay. For what I've currently got --os:linux
seems to work fine. I remember running into problems with that in the past, which is why I switched to --os:any
. But for my current project, it seems to be working fine so far. Thanks
from nimskull.
Similarly, things fail when the os
module is imported (when compiling for wasm).
Error:
/Users/adam/.asdf/installs/nimskull/0.1.0-dev.21252/lib/pure/os.nim(3514, 15) Error: undeclared identifier: 'paramCount'
candidates (edit distance, scope distance); see '--spellSuggest':
(5, 7): 'FTW_MOUNT' [var declared in /Users/adam/.asdf/installs/nimskull/0.1.0-dev.21252/lib/posix/posix_other_consts.nim(187, 5)]
(5, 7): 'count' [func declared in /Users/adam/.asdf/installs/nimskull/0.1.0-dev.21252/lib/pure/strutils.nim(1978, 6)]
(5, 7): 'count' [func declared in /Users/adam/.asdf/installs/nimskull/0.1.0-dev.21252/lib/pure/strutils.nim(1998, 6)]
(5, 7): 'count' [func declared in /Users/adam/.asdf/installs/nimskull/0.1.0-dev.21252/lib/pure/strutils.nim(1987, 6)]
(5, 7): 'parseInt' [func declared in /Users/adam/.asdf/installs/nimskull/0.1.0-dev.21252/lib/pure/strutils.nim(1064, 6)]
(5, 7): 'parseOctInt' [func declared in /Users/adam/.asdf/installs/nimskull/0.1.0-dev.21252/lib/pure/strutils.nim(1135, 6)]
(5, 7): 'parseUInt' [func declared in /Users/adam/.asdf/installs/nimskull/0.1.0-dev.21252/lib/pure/strutils.nim(1085, 6)]
(5, 7): 'pathconf' [proc declared in /Users/adam/.asdf/installs/nimskull/0.1.0-dev.21252/lib/posix/posix.nim(525, 6)] [rsemUndeclaredIdentifier]
lookups.nim(791, 35) compiler msg instantiated here [MsgOrigin]
sempass2.nim(1449, 16) compiler report submitted here [MsgOrigin]
No stack traceback available
To create a stacktrace, rerun compilation with './koch temp $1 <file>'
So I'm starting to wonder if we should have a larger discussion around wasm support because I think there's going to be a lot of stuff like this and I think we should get on the same page as to how much work it's going to be (both initial implementation and for maintenance). Of course, I'm willing to contribute but it would still require some efforts from the core team to guide me and review PRs, etc. So it may be worth estimating how much labor that would be.
from nimskull.
In order to have a productive discussion I think the first bit would be to gather/summarize what's provided/required in a wasm environment, as opposed to something like wasi or whatever distinctions that might exist, at which point we can figure out what sort of approach to take.
To be clear, I think wasi would be the best option. The specification appears to be evolving, but it's the best option for something like stability. And there's a browser shim available. Mostly what I'm thinking is just incrementally fixing modules so that nimskull can output code that emscripten can turn into wasi. The extent of my understanding right now is that there are some modules in the standard library that cause the compiler to error when attempting to compile nim->c with the flags that would make the c consumable by emscripten. And all I can speak to at the moment is the situation on macos. It may be better or worse on windows or linux. Providing functionality that emscripten already provides is a non-goal.
One potential mismatch is that emscripten seems to like when nimskull compiles with --os:any
or --os:linux
but macos may not. I'm not sure how much that's going to matter in general.
If one or more of us need to spend time developing significant wasm/wasi expertise on an ad-hoc basis. It's a lot of context, unstructured fact finding, etc.
At the moment, I seem to be the only one with much interest. So I wouldn't think anybody from the core team would need to push this effort or champion it to the point of adding features/extending coverage. I know the core team is prioritizing correctness and simplicity at the moment, and I don't won't to undermine that.
Testing, not just writing them but good reliable harnesses, clear and organized description of specifications and requirements, and finally minimal examples
I don't know much about what the nimskull testing approach looks like, yet. So from my perspective, this feels like the biggest effort and possible the area where I will need to most guidance to make sure that the test harness is something that fits into the general workflow.
What I don't want to do is start bringing in PRs and adding to the core team's maintenance burden. I don't have the bandwidth to go whole hog, but I'd like to incrementally fix modules as I need them and make sure there's a test harness in place to make it easy-ish to maintain. But I don't want this to become something the core team has to continually work around if I'm no longer able to contribute in 3 months or something.
from nimskull.
Reading over what you wrote, @theSherwood here are a few things I noticed, which are basically what I identified in my previous message, just restated:
- we need a map: there is wasm, wasi, and emscripten, that have partially overlapping impact across runtime, os, and codegen aspects
- we don't have a way to test these changes
I think both these things need to be sorted out in order for any significant changes to stdlib, and possibly codegen.
from nimskull.
FWIW, my current thinking is:
- create a
backend
calledempscripten
- initially just an alias for
c
; later maybeextccomp
makes it more turnkey backend
intestament
istarget
, setup anemscripten
target, to run it across various OSes
- initially just an alias for
- make a trivial test(s) for emscripten work with testament, the bigger lift here will be CI
- incrementally add support for the emscripten target to various stdlib tests, until the category can be enabled
- use
wasm
andwasi
defines to appropriately enable disable various API - assume
wasm
ifempscripten
, and user can definewasi
to open up greater APIs- if wasm isn't a strict subset of wasi, then we need to revise this appproach
- use
from nimskull.
Could you tell me more about what you mean about the differences between wasm
, wasi
, and emscripten
? I'm definitely a novice with this stuff, but my experience with wasm
over the course of the past few weeks is that wasm
is the binary format, wasi
is a standardization effort for wasm
module interfaces (such as wasi_snapshot_preview1
and the in-progress wasi_snapshot_preview2
), and emscripten
is a compiler for wasm
that historically has used its own module interface but now supports the wasi_snapshot_preview1
interface with an Emscripten compilation flag (PURE_WASI
).
My understanding is that the only wasm
interface standards are wasi
and Emscripten's. I don't know whether there are any particular features of a C program that would make Emscripten unable to compile to the wasi
standard, but there may be.
When you talk about a wasm
define in contrast to a wasi
define, do you mean throwing compile errors on anything that would require any wasi
imports? I would think that for an MVP, that could just be a user problem. To my mind, a separate wasm
target seems unnecessary. That should be handled with compiler options passed to Emscripten (or clang or wasi-sdk, etc.). Maybe I'm misunderstanding what you're saying. If I have any obvious gaps in my understanding, please point them out.
Another thing to consider is wasm32
vs wasm64
. I don't think 64-bit wasm
is really a thing yet, but I think it's in active development.
Edit: spelling and punctuation
from nimskull.
Could you tell me more about what you mean about the differences between
wasm
,wasi
, andemscripten
? I'm definitely a novice with this stuff, but my experience withwasm
over the course of the past few weeks is thatwasm
is the binary format,wasi
is a standardization effort forwasm
module interfaces (such aswasi_snapshot_preview1
and the in-progresswasi_snapshot_preview2
), andemscripten
is a compiler forwasm
that historically has used its own module interface but now supports thewasi_snapshot_preview1
interface with an Emscripten compilation flag (PURE_WASI
).
- wasm is a binary format, but it also implies some basics for browsers can load/work with wasm modules, IIRC
- wasi is an interface
- emscripten is both a compiler toolchain and defines at least two interfaces, it's own and wasi
When you talk about a
wasm
define in contrast to awasi
define, do you mean throwing compile errors on anything that would require anywasi
imports? I would think that for an MVP, that could just be a user problem. To my mind, a separatewasm
target seems unnecessary. That should be handled with compiler options passed to Emscripten (or clang or wasi-sdk, etc.). Maybe I'm misunderstanding what you're saying. If I have any obvious gaps in my understanding, please point them out.
The defines are for the stdlib, these are compile time errors, not compiler errors. Anyhow, if this stuff is ambiguous that raises core dev workload because now we need to know lots of intricacies in order to reason about whether a define is ambiguous/sloppy or whether it's sensible.
Another thing to consider is
wasm32
vswasm64
. I don't think 64-bitwasm
is really a thing yet, but I think it's in active development.
All the above is stuff you should research and summarize, so we have a map we can discuss, but if I, or another compiler dev, are doing that, then we're back to the significantly increased workload.
from nimskull.
So, to me it sounds like there is:
emscripten
, the compileremscripten
, the os/system interfacewasi
, the os/system interface
Notably, the compiler called emscripten
supports the system interfaces called emscripten
and wasi
?
from nimskull.
Related Issues (20)
- calls introduced by macros does not exhibit automatic typedesc conversion HOT 1
- Generic parameters `void` and `not void` clash HOT 3
- stdlib_*.nim.c files generated incompatible with my platform HOT 2
- unconditional pointer member access is generated in C for inheritance HOT 2
- NULL dereference when an empty seq is passed to openArray HOT 1
- stdlib: organize the standard library modules (`lib`) HOT 4
- objChecks:off not respected in pragma form HOT 2
- confusion of forvar type when supplied as typed macro argument HOT 2
- attempt to define call operator can crash the compiler HOT 1
- getType doesn't reveal complete generic arguments HOT 1
- CI failures due to inconsistent binaries buildt on M1 runners HOT 1
- incorrect control-flow when indirect call raises with `--panics:on` HOT 5
- UFCS issue iterator into macro HOT 4
- set[int8] cannot initialized with values HOT 4
- linking error when using `{.compile.}` pragma on .c files with same name but located on different paths HOT 1
- dot function call syntax inside a template can't lookup symbols of an imported module when the template is called from another module HOT 1
- ` .threadvar`s aren't destroyed on thread exit HOT 1
- value is implicitly moved even though it's used afterwards HOT 2
- procedure result is not cleaned up if the procedure raises HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nimskull.