[dev] Libre Graphic Meeting
Hi all, For your information, the 17, 18, 19 march 2006, will take place the Libre Graphic Meeting in Lyon (France). Developers from several projects like Gimp, Blender, Scribus, Cairo... will be present, see the conference schedule here http://libregraphicsmeeting.org/schedule.php. Most of the conferences will be presented in English. The goal of the 3 days it to make developers from graphic projects meet and share their knowledge. If you need more information about it, please let me know. Kind regards Sophie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] why making compiling OO such a secret?
2006/2/5, Johannes Walther [EMAIL PROTECTED]: I now spent two days trying to compile OO. I tried different ways, read the Wiki and linked documents but always failed. What is it that makes you so hostile against people who try compiling OO? As I wrote two days ago, a simple build of the 2.0.1 tarball failed after 17 hours (resp. I don't even know if it failed, but at least it didn't run). That was with dmake in toplevel dir. Then I tried compiling it from 2.0.1 CVS (with build debug=true --all) which was even worse. First it threw error: duplicate `static` when build was called with debug=true in store/source/filelckb.cxx. Then minutes after that another problem arose while processing some file I forgot into an html and I was stuck. Then I tried ooo-build (ooo-build-src680.150.0). Not mentioning its configure doesn't understand --with-gnu-cp and --with-gnu-patch so it's hard to get it work on FreeBSD. But what stopped everything was that patching psprint_config/configuration/ppds/makefile.mk with psprint_config-no-orig.diff failed even before compilation started. Why the hell can't you produce code that at least builds? Johannes Well, I got very nice, quick, and helpful responses when I had problems compiling the code with only the free versions of MS compilers. Could it have anything to do with the way You ask for help? /$ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Error: no office executable found!
Hi J, I cannot connect to OO from a JSP under Tomcat. Using the bootstrap call: xContext = com.sun.star.comp.helper.Bootstrap.bootstrap(); I receive the following error: com.sun.star.comp.helper.BootstrapException: no office executable found! I can run the same code directly, from a test main java application. Does anyone know what needs to be set for this to work from a servlet container, specifically Tomcat? I had the same problem with my Eclipse project. Try adding the folder that contains the office executable to you classpath. That will help. Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] why making compiling OO such a secret?
I now spent two days trying to compile OO. I tried different ways, read the Wiki and linked documents but always failed. What is it that makes you so hostile against people who try compiling OO? As I wrote two days ago, a simple build of the 2.0.1 tarball failed after 17 hours (resp. I don't even know if it failed, but at least it didn't run). That was with dmake in toplevel dir. Then I tried compiling it from 2.0.1 CVS (with build debug=true --all) which was even worse. First it threw error: duplicate `static` when build was called with debug=true in store/source/filelckb.cxx. Then minutes after that another problem arose while processing some file I forgot into an html and I was stuck. Then I tried ooo-build (ooo-build-src680.150.0). Not mentioning its configure doesn't understand --with-gnu-cp and --with-gnu-patch so it's hard to get it work on FreeBSD. But what stopped everything was that patching psprint_config/configuration/ppds/makefile.mk with psprint_config-no-orig.diff failed even before compilation started. Why the hell can't you produce code that at least builds? Johannes ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] why making compiling OO such a secret?
--- Henrik Sundberg [EMAIL PROTECTED] wrote: Well, I got very nice, quick, and helpful responses when I had problems compiling the code with only the free versions of MS compilers. Could it have anything to do with the way You ask for help? Maybe it has, but I can't say. You're free to read my post from 2006-03-02 13:11 and tell me if it was written in bad style - but produced no result though. My post from last hour wasn't to ask for help compiling - at the moment I gave up, being frustrated after sitting here for nearly ten hours without anything done. I just wanted to know why the code produced by the maintainers is so fragile, so uncompilable - or the other way around the docu/tools are that bad/missleading. Johannes ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] warnings01: -Wnon-virtual-dtor
Hi Stephan and all, The consensus back then was to keep -Wnon-virtual-dtor switched on globally, and only switch it off (together with all other warnings) within cppumaker-generated headers, on the grounds that -Wnon-virtual-dtor was considered a useful tool to find errors. However, trying to compile cppuhelper/qa/propertysetmixin/comp_propertysetmixin.cxx, I fear we have to rethink the case: cppu::PropertySetMixin is part of the stable API of OOo/URE, is a class template, and contains a non-virtual dtor and virtual functions. Since it is part of the stable API, we cannot change its dtor to be virtual (and even if we could, one could argue that that would not be what one would want to do, but consider it a hack to work around the warning). And since it is a template, we cannot disable the warning locally---the warning is emitted at the end of each compilation unit that includes cppuhelper/propertysetmixin.hxx, rather than from within cppuhelper/propertysetmixin.hxx itself. The only solution I see is to bite the bullet and globally disable -Wnon-virtual-dtor. Mhmm. Why not make the d'tor protected? As for compatibility, there should be no binary difference. Only the use would be constrained, but if cppu::PropertySetMixin is indeed used as a mixin, then in most cases (whenever it is not the first base class or any other base class is virtual, may be even whenever it is not the only base class) calling its d'tor directly would be a bug anyway. So maybe this does not break practical compatibility? You mentioned somewhere else, that making non-virtual d'tors protected does not solve the problem of the warning. But as it solves the defect, may be later versions of the compiler will not complain anymore? So we would at least keep the option to switch the warning on in future. Nikolai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
