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 <[email protected]
> <javascript:>> wrote:
>
>> Hi!
>>
>> On Wed, 15 Jul 2020 02:32:24 -0700 (PDT)
>> Bernhard Ege <[email protected] <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 [email protected] <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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/emscripten-discuss/496ad5df-e521-41b4-bb50-a26ae13b19c6o%40googlegroups.com.
