robust FS_createDataFile error handling?
In one of my projects I am populating the FS via files that the user drag on the page. I am using FS_createPath and then FS_createDataFile to create respective FS entries from the user supplied files. Unfortunately it seems that older and more recent Emscripten versions behave differently in this context - which sucks. Specifically I am performing the FS_createDataFile in a try/catch to handle the scenario where a user repeatedly drops the same file, i.e. that file then already exists. The older Emscripten version reacted to this scenario with err.message == 'File exists' (it seems that the also supplied err.code unfortunartely was unusable garbage - which sucks). Though the check for a specific "message" - rather than some stable error code - seemed rather braindead, it at least allowed to properly handle the specific error scanario. Unfornately it seems that the more recent Emscripten versions here have been made even worse: Now the err.message in this partucular scenario is "FS error" - which is a totally useless information and no longer allows to properly handle the specific error scenario. I wonder what the "officially suggested" approach for this scanario might actually be - since the available exception handling obvisouly isn't fit for the task. (Since I don't want to support different implementations for use with different Emscripten versions, I am looking for a robost approach that actually works regardless of the used Emscripten version.) -- 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/44ab15a9-90cd-4520-8fda-e6e7592ce214n%40googlegroups.com.
Re: howto disable stack trace for console output of fprintf
PS: the above globally changes the console's behavior and has the side
effect that log calls made from unrelated JavaScript code will also no
longer show the "source file". The clean way is probably to define the
Module's "print" function by passing a respective object into the Module
constuction function:
let in = {
print: function(t) {
// suppress annoying "source file" info
setTimeout(console.log.bind(console, t)); // "lose" the original context
}
};
juergen...@gmail.com schrieb am Freitag, 11. August 2023 um 14:56:26 UTC+2:
> Thanks for the tip. The behavior actually seems to depend on
> std::cerr/stderr.. when stdout is used instead then the stacktrace is gone
> (i.e. works also in C).
>
> To then also get rid of the annoying "source file" info console.log has to
> be replaced before the EMSCRIPTEN Module is instanciated, i.e. putting
> something like the below into the respective file does the trick (and it
> doesn't seem to have any negative effects on the scenarios where you
> actually want to log an error with stacktrace):
>
> let origLog = console.log;
> console.log = function(t) {
> setTimeout(origLog.bind(console, t)); // "lose" the original context
> };
>
> problem solved :-)
> mike.l...@googlemail.com schrieb am Freitag, 11. August 2023 um 14:15:43
> UTC+2:
>
>>
>> I sometimes just want to print trace output from the C/C++ side and I do
>> not care about the stack trace info in that scenario. I already do know
>> exactly where the messages come from and the stack unnecessarily bloats the
>> output by 1-2 orders of magnitude - sometimes slowing the browser to a
>> crawl due to the amount of data, and unnecessarily complicating the actual
>> use of the log data..
>>
>> How can EMSCRIPTEN's default impl of always including the stack info be
>> overridden to just print my plain fprint messages?
>>
>>
>> Instead of printf use std::cout << "your message" << yourObject <<
>> std::endl, if you are in C++. That only prints that message, nothing else
>> (and does good formatting). I use that currently for debugging.
>>
>> Mike
>> --
>> www.soft-gems.net
>>
>>
--
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/15ef311a-1b69-4f03-b35c-4d9404b3b28cn%40googlegroups.com.
Re: howto disable stack trace for console output of fprintf
Thanks for the tip. The behavior actually seems to depend on
std::cerr/stderr.. when stdout is used instead then the stacktrace is gone
(i.e. works also in C).
To then also get rid of the annoying "source file" info console.log has to
be replaced before the EMSCRIPTEN Module is instanciated, i.e. putting
something like the below into the respective file does the trick (and it
doesn't seem to have any negative effects on the scenarios where you
actually want to log an error with stacktrace):
let origLog = console.log;
console.log = function(t) {
setTimeout(origLog.bind(console, t)); // "lose" the original context
};
problem solved :-)
mike.l...@googlemail.com schrieb am Freitag, 11. August 2023 um 14:15:43
UTC+2:
>
> I sometimes just want to print trace output from the C/C++ side and I do
> not care about the stack trace info in that scenario. I already do know
> exactly where the messages come from and the stack unnecessarily bloats the
> output by 1-2 orders of magnitude - sometimes slowing the browser to a
> crawl due to the amount of data, and unnecessarily complicating the actual
> use of the log data..
>
> How can EMSCRIPTEN's default impl of always including the stack info be
> overridden to just print my plain fprint messages?
>
>
> Instead of printf use std::cout << "your message" << yourObject <<
> std::endl, if you are in C++. That only prints that message, nothing else
> (and does good formatting). I use that currently for debugging.
>
> Mike
> --
> www.soft-gems.net
>
>
--
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/9e4207cf-9802-4ce1-a5ed-1fd9696eada4n%40googlegroups.com.
Re: howto disable stack trace for console output of fprintf
aha!... using "stdout" instead of "stderr" always gets rid of the stack
trace! (I can live with that..) now the only remaining question is how to
get EMSCRIPTEN to use my replaced (see above) console.log rather than the
original one...
juergen...@gmail.com schrieb am Freitag, 11. August 2023 um 14:29:49 UTC+2:
> thanks for the tip. that is indeed an improvement for the C++ case -
> unfortunately it doesn't help for my current C project. Also I'd like to
> completely get rid of the useless "source file" info (since it is a
> nuisance having to edit that out first when using the logs), something that
> I'd handle in the plain JavaScript context using something like this:
>
> function disableLogSourceDisplay() {
> var origLog = console.log;
>
> console.log = function (s1) {
> setTimeout(origLog.bind(console, s1)); // "lose" the original context
> };
> }
> disableLogSourceDisplay();
>
>
>
--
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/d4cc097c-ccdd-4001-a715-e7c174b2c4b0n%40googlegroups.com.
Re: howto disable stack trace for console output of fprintf
thanks for the tip. that is indeed an improvement for the C++ case -
unfortunately it doesn't help for my current C project. Also I'd like to
completely get rid of the useless "source file" info (since it is a
nuisance having to edit that out first when using the logs), something that
I'd handle in the plain JavaScript context using something like this:
function disableLogSourceDisplay() {
var origLog = console.log;
console.log = function (s1) {
setTimeout(origLog.bind(console, s1)); // "lose" the original context
};
}
disableLogSourceDisplay();
--
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/889ef6e1-e8de-470f-841c-e769a0edfdf2n%40googlegroups.com.
howto disable stack trace for console output of fprintf
I sometimes just want to print trace output from the C/C++ side and I do not care about the stack trace info in that scenario. I already do know exactly where the messages come from and the stack unnecessarily bloats the output by 1-2 orders of magnitude - sometimes slowing the browser to a crawl due to the amount of data, and unnecessarily complicating the actual use of the log data.. How can EMSCRIPTEN's default impl of always including the stack info be overridden to just print my plain fprint messages? -- 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/ed3741cd-7c2a-4c02-ae52-c92fae8a7c82n%40googlegroups.com.
what is wrong with recent Emscripten?
I just made the mistake to update my old Emscripten 1.38.13 version (which had worked fine) to a recent 3.1.x version (due to one 3rd party project that had specifically required a respective >3.1.x version). Interestingly it seems that the executables of my existing WASM projects now suddenly are massively (30% ) larger when compiled with the new Emscripten version, e.g. 3MB instead of 2.3MB.. WTF? (same build script - only change was to add "-r" option when building ".bc" libs). Worse it seems that code that worked fine before now suddenly doesn't anymore. (e.h. some kind of emulator that generates chiptune music and the respective audio calculations now suddenly produce garbage - whereas the same code compiled with the 1.38.13 version did not have this problem.) Worst of all I had kept the backup folder of my old emscripten installation - as an insurance against the above scenario. Only to find that the new install apparently messed up stuff outside of the installation folder and my old version no longer wants to start.. :-( Help! How can I rollback to my old version to escape this nightmare? -- 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/4e59121e-0359-42c5-83d9-b1b6967b6e30n%40googlegroups.com.
usual suspects?
On a recent project (see http://www.wothke.ch/webixs/ ) I have the effect that the Emscripten built version of a music player in *some* songs produces "incorrect clicks" that are completely absent if the same original C code is built as a win32 or 32-bit Linux executable (e.g. see song "world of noise" in the dropdown list). I think I already fixed all the unaligned memory access issues that the program originally had had (at least there are no respective warnings anymore - I am building with -s ASSERTIONS=*1* -s SAFE_HEAP=*1*). for the most part the code seems to work fine.. and I would suspect that it might be some kind of special case clamping/overflow issue.. The audio-generation logic to a large part is based on (unsigned )int64 based logic (simulating the functionality originally performed by x86 MMX operations (e.g. adding/multiplying packed int16 within int64, and-ing/or-ing, etc) and and floating point (double) calculations. Are there any known issues in that area? anything that might help me narrow down the the search area? -- 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/37af91fb-6a0a-41ef-b3e4-1df35ea30965n%40googlegroups.com.
C compilation bug
I just refactored some old C code of mine. Surprisingly the updated code
failed in a very unexpected manner that I still don't understand. I
narrowed the problem down and here is what the relevant code looks like:
static uint8_t _x, _y; // ... _x and _y get both initialized and updated
elsewhere
void setOutput(uint8_t val) { ...}void someFunction() {
static uint8_t tmp;
...
swich(..) {
case foo: {
// tmp = _x & _y;
setOutput( _x & _y);
}
...
}
}
The code fails because the _x & _y expression suddenly passes total garbage
to the setOutput() function. Originally I had used the commented tmp
assignment
and then used tmp as an argument for that call - and that functions
correctly.
However what I find most puzzling is this: simply uncommenting the "tmp"
assignment - without even using tmp later) makes the problem
disappear...WTF?!
I am still using an older Emscripten version 1.38 and the effect is there
regardless if I compile to WASM or asm.js and whether or not I am using
different optimizer options or the closure compiler.
Any ideas what is going on here? Is this some kind of known bug or some C
feature that I am not aware of..
--
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/636d73be-ce53-4a55-bdba-66b7ab938887n%40googlegroups.com.
