-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add basic wasm32-unknown-unknown support #148
Conversation
While implementing this feature, I found the lost of level after formatted, then I have to re parse the level message, Otherwise I have to log all message with console.log. Any better way to get the level message so that we could seperate different levels' message? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this @huangjj27!
It would be great to at least build for the wasm target in CI, if not also run all the tests (looks like there's a wasm-bindgen-test
crate we could use for that).
@KodrAus Thanks for your sugesstion! I have committed some codes for that. Another point is that,how could we parse the logging levels on web as we do on native runtime? I think it is better to make use of the logging levels from the web console |
|
Hey @huangjj27, it's a little hard to tell what the current state of this is. Is there more work to be done? |
Hi @jplatte , I think there is:
|
Do you plan to work on this?
I'd expect CI to run properly after a rebase. |
Update from upstream
c4c503e
to
bc6d841
Compare
@jplatte Hi! I rebased and it passed all checks now. I'm glad that someone will help with this issue. I think it needs much refactoring to the current formatter? |
52ccb01
to
7c3ef4a
Compare
We could refactor things to pass the |
I think this will pending until refactoring for this is done, for there are information of level and some other meta data we can make use of. |
Update from upstream
@huangjj27 Support for structured logging is something we could add at any time, but is absolutely desirable. I think all we need to do here is add some CI support for WebAssembly. I've got an example from another project, and there's also the If you'd like a hand getting this up and running let me know! |
Ok, I will take this at the weekend, or as soon as I’ get spare time |
update from upstream before rebasing branch
7c3ef4a
to
b36f7ce
Compare
CI is added but it seems not to test. Will fix it as soon |
Aha! here is the document. |
475a4cb
to
d05bff1
Compare
a9cfe94
to
d82284f
Compare
encounter with this bug. To work around this, I think we have to disable the default feature when we compile to the |
@KodrAus I get it worked, but there is some issue: when I tried to compile with the
although the
So I have to comment out the "deny warning" parts. |
only enable when termcolor feature is disabled
61af00e
to
8313446
Compare
Hi @KodrAus, basic implement and basic CI are committed. Any Advice? |
I've just removed |
I'm curious why it's desirable to use env_logger on wasm32-unknown-unknown. The motivation here seems to be for use on the Web, but the Web embedding doesn't have environment variables, and its stdin and stderr don't print anything. The |
Thanks for advice! I'll abandon this PR. |
Simple version of web logger support
Update 2020-01-10 23:31:15
This PR is to add basic, ugly but work support for the
wasm32-unknown-unknown
target, with default features disable. Tests can be used as:Issues remain
fmt
) and writercompile
modified example
default.rs
:compile the example and generate bindgen:
add
index.html
to./wasm
directory:open the
index.html
from a browser(I used Firefox 71). It's expected to see logs on the console(F12)