> 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
It already does that, doesn't it? If not, can you share your patch that
fixes it?
On Wed, Jul 15, 2020 at 3:01 PM Bernhard Ege <gal...@gmail.com> wrote:
> 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>
>> wrote:
>>
>>> Hi!
>>>
>>> On Wed, 15 Jul 2020 02:32:24 -0700 (PDT)
>>> Bernhard Ege <gal...@gmail.com> 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.
>>> 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
> <https://groups.google.com/d/msgid/emscripten-discuss/496ad5df-e521-41b4-bb50-a26ae13b19c6o%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAEX4NpRkJgD-dqAE1JP-V9w3FLESMnLtFysvNe%3Dn8QCYKhnSYg%40mail.gmail.com.
