Re: [PUSHED] x11 / cairo-less build try #3
Hello Michael, first of all thanks for pushing the stuff to master :) Il 17/02/2012 17:52, Michael Meeks ha scritto: Fair enough. I suspect that for the native-dialog implementation in headlessinst.cxx we want to go for an fprintf with some parse-able syntax to the console, and then return. The salplug changes probably are not needed anymore, the #if 0 in tests are asserts that does not look regressions i've introduced. Ah yes - quite right; it'd be nice if you can revert them in your next patch. patch sent to the list Now that everything builds at runtime it fails at runtime, looking around cli_ure/source/climaker/climaker_app.cxx:476 does not show something obvious, any hint? Um; cli_ure shouldn't fail - it is some random mono / .net stuff that shouldn't be on the startup path. $ ./soffice.bin terminate called after throwing an instance of 'com::sun::star::loader::CannotActivateFactoryException' Aborted (core dumped) ... Nice - IMHO this is all a bit silly - the 'main' has no wrapper 'catch' around it, so if we get an un-caught exception we bomb out in a very unpleasant way for no particularly good reason. If you poke at desktop/source/app/sofficemain.cxx you'll see some #ifdef ANDROID-ness that adds a try / catch around 'main'. In theory there is an unoexceptionwrapper that can be put around this stuff with some magic, but ... I'll try to dig a bit more before poking the list again :) Hopefully that'll show you which shared library or random other component registration that you're missing [ though you really don't want the setIniFilename piece there ]. done in git master thanks a lot -- Riccardo Magliocchetti ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED] x11 / cairo-less build try #3
On Mon, 2012-02-20 at 09:21 +0100, Stephan Bergmann wrote: Nice - IMHO this is all a bit silly - the 'main' has no wrapper 'catch' around it, so if we get an un-caught exception we bomb out in a very unpleasant way for no particularly good reason. ... Stephan - is there a reason why we would not catch and print something helpful (a native dialog?) on unhandled exceptions around master ? ... In my experience, such exceptions typically indicate a programming error (either in actual program code, or in the way the bits of the program are combined into an installation set). And for programmers, it is often more helpful to see the direct consequences of such error than some helpful mediation on LO's part (like the infamous The user language cannot be determined message, typically caused by some problem that has zero to do with any locale data, only leading devs to start searching in the wrong direction). Haha :-) indeed, however a pathalogical, silent abort, without even an auto-save, or any message from the exception is rather unfortunate too ;-) So - what would the dis-advantages be of having an un-conditional catch wrapper around main that builds a useful string from the exception's contents (which while English, is usually more useful than an unexplained failure) ? Of course, we wouldn't necessarily need a native dialog for that - but from a bug reporting perspective - a bug with -some- pointers is more useful than a bland it fails to launch thing, presumably. ATB, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED] x11 / cairo-less build try #3
On 02/21/2012 04:07 PM, Michael Meeks wrote: On Mon, 2012-02-20 at 09:21 +0100, Stephan Bergmann wrote: Nice - IMHO this is all a bit silly - the 'main' has no wrapper 'catch' around it, so if we get an un-caught exception we bomb out in a very unpleasant way for no particularly good reason. ... Stephan - is there a reason why we would not catch and print something helpful (a native dialog?) on unhandled exceptions around master ? ... In my experience, such exceptions typically indicate a programming error (either in actual program code, or in the way the bits of the program are combined into an installation set). And for programmers, it is often more helpful to see the direct consequences of such error than some helpful mediation on LO's part (like the infamous The user language cannot be determined message, typically caused by some problem that has zero to do with any locale data, only leading devs to start searching in the wrong direction). Haha :-) indeed, however a pathalogical, silent abort, without even an auto-save, or any message from the exception is rather unfortunate too ;-) This should not be a silent abort, without even an auto-save anyway---at least not in production builds where the sal signal handler machinery should catch the abort. (No idea what the current status is, which configurations lead to which behaviour wrt. that signal handler.) Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED] x11 / cairo-less build try #3
On 02/17/2012 05:52 PM, Michael Meeks wrote: On Wed, 2012-02-15 at 17:55 +0100, Riccardo Magliocchetti wrote: $ ./soffice.bin terminate called after throwing an instance of 'com::sun::star::loader::CannotActivateFactoryException' Aborted (core dumped) ... Nice - IMHO this is all a bit silly - the 'main' has no wrapper 'catch' around it, so if we get an un-caught exception we bomb out in a very unpleasant way for no particularly good reason. If you poke at desktop/source/app/sofficemain.cxx you'll see some #ifdef ANDROID-ness that adds a try / catch around 'main'. In theory there is an unoexceptionwrapper that can be put around this stuff with some magic, but ... Stephan - is there a reason why we would not catch and print something helpful (a native dialog?) on unhandled exceptions around master ? In my experience, such exceptions typically indicate a programming error (either in actual program code, or in the way the bits of the program are combined into an installation set). And for programmers, it is often more helpful to see the direct consequences of such error than some helpful mediation on LO's part (like the infamous The user language cannot be determined message, typically caused by some problem that has zero to do with any locale data, only leading devs to start searching in the wrong direction). Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PUSHED] x11 / cairo-less build try #3
Hi Riccardo, On Wed, 2012-02-15 at 17:55 +0100, Riccardo Magliocchetti wrote: this is another update on building libreoffice without need to link against X11 or toolkits in general. The aim is to ease the deploy server side where less dependencies needed the better. Great :-) so - I got tired of seeing such a big patch, and pushed most of it to master - I hope that's allright. I removed the unit test disabling stuff. As you can see the vcl/headless/headlessinst.cxx has been shamelessly copied from Android, you can see still some #if 0-ed code because i'd like to have soffice.bin run without crashing to assure myself that the code is not needed :) Fair enough. I suspect that for the native-dialog implementation in headlessinst.cxx we want to go for an fprintf with some parse-able syntax to the console, and then return. The salplug changes probably are not needed anymore, the #if 0 in tests are asserts that does not look regressions i've introduced. Ah yes - quite right; it'd be nice if you can revert them in your next patch. Michael i've not forgot about cleaning up Library_vcl.mk :) I got annoyed by that and fixed it myself on master ;-) it seems to work, though ideally we'd share more from Library_vcl.mk with the other backends eg. the gtk3 one. Now that everything builds at runtime it fails at runtime, looking around cli_ure/source/climaker/climaker_app.cxx:476 does not show something obvious, any hint? Um; cli_ure shouldn't fail - it is some random mono / .net stuff that shouldn't be on the startup path. $ ./soffice.bin terminate called after throwing an instance of 'com::sun::star::loader::CannotActivateFactoryException' Aborted (core dumped) ... Nice - IMHO this is all a bit silly - the 'main' has no wrapper 'catch' around it, so if we get an un-caught exception we bomb out in a very unpleasant way for no particularly good reason. If you poke at desktop/source/app/sofficemain.cxx you'll see some #ifdef ANDROID-ness that adds a try / catch around 'main'. In theory there is an unoexceptionwrapper that can be put around this stuff with some magic, but ... Stephan - is there a reason why we would not catch and print something helpful (a native dialog?) on unhandled exceptions around master ? Hopefully that'll show you which shared library or random other component registration that you're missing [ though you really don't want the setIniFilename piece there ]. Does that help ? Thanks ! Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
