Re: [dev] OOo 3.0 crashes on Mac
Hi Robert, Thanks for the reply. Do you have a pointer for the same? It is kind of a stopper for me, since our addon doesn't work on Mac :( (I'm following OOo's preference of moving the configuration to an Options dialog and hence can't configure the addon on Mac) -Karthik Robert Vojta wrote: On Wed, Feb 25, 2009 at 8:17 AM, Karthik Sudarshan karthik.sudars...@sun.com wrote: Hi, The bug is in the way OpenOffice port of MacOS, inits the JVM. Is this a known issue? Should I file a bug for the same? it's a known bug and issue was already reported.
Re: [dev] moving psprint into vcl
Hi all, since DEV300m42 is out (which conveniently contains the last changes to psprint), the move of psprint into vcl takes place now. Kind regards, pl -- Those who can, do; those who can't, teach. And those who can't teach, go into administration. -- attributed to Lois McMaster Bujold - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] No more LD_LIBRARY_PATH in build environment
With CWS sb104 integrated in DEV300m42, LD_LIBRARY_PATH (DYLD_LIBRARY_PATH on Mac OS X) is no longer set in the build environment, see http://www.openoffice.org/servlets/ReadMsg?list=interface-announcemsgNo=1202. I tried to test my changes as thoroughly as I could, but of course broke some of the lesser obvious things. If you encounter any problems building DEV300m42 on any Unix-like system that have to do with not finding some libraries, this is probably due to a still missing $(AUGMENT_LIBRARY_PATH) in some makefile.mk. That is, if there is a line foo -bar -baz in a makefile and foo fails due to missing libraries, try $(AUGMENT_LIBRARY_PATH) foo -bar -baz instead (and report your findings to me). Pending DEV300m43 masterfixes of this category are trunk/helpcontent2/makefile.pmk rev. 268436 and trunk/solenv/inc/pstrules.mk rev. 268456. If you encounter any problems running on the command line of a Unix-like system tools built during building OOo, this is probably due to those tools still relying on the solver lib directory being on the LD_LIBRARY_PATH (one such case is cwslocalize). As a temporary workaround, try to execute the command with LD_LIBRARY_PATH set to include the solver lib directory (and report any problematic commands in addition to cwslocalize to me). Thanks, -Stephan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Error handling in OOo, shouldn't we show additional info.
Hi All, While discussing with Mathias a mysterious non-reproducible problem, we came again to conclusion that OOo error handling is not the best one from the developer point of view. It is quite hard to understand what exactly goes wrong sometimes. This is of course nothing new, the discussions regarding better error-handling design can be seen regularly. But in our case, even an information, which exactly exception has caused the problem ( in our scenario there is a high probability that an exception takes place ) would be helpful. The first idea was to provide information similar to the assertions. Each extension could use the macros wrapping the existing text and adding the file name and line number. Since usually the text is based on the constant string literal, the generation of the string would not affect the performance. In case of exceptions that have no arguments ( and we have many of such cases ), we could use a default macro for each type of extension, that would not take so much time I think. That could be actually done by a relative simple script. In result the InteractionHandler could get the requests containing additional information. This information could be shown in a kind of details... subwindow of the error message. There were already suggestions from UX to extend the error messages with such a details window. The framework and applications also would have a chance to provide this additional information in this way. In general it looks from the first view to be realistic even for OOo3.2. From other side it is only a very quick first view, so any suggestions, corrections and etc are very welcome. Best regards, Mikhail. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] buildbot builds vs standard builds
Hi Rene, Rene Engelhard wrote: Hi, Thorsten Ziehm wrote: I do not see the need to bring the build bots near to the build environment here in Hamburg. The request for build bots was (as I know) to have builds in different environments to find build issues in these different environment. When these environment will be nearly the same, then we miss to find these build breakers. buildbots != tinderbox. Perhaps I am wrong, but build bots are used for this! As I know the results of the build bots are used in EIS to get the state, if a CWS is possible to build. But perhaps I am wrong. Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
