I haven't made a standalone test yet as that would require quite some time. However, I hope with the given information, that we can see what is going on and if there is anything to do about it. Problem is I am using webassembly inside webworker (works jusy fine), but it can muddy the experience and getting a clean standalone test means creating a project from scratch. I am willing to do so if we can't make a clear case of the information below:
This is how I compile my C-project (just updated to latest emscripten, problem remains): & emcc -s WASM=1 -s ALLOW_MEMORY_GROWTH -s EXPORTED_FUNCTIONS="['_main','_malloc','_Iterate','_getImageData','_getBufferPtr']" -s EXTRA_EXPORTED_RUNTIME_METHODS='["cwrap", "getValue", "setValue"]' $(ls *.c| % {$_.FullName}) $(ls Racer/*.c | % {$_.FullName}) -I. -ferror-limit=0 -o myrekrig.js My source is current folder and the Racer subfolder. I just want a myrekrig.js file generated (along with the webassembly). I use the webassembly as a library, i.e. it doesn't exit, meaning I call repeatedly from javascript to wasm and have wasm repeatedly output text using printf (with and without "\n"). The printf are caught using the override in the Module setup: var Module = { print: (function() { return function(text) { console.log(text); console.log(ascii_to_hexa(text); }; } } ascii_to_hexa simply converts text to hex and is used to verify proper operation. I normally push the text via the message queue to the main page that appends the text to a textarea (which obeys newlines). One example of text received that in the printf is \n terminated: 536c65657079416e742020202020302020202030202020302e30202020202030202020202030202020202030202020302e302520202020202031202020302e3025202020302e3025202020302e3025 Clearly no newline present (last 2 digits, 25, is a %-sign). In the generated myrekrig.js, I find this section: printChar:function(stream, curr) { var buffer = SYSCALLS.buffers[stream]; assert(buffer); if (curr === 0 || curr === 10) { (stream === 1 ? out : err)(UTF8ArrayToString(buffer, 0)); buffer.length = 0; } else { buffer.push(curr); } If I remove "|| curr === 10", then the output is correct, newline or no newline. However, this also means the output is buffered for a long time (or until a buffer is filler or some other event happens), delaying the text for a long time, which is also unwanted. The hack will also be overwritten on the next compilation. I am considering simply using sprintf and push the string from wasm to js domain manually, but I hope I don't have to. It seems the printf output is made more responsive by sending data to the JS-print method every time \n (10) or 0 (string termination) is found, which is great (if it preserves all characters, including \n, which it doesn't seem to). Could we make it operate using a smaller buffer or maybe using a forced flush (or a timeout, not sure that is possible)? Does the above information make sense? Thanks, Bernhard On Wednesday, 15 July 2020 23:16:56 UTC+2, Alon Zakai wrote: > > One possible noticeable difference with a normal target is that we print > using console.log() and other JS APIs, which can't print partial lines - > they always add a newline. So we buffer, and call those APIs only when we > reach a newline. As a result, you won't see partial lines printed until a > newline is reached. > > If that's not the issue here, that might be an unknown bug somehow, a > testcase would help. > > On Wed, Jul 15, 2020 at 4:40 AM Shlomi Fish <shl...@shlomifish.org > <javascript:>> wrote: > >> Hi! >> >> On Wed, 15 Jul 2020 02:32:24 -0700 (PDT) >> Bernhard Ege <gal...@gmail.com <javascript:>> wrote: >> >> > When I compile my C-code using emscripten and in C use printf and in >> > javascript receive the string via 'print', the newlines are removed. >> > >> > This makes it quite difficult to discern the difference between these >> two >> > printf's: >> > >> > printf("foo"); >> > printf("foo\n"); >> > >> > Visually, there is an important difference, though. >> > >> > Is there some flag or some way print can be told to return the newlines? >> > >> >> seems to work here: >> >> ``` >> [shlomif@localhost shlomif-c-snippets]$ cat newline-printf.c >> /* >> * License is the MIT/Expat license - http://opensource.org/licenses/MIT >> . >> * ( https://en.wikipedia.org/wiki/MIT_License ). >> */ >> #include <stdio.h> >> >> int main(void) >> { >> printf ("Hello World!"); >> printf ("(emcc)\n"); >> >> return 0; >> } >> [shlomif@localhost shlomif-c-snippets]$ emcc newline-printf.c >> [shlomif@localhost shlomif-c-snippets]$ ls -lrt *.js >> -rw-r--r--. 1 shlomif shlomif 110446 Jul 15 14:36 a.out.js >> [shlomif@localhost shlomif-c-snippets]$ node a.out.js >> Hello World!(emcc) >> [shlomif@localhost shlomif-c-snippets]$ >> ``` >> >> Can you share a self-contained sample? See: >> https://github.com/shlomif/how-to-share-code-online (read the whole >> thing). >> >> Thanks in advance. >> >> -- >> >> Shlomi Fish https://www.shlomifish.org/ >> https://github.com/sindresorhus/awesome - curated list of lists >> >> At this point, I'd like to take a moment to speak to you about the Adobe >> PSD >> format. PSD is not a good format. PSD is not even a bad format. Calling it >> such would be an insult to other bad formats, such as PCX or JPEG. No, >> PSD is >> an abysmal format. >> — https://github.com/gco/xee/blob/master/XeePhotoshopLoader.m >> >> Please reply to list if it's a mailing list post - https://shlom.in/reply >> . >> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to emscripten-discuss+unsubscr...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/20200715144004.58141cb4%40telaviv1.shlomifish.org >> . >> > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/496ad5df-e521-41b4-bb50-a26ae13b19c6o%40googlegroups.com.