[dev] Moving to bost 1.3?
Hi, Currently, OOo uses boost 1.34.1 for platforms with a GCC =4, and boost 1.30.2 + a separated spirit 1.6.1 for all other platforms (see boost/download in the source tree). For various reasons, we'd like to clean up this mess, and move to a single version (containing spirit). This could be boost 1.34.1, but given that this version is pretty old already, we'd prefer a recent version - boost 1.39.0, that is. The work for this is ongoing in CWS boost134. In this CWS, a move to 1.39 has been done, and it compiles on the standard build platforms provided by Sun HH: Solaris Intel/Sparc, Linux 32/64, Mac OS X, Windows. We invite everybody porting OOo to another platform to give feedback to this project. As rumor has it, boost 1.39 creates problems when used on some platforms (either at compile- or runtime), so if your platform is know to be one of those, or if you just want to be sure - please give the CWS a try. If boost 1.39 proves to be too problematic, an option would be to indeed stay with 1.34 (on all platforms). This would require reverting a few changes in the CWS, but on the standard platforms mentioned above, an older version of the CWS, using 1.34, also compiled fine. Any feedback is appreciated. As an additional note, it has been suggested to not commit the boost*.tar.gz to boost/download, but make it a pre-requisite which needs to be downloaded before building. This would (for 1.39) save 50M in the repository for every version ever committed there. Opinions on this plan are also welcome. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build problems with CWS odff06 rebased to m50
Hi Christian, Frank Schönheit - Sun Microsystems Germany wrote: How to clear output trees? I'm a dummy concerning building. In cygwin, something like cd $SRC_ROOT find . -maxdepth 2 -name wntmsci12* | xargs rm -rf should do. nitpickthe * is not protected against expansion from the shell - but shouldn't matter since there is no soutput dir in $SRC_ROOT/nitpick Ehm - shouldn't the protect it? But I wonder why you don't simply suggest a dmake clean in toplevel. Because at least /me usually works in an environment where this doesn't work (no complete source tree) :) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build problems with CWS odff06 rebased to m50
Hi Regina, ERROR: The following files could not be found: ERROR: File not found: emboleobj.dll ERROR: File not found: emsermi.dll ERROR: File not found: oleautobridge.uno.dll Sounds like some OLE-related module has not been built (correctly). According to trunk, emboleobj is built in module embeddedobj, emsermi in embedserv, and oleautobridge in extensions/source/ole. All three libs have in common that they are/should not packed (if not even built) when --disable-atl is given ( http://svn.services.openoffice.org/opengrok/xref/Current%20(trunk)/scp2/source/ooo/file_library_ooo.scp#418 http://svn.services.openoffice.org/opengrok/xref/Current%20(trunk)/scp2/source/ooo/file_library_ooo.scp#1037 ) This either means your build of scp2 was not successful, or contained remaints of a previous (non-disable-atl) build, or that your DISABLE_ATL environment variable is somehow broken: http://svn.services.openoffice.org/opengrok/xref/Current%20(trunk)/scp2/source/ooo/makefile.mk#224 What does echo $DISABLE_ATL on a console output? Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build problems with CWS odff06 rebased to m50
Hi Christian, Because at least /me usually works in an environment where this doesn't work (no complete source tree) :) Doesn't dmake clean still work? If the question was: Should it work in an OOo env? I suppose it should. If the question was: Doesn't it work in the env you mentioned? No, it doesn't, since there's no makefile.mk for dmake to operate on. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build problems with CWS odff06 rebased to m50
Hi Regina, Searching with OpenGrok I see, that the file nametree.hxx is contained in DEV300_m49 but no longer in DEV300_m50. A file object.hxx exists but in store/source/ not in store/inc/store. Suggestions? If you did not clear your output trees after updating to the new milestone, a dmake depend=1 might help - it will throw away the old auto-generated file dependencies, and recreate them on the next dmake run. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: [l10n-dev] Localisation moved into own module
Hi Ivo, I guess that for building a language pack the OOo source tree would not be needed anymore, except maybe a few modules, is still a wish for the far future? MBA had the idea to move also all resource source files into a own module but we first need to discuss this a bit further Don't think this would be a good idea. I'd hate to deal with / build Yet Another 100MB monster if I just want to change a resource string in a project of mine. JM2C Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build problems with CWS odff06 rebased to m50
Hi Regina, How to clear output trees? I'm a dummy concerning building. In cygwin, something like cd $SRC_ROOT find . -maxdepth 2 -name wntmsci12* | xargs rm -rf should do. Alternatively, cd instsetoo_native build --from solenv --prepare should also do what you need, and also clear the so-called solver ($SRC_ROOT/solver, where all files built in a module are delivered to, to be used by other modules). Be aware that both approaches mean that you do a full rebuild of the complete OOo source tree after that. However, I often found the time spent for that a better investment than the time wasted for figuring out bugs caused by out-of-date build trees. a dmake depend=1 might help - it will throw away the old auto-generated file dependencies, and recreate them on the next dmake run. That doesn't help. I have also tried dmake depend=t and dmake depend=true. Hmm, sorry, no idea then. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: [l10n-dev] Localisation moved into own module
the DEV300 m51 milestones contains the cws l10ncleanup04 that moves all the translations that are spread over the office code to the new module l10n. Hey, wow, finally, well done! :-) Good news; not only for translators, but also for developers because now a recursive grep for some resource ID in the source directories doesn't produce a gazillion lines with localize.sdf content anymore. Indeed, that's great news, thanks! And if one wants to know to which source code module a certain dialog's message belongs, it should be possible to grep that from the one l10n/source/*/localize.sdf file. Just not for en-US :-( Well, en-GB most times probably will deliver the result. http://grok.services.openoffice.org :) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] default patch owners for modules
Hi Caolán, Who should maintain the data included in the script? Developers themselves? Ideally I guess the developers who maintain/don't actually maintain a given module would update it themselves as owner there. That won't work. Most developers do not even know this list, and even if we tell them, they will have forgot at the time they resign from their maintainer role. The only feasible way is exactly what you're doing currently: Update as soon as we find it's necessary ... Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] default patch owners for modules
Hi Caolán, I generally use http://qa.openoffice.org/issue_handling/submission_gateway.html as my launch page for submitting bugs. Where do the default owners for patches there get filled in from ? Is it simply hardcoded into the html of that page ? i.e. I wonder if that page has fallen out of sync with reality in some cases. It definitely doesn't contain all the newer modules that have appeared, e.g. reportdesigner etc., and (no offence intended) mh is listed as the module owner for e.g. sal which doesn't seem quite right. http://qa.openoffice.org/issue_handling/create_submission_gateway.pl And yes, that's somewhat outdated. Feel free to check out, update, run, and commit the perl script :) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Please fix these security flaws that could be considered bugs ...
Hi Malte, Wrt the wish to automatically remove entries where the document is no longer available: This is not so obvious for me. I sometimes open documents from encrypted containers or network shares which I mount on demand only, or from USB devices, so opening the menu in the wrong time would remove these items (not that I would care about it... ). I wish we'd had a The document ... does not exist anymore. Do you want to remove the entry from the 'Recent Files' list? [Yes] [No] message box for this purpose, raised when the user chose such a not-existent-anymore file. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Please fix these security flaws that could be considered bugs ...
Hi Rich, and maybe checking for unavailable files when the menu is opened, and making them visually different (either disabled, or coloured differently). threaded, of course, so that it does not block the menu, but updates it in the background, even while it is open :) Given that this is potentially expensive (consider files on the network, where checking the file existence can take minutes, depending on the network state), I wouldn't really consider this a good idea, even when done in the background. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] create/modify writer docs without running OO
Hi Dan, Using the tutorials in the wiki, I now know how to load, modify, and save writer docs using the API. However, we are writing a desktop app that we will distribute and would like to avoid distributing the open office executables (just the api libraries, would be preferable). All I need to do is add a graphic or two and some values in pre-specified locations. Is it possible to do this without using the OO services of a hidden OO instance and just either parse the doc or build an app from scratch using API calls? There's no stripped-down version of OpenOffice.org, but the ODF Toolkit at http://odftoolkit.org/ pretty much sounds like what you want. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Martin, From my perspective one reason for the high amount of regression is the high amount of integrated child workspaces short before a feature freeze. In the moment the ITeam (the QA representative) does the nomination before feature freeze. As an immediate action (for the upcoming 3.2 release) from my side I will limit this freedom until 4 weeks before feature freeze, in the last 4 weeks before feature freeze, In my opinion, it's strictly necessary then to have parallel development branches earlier than we have today. That is, if there are a lot of CWSes coming in, but not approved/nominated for the next release, then we should *not* pile them, but instead have a different branch to integrate them into. Else, the quality problems will be shifted to post-release only. An yes, extending the various phases we have - feature implementation, bug fixing, release canditates -, as suggested by Ingrid, would help, too. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Mathias et. al., The problem is ... Seeing many different explanations in this thread, and suggested solutions ... I wonder if we should collect some data about the concrete regressions, before we start speculating 'bout the larger picture. Oliver's table with the introduced in and found in was a good start, I think we should have this for nearly all of the regressions, ideally together with a root cause. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Ingrid, Two problems here. The worst one is that you cannot control that this new rule is applied. Who decides that a code change is too huge to risk it for the next release in two months or so? You won't count lines, don't you - that would be stupid. Those who are willing to act carefully are doing that already I am convinced. And those who are not acting carefully you cannot control really with this new rule. So introducing this new rule will basically change nothing. I beg to disagree. Of course, as you point out, there cannot be a definite rule of what change is too big in which release phase. But alone raising the awareness that large code changes are Bad (TM) after feature freeze might help. And if the analysis of current show stoppers reveal that a significant mount is caused by late big code changes, this is a good argument I'd say. So, let's not call this rule as it if you don't follow it, you'll be shot. I'd consider it a guideline which every reasonable developer would usually follow. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Thorsten, The problem is a bit more complex. The testers and test script writers do not have any time for writing new test cases for new functionality, they do not have time to check fixed issues in master, they do not have time to check code changes in a CWS as much as they should and at the end you are right, they do not have the time for real-life testing. That statement frightens me - way too many they do not have time, for my taste. Is there any chance to change this? Or have we already reached the point where the daily effort to keep QA running on the current (insufficient) level prevents us from investing the effort to make QA more efficient? For instance, is it possible that QA does not have time to write new automated tests because this is such a laborious and time-consuming task, but we do not have the time/resources to make it an easy and quick task? Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] qa and qadevOOo
Hi Shuang, I notice there is a qa sub-module under each module, for example sw/qa, sd/qa.. but there is also a qadevOOo. Who can tell me the relation ship of these qa related modules? Does automation test of qadevOOo depend on qa of each module? How to build these /qa ? module/qa contains test cases for the module's code. Often, but not always, this is Java code which depends on the qadevOOo framework - so-called complex tests cases or UNO API tests. The concrete structure of the qa folder depends on the module, there's no general rule. To find out, I suggest you look for a makefile.mk somewhere in the qa folder (or subfolders thereof), and try what happens when you do a dmake. Either the tests are ran immediately then (which is the case for C++ test cases, usually), or the tests are compiled, and a subsequent dmake run or dmake run_test_name will will actually run it. Note that for the complex tests and the UNO API tests you need a running OpenOffice.org instances, started with the usual --accept=... parameter. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Ingrid, that now bite us, most of them have been found by users or testers *working* with the program. Adding more CWS test runs and so shortening the time for real-life testing will not help us but make things worse. I don't agree. Preventing the integration of bugs earlier in the production phase especially before the integration into the master trunk would give us much more freedom. Now we always need to react on show stoppers and react and react and uh then the release time line is on risk. All that, because the bugs are already in the product. If you instead detect the bugs before they are integrated into the product you can keep cool, refuse the bad CWS and thus not the release is on risk but only the single bad CWS. Hmmm ... difficult. On the one hand, I agree (and this is what you can read in every QA handbook) that finding bugs earlier reduces the overall costs. On the other hand, I suppose (! - that's an interesting facet to find out when analyzing the current show stoppers: found by whom?) that in fact the majority of problems are found during real-life usage. And nobody will use a CWS in real life. So, getting the CWS into the MWS early has its advantages, too. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Ingrid, There are more than the VCLTestTool tests. We have the performance tests and the UNO API test and the convwatch test. All those are in the responsibility of the developers. I think only convwatch is not mandatory. As far as I know, confwatch is mandatory, too. In theory, at least. In practice, I doubt anybody is running it, given its reliability. Which brings me to a very favorite topic of mine: We urgently need to possibility to run all kind of automated tests (testtool tests, confwatch tests, UNO API tests, performance tests, complex test cases - more, anybody?) in an easy way. Currently, this is *a lot* of manual work, and not remotely reliably (some test infrastructures are semi-permanently broken, and some tests produce different results on subsequent runs, which effectively makes them useless). As a consequence, a lot of those tests are not run all the time, and the bugs they could reveal are found too late. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Thorsten, Writing good test scripts isn't an easy tasks you are right. This is status for all software products. Writing test code costs more time than writing other code. Try it out with UNIT tests ;-) I know for sure. Writing complex test cases for my UNO API implementations usually takes the same time than the implementation took, or even more. Usually, but not always, I think it's worth it :) Okay, so let me make this more explicit: I see a ... remote possibility that our *tooling* for writing tests - namely the testtool - has strong usability deficiencies, and thus costs too much time for fighting the testtool/infrastructure, which could be better spent in the actual test. I might be wrong on that, since I seldom come in touch with testtool. But whenever I do, I feel it hard to believe we live in the 21st century ... Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Max, I just thought there is a higher chance of getting support for cygwin in the near time than having these automated tests in EIS. As far as I know, there's a group working on this. It would still leave us with the reliability problem (sometimes a test simply gives you bogus results, and the solution is to re-run it), but it would be a tremendous step forward. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Max, Do you know, how often a CWS returns back to development because of broken functionality, not fixed issues or process violation? of course in regards to process violation, nothing would change. I am talking about e.g crashing issues. If the developer tried it and it does not crash anymore, QA should not have to test the scenario again and waste time on reproducing the issue again(and again when closing the issue) Difficult to draw the line: Which issues need verification, which don't? Also, having seen a lot of misunderstandings (Oh! I though you meant *this* button, but now I see you meant *that* one!), I think it is a good idea that somebody who did not fix the issue verifies it. And the CWS is the the best place for this verification, I'd say. Also, IMO good QA engineers tend to not only blindly verify the concrete issue is fixed, but think about what they saw and did. Sometimes, this leads to additional issues, or discussions whether the new behaviour is really intended and Good (TM), and so on. At least this is my experience with DBA's QA, and I would not like to miss that, since it finally also improves the product. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Rich, summary - while release early, release often is very important, stable dev snapshots are as important. Yes, but how to reach that? In theory, trunk is always stable, since every CWS has undergone tests (before integration) which ensure that it doesn't break anything. Okay, enough laughing. Finally, that's exactly the problem here: Too many serious bugs slip Dev/QA's attention in the CWS, and are found on trunk only. If we fix that, trunk will automatically be much more stable. Easy to say, hard to do. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Max, yes, this is true, so would you say we could skip the step from going from verified to closed, doing this verification again? I'd say this gives the least pain/loss. (Though my experience with dba31g, whose issues were not fixed at all in the milestone which the CWS was integrated into, lets me be careful here. On the other hand, this was not discovered by the verify in master and close step, so ...) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Christian, Maybe in the cvs days. Now with svn there have been a couple of failed integrations, quite a number of changes that were reverted by other cws. Using the verified-closed step to find broken tooling/SVN/integrations/builds sounds weird, doesn't it? So, this shouldn't be a permanent argument (though it might be a good one at the moment), but only hold until the root causes are fixed. So I don't have trust in that number. And this makes it really hard to check when your fix was integrated in mXX, but later gets reverted by integration of another cws in mXX+4. You never can prevent that. If you verify-close the issue in mXX+2, you won't find the reversal in mXX+4, anyway. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hello KP, Promoting QA in community is not enough - you have to retain people. In order to retain people project needs to fix their issues, which inspires people to use milestones in daily work. Many of developers do not know how great it feels when issue you are interested in gets fixed relatively quick. Developers also do not know that it sucks when fix for your issue is delayed and delayed. I'd claim a lot of developers, if not most, know how this feels - in both ways. It's just that we have much more issues than developers, and developers have only a pretty small amount of time for fixing for retaining people. In combination, this might look like developers do not care for the issues reported by other people, but it's just not as easy as this. I think many users would rather have faster fixes than more stable milestone (you always can go to prev release/milestone). Uhm, I doubt that. What you're saying here is that we should sacrifice quality to more fixes. I believe this would be bad for OOo's overall reputation. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Thorsten, The time to master isn't a problem currently, I think. That's not remotely my experience. See dba31g (http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=7708OpenOnly=falseSection=History) for a recent example of a CWS which needed 36 days from ready for QA to integrated state (and add a few more days for the milestone to be finished). A few more? dba31a: 26 days dba31b: 42 days dba31e: 26 days dba31f: 13 days dba31h: 23 days mysql1: 17 days (and that one was really small) rptfix04: 9 days (though this number is misleading for other reasons) dba32a is currently in QA - for 9 days already (which admittedly is also somewhat misleading, since a regression was fixed meanwhile without resetting the CWS to new). Okay, there were also: fixdbares: 2 days dba31i: 7 days Don't get me wrong, that's not remotely QA's alone responsibility. Especially the first OOO310 milestones had a lot of delay between CWSes being approved and being integrated. But: time-to-master *is* a problem. At least for the majority of CWSes which I participated in, over the last months. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Mechtilde, So more testing on CWS is also welcome! Yes Full ACK to last sentence. And this is not only a task for the Sun people. The persons who are interested at a CWS must be able to test a CWS. And this also if they aren't able to build OOo on their own. I think especially we in the DBA team have good experiences with providing CWS snapshots at qa-upload. I am really glad that our community (including you!) does intensive CWS QA, and this way also found bugs pretty early. However, as good as this worked out for us, I am unsure whether this would scale. I suppose if *every* developer would upload his/her CWS, then people would pick a few only, and the majority would be still be untested. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hello Kirill, Uhm, I doubt that. What you're saying here is that we should sacrifice quality to more fixes. I believe this would be bad for OOo's overall reputation. What I mean to say is that we could sacrifice quality of snapshots to bring in features faster and to motivate QA volunteers to test in real life (fast-paced development is yet another usage motivator). Besides, it is questionable what is worse for reputation - having 2-3-4-5 y/old usability defects or bugs versus regressions. But bringing CWSes faster into the master would not yield the developer's output. In other words, we would not be able to fix only one more bug by that. At the opposite, I would assume that if we reduce the snapshot quality in the way you propose it, then developers would be able to fix *less* issues, since they would need to do more regression fixing, which is the more expensive the later in the release cycle it happens. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Mathias, I don't see a lot of sense in making tests mandatory just because we have them. If a test probably can help to find problems in areas where we know that we have them, fine. So when tests are defined it's necessary to see which problems they can catch and if that's what we need. I had a look on the regressions that I can judge - some of them might have been found with convwatch, for most of them I have serious doubts that any test we have would have found them. It's still working with the product that is necessary. So until now I fail to see which tests could help us further without burning a lot of time. Quite true ... A personal goal I set for the 3.1 release was to write complex test cases for (most of) the show stoppers found in the DBA project. Since we regularly run our complex tests on all CWSes, at least those concrete stoppers would not have much chances to re-appear. (And as it is usually the case with complex test cases, they also cover related areas pretty well.) Unfortunately, we didn't have too many 3.1 stoppers so far :), so I am not sure whether it will help. But it's worth a try, /me thinks. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Mechtilde, I don't think that the developer have to upload each CWS build. I prefer that the possible tester are able to pick up the CWS builds they want beside the normal test scenario. Ah, you're right, that would be most helpful ... Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] UNO API exception specifications (was: [dev] Error handling in OOo, shouldn't we show additional info.)
Hi Mathias, However a reasonable error handling would look like, IMO carefully re-designing UNO to add more exceptions specifications to (a lot of) methods is a must-have. +1 Just to play the devil's advocate: without careful considerations that would end in adding throws css.uno.Exception to any method, though perhaps it's the right approach for all generic APIs (generic APIs need generic exceptions - don't they?). Don't think so. I suppose the line is to be drawn (if at all) between ¨high level¨ and ¨low level¨ API (whatever that means :), where the former has an increased chance of throwing a WrappedTargetException (which I'd consider more appropriate than a generic Exception). OTOH designing exceptions right is very hard and often needs a lot of thinking. So I don't expect that we can fix that in a big bang release, we will need quite some time to fix that. I would be happy if we would allow for such fixing. I don't want to fix all of those at the same time, but being able to fix them incrementally, as they bite me, would be great. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Simplify Reference Casts by template constructors
Hi Rainman,
After a period of time of developing with URE, I find the C++ UNO
class Reference is not very comfortable for use sometime.
The problem is, when I have a reference of base interface XA and a
reference of derived interface XB, I can't make xA = xB directly.
Instead I have to query XA from xB like this xA = ReferenceXA::query(xB).
¨xA = xB.get()¨ would do, too, and be less expensive.
I wonder that whether we can use template constructors to simply this
situation.These constructors may something like this:
template typename interface_type
class Reference
{
template _interface_type
Reference(const Reference_interface_type rRef)
{
interface_type* p = NULL;
_interface_type* _p = NULL;
p = _p; // compiling time cast check.
_pInterface = iquery( rRef.get() );
The last two lines could be to just assigning (and aquiring) rRef.get()
to _pInterface.
}
...
Now we can simplify the cast code above to
xA = xB;
I am not sure we should do this, implicit constructors usually add
ambiguity ...
Ciao
Frank
--
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] UNO API exception specifications
Hi Eike, OTOH designing exceptions right is very hard and often needs a lot of thinking. So I don't expect that we can fix that in a big bang release, we will need quite some time to fix that. I would be happy if we would allow for such fixing. I don't want to fix all of those at the same time, but being able to fix them incrementally, as they bite me, would be great. Unfortunately, adding exceptions to a method changes the API contract, so fixing things incrementally would incrementally destabilize API use. what do you mean by destabilize? The only problem I see is that classes implementing the respective interface need to be adjusted, too, which of course is error prone. If this adjustment is not made, implementations throwing the new exception might crash (at least on platforms where the compiler respects the throw specification on a method, and generates code to assure it). Nonetheless, I think that's manageable. (Side note: If the tool generating our C++ headers would have the - long-desired - feature to create a ¨#define DECLARE_XFOO¨, then the problem would be less severe, as then a simple recompilation would adjust the headers, and the not-adjusted source files would simply break during compilation.) We'll need some versioned API for this. I guess many are missing such thing and didn't do useful but not required changes for just the reason of API compatibility. Not sure we need versioning, but we definitely need to way to (carefully) break compatibility. As I've been told, this has been a topic on this week's engineering steering committee meeting ... Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Simplify Reference Casts by template constructors
Hi Rainman,
I have another ideal, it is better and safer than the last one I mentioned.
I add a conversion operator to Reference, instead of a constructor, here is
it:
template class base_interface_type
inline SAL_CALL operator const Reference base_interface_type ()
const SAL_THROW( () )
{ return Reference base_interface_type ( get() ); }
I tested some cases, and it works well.
How do you think it? I am not very sure it will work for all situation.
Uhm - implicit conversion operators are Evil (TM) :)
This is a place where my gut feeling says we should sacrifice the little
convenience we could gain (xA = xB instead of xA = xB.get()) for
clarity. At least clarity in reading code, but also clarity in reading
the error messages which the compiler would raise for incompatible xA
and xB :)
Admittedly, this feeling is not backed up by strong arguments, but I am
sure others could come up with some. Stephan?
Btw, did you compile the complete OOo from scratch with this change?
Would be interesting to know whether the existing code already survives it.
Ciao
Frank
--
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] UNO API exception specifications
Hi Stephan, The only problem I see is that classes implementing the respective interface need to be adjusted, too, which of course is error prone. If this adjustment is not made, implementations throwing the new exception might crash (at least on platforms where the compiler respects the throw specification on a method, and generates code to assure it). What about language bindings other than C++? Basic an Python ignore are not affected by changed exception specifications, as far as I understand. Java code would need to be recompiled, which would break until the code is adjusted (right?). However, this is probably something on the ¨to-be-accepted¨ list, if we allow for such a change in the UNO API (and this allowance was my premise for this discussion). What other language bindings are there? Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] UNO API exception specifications
Hi Rony, *The former: it is just frustrating to have a program bomb and get a message like exception occurred. (Yielding the message: go, figure...)* which nicely fits into the original thread :) Fixing those exceptions (which I consider buggy in the current messageless-shape) to carry a meaningful message would address the original problem of the thread as well as the API consumer's problems. (MM: Sorry, could not resist :) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi T. J., May I agree, wholeheartedly? From my own long years of dealing with users (some of them very angry), I conclude that the *error* is what bothers them, not the error *message*. They just want to get their work done. A little techno-babble is only a small point. ... Consider the opposite case, where user and programmer are _under_whelmed by lack of information. A real case: Line 1: Error saving the document filename : Line 2: Error writing file. I would *kill* for a little techno-babble here (for once, I get to wear the angry user hat). Then I could report the bug, with a chance that somebody could fix it, even without a reproducible case. Okay, I see your point here. I am still not convinced that transporting the information via css.Exception.Message is the best idea ever, and won't cause problems later on, but I definitely see your point. Logging errors is an excellent idea. Keeping such logs short enough to avoid burdening the file system, or performance, but long enough to be useful, is only a small problem, with several possible solutions. But logging is a longer-term enhancement, No. Logging facilities are available, and the same script which produces a add file/line info to exceptions patch could equally easily produce a add logger calls patch. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Okay, I see your point here. I am still not convinced that transporting the information via css.Exception.Message is the best idea ever, and won't cause problems later on, but I definitely see your point. See my other mail in response to Stephan's comment, which I saw after I wrote the above ... Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Stephan, For one, end-user oriented exception messages simply do not work in general (think about the category of unchecked or runtime or programmer made a coding mistake exceptions---what use is it for the end user to see a localized Index i=7 was out of bounds of array xyzStrangeList (ranging from 0 to 3)?). For another, common practice *is* to put developer-oriented data into exception messages. For randomly picked evidence of the latter take, for example, a quote from Item 45 of Effective Java: The string representation of an exception should not be confused with a user-level error message, which must be intelligible to end users. Unlike a user-level error message, it is primarily for the benefit of programmers or field service-personnel for use when analyzing a failure. Therefore information content is far more important than intelligibility. (Of course, there is nothing wrong with questioning common wisdom. I just personally think that common wisdom is indeed right here.) And the quote you cited might be an indication I am wrong here :) (though I could try to debate about the difference between an exception's string representation and the exception message :) As a consequence, this would mean that our error handling infrastructure is even worse than I thought: If we cannot use Exception.Message to transport user-messages, or information to *generate* meaningful user messages, then ... With very few exceptions (sic), none our exception classes has additional fields for transporting the necessary information. (Not to mention ... I remember having seen an exception class with an error code field which was not even documented, and used non-UNO SFX-internal error codes. Argh!) So, let's pave our exception messages with techno-babble, for the sake of usability ... who cares :( Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Mathias, When we talk about seldom, hard to reproduce errors, then let's introduce a logger which is permanently switched ON, or at least switched ON for log levels = LogLevel.SEVERE. (by default, loggers are OFF, i.e. do not log any event, regardless of the LogLevel.) Everything that must be switched on doesn't help read again, please: ¨permanently switched on¨ was what I wrote :) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Without having the bigger picture how good error handling should look like while we are at it, and mentioned UNO incompatibility already ... I just came across (yet) another issue where a severe error was silenced instead of propagated to the caller (and thus caused document corruption), simply because the respective UNO method (XFilter::filter) was poorly designed, and did not allow to throw any but a RuntimeException. However a reasonable error handling would look like, IMO carefully re-designing UNO to add more exceptions specifications to (a lot of) methods is a must-have. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Mathias, I think that exception messages are not made for end users. As already said, this might be the fundamental point of disagreement between us :) Usually errors and exceptions in programs must be interpreted, put into a context and translated before they can be presented to users. While presenting raw exception messages to users might work in some cases, it won't in the majority of situation where exceptions happen. And especially it doesn't work in case of i/o errors. If an error happens while e.g. a temporary file is written that is just an intermediate step in a process, it won't help the user to tell him what happened. Okay, I see your point here. In Base's code, this is usually solved by chaining exceptions, where a high-level layer throws an own exception describing what happened, and chaining the caught lower-level exception. Admittedly, uno.Exception misses sdbc.SQLException's cool chaining feature :) On the other hand: The translation you describe rarely happens, and nonetheless the exceptions *are* displayed to the user. My favorite example still is the Basic IDE, which you can get easily into displaying NoSuchElementException or IOException without any further info, which is of no help at all to script developer (which happens to be the end user here). OTOH if this is a very rare case that is hard to reproduce, it would be great to have more developer related information that can be reported or automatically sent in an error report. Exceptions are diagnostic tools for developers, and they either can convert them into messages shown to the user (if possible) or handle them in other ways, perhaps by throwing another exception. Enriching the diagnostic message with information that helps developers is very useful, and so adding file names and line numbers would be a relief. Whether it can be logged in a file, in a report or in a details window is of minor importance. Assuming you add file/line to the exception messages. How will users see it, so they can tell you? Either, they explicitly need to switch on some generate additional developer diagnostic information feature - which is what logging thrown exceptions would also allow, and which you say you do not want to require, 'cause of the nondeterministic bugs. Or, the developer diagnostic information is _always_ presented to the user, also to the ones not encountering your nondeterministic bugs, who are not interested in sending you the info. Which I continue to consider a big usability problem (slaying end users with developer babbling). I wouldn't call this a hack. Depends on the intended semantics of Exception.Message. In your interpretation, it might be valid to transport file/line it it. In my interpretation, this would be a hack, since Message is intended for the real message, which would need to be separated from the file/line info. By the way, this separation is highly error-prone, and this is one reason why I call the solution a hack: If you mix file/line with other message content, how will you separate it? If you do not mix it, how will you determine for a given message that it's file/line info? In both cases, how do you *reliably* do this, even for exceptions thrown in third-party components (and passed to your interaction handler)? Too many uncertainties for my taste. IMO, if you need file/line info, use some dedicated file/line info channel. Do not rededicate something which by luck already exists, but was not (canonical) intended for this purpose. (This rededication of something luckily already there and not used otherwise is another point why I call this a hack. And continue to do so, sorry.) So before you can call something a hack, you should present a realistic, cleaner solution that fulfills the same requirements. So: how can we get better diagnostic information in the case of bugs that are hard to reproduce and where we just know that an exception has been thrown somewhere in the code. When we talk about seldom, hard to reproduce errors, then let's introduce a logger which is permanently switched ON, or at least switched ON for log levels = LogLevel.SEVERE. (by default, loggers are OFF, i.e. do not log any event, regardless of the LogLevel.) Then, in your code where you throw an exception, log it to this logger. (Currently, loggers always re-create their log file in a new OOo session, but this can be adjusted, of course.) Now if somebody tells you about an error which needs to be diagnosed, tell him to send you the log file. Or even to only look at the last few lines of the log file, and tell you what's written there. This solution shouldn't add too much overhead, assuming that exceptions are, well, exceptional events, and logging itself isn't too expensive. Mikhail's suggestion is not meant to be a replacement for our suboptimal error handling! But it imposes additional restrictions on a future somewhat-more-optimal solution, thus making it more difficult to
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Mikhail, My intention was to allow user provide the developer with information that identifies the source of the error. That's understood. It would be useful in case of problems that appear once a year, and look to be mysterious from the first view. Ugly is a taste-related comment, so it is hard to argument for/against it. As for error prone transportation, a screenshot solves this problem easily. The error-prone (and also the ugly, but let's omit that :) related to something else: When you transport the file/line information via the error message, then you need to strip it before you actually display the message to the user. I would consider this an essential requirement, from a user experience point of view. While it is helpful to you as a developer when somebody gives you a screeshot reading Access denied. foobar.cxx, line 134, it is certainly not at all helpful for the average end user who does not intend to send you the screen shot, but is happy with the Access denied message already. Moreover, it is not only not helpful, it will definitely (IMO) alienate the average end user. (Access denied might be a bad example, since this end-user message is probably generated from some error code, and not an actual exception message, but I hope you get the idea.) As a consequence, you *must* strip the file/line info before displaying the message, and this is what I called error-prone. (If I had a wish, I'd vote for changing UNO incompatibly, and adding a Stack member to the css.uno.Exception class instead. Oh, well, just dreaming :) By the way, the rework would take much more time, than the script adding the lines. From this point of view, it is better to let the script run and have at least the line numbers in the messages, than to dream how we change all the extensions in our office. s/extensions/exceptions/, I suppose? Well ... I hate to say that, but the approach you suggest is clumsy, in my opinion, for the reasons outlined above. And the argument We do not have the time/resources to make it right, let's do it the quick and dirty way instead is something which I hear too often (and suffer from too often, months or years later), for my taste. But okay, that might be only me. In any case, I *strongly* suggest you ask user experience what they think about slaying end users (who do not want to send you the screenshots) with file/line information. But even if all of them have messages ( thousands of unique messages? ), the filename and linenumber will stay the best unique identifier, as actually assertions prove. One other note: Did you try how this adds to library size, if all those exceptions are padded with additional strings? Don't want to say it's not bearable, just wanted to mention that you should keep an eye on this, too. Completely agree, we should. But again, I would not mix those two solutions.. See above. In my opinion, the one solution is not a solution, but a hack only :) [logging] This is a nice solution. It would help in our case, although the minus is that it has to be turned on before the problem happens. And some problems of the mentioned kind, are hardly reproducible. Reproducibility is a problem indeed. Seeing that our latest versions towards 3.1 have this OpenOffice.org improvement program feature, where user actions are anonymously logged, I wonder whether log all thrown exceptions is something which belongs to OpenOffice.org improvement, too. That is, if a user volunteers to let OOo collect data which helps us making OOo better, why not also logging the thrown exceptions then? Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Stephan, Even if there happen to be exception instances where the exception message is designed to be meaningfully presented to an end user (do you indeed use localized exception messages?) (yes, indeed, we do) this is not true for the majority of exception instances (where the exception message is something that can help a knowing person track down the problem, but not something that is meaningful for the average end user---for example, it is always in English). Which I'd consider a bug. If I run an arbitrary macro in Basic which uses the UNO API, any exception which is caught there is reported to the end user. Speaking techno-babble which is not meaningful (I tend to think that Basic developers still are allowed to be, though not necessarily are, average end users) is a usability issue, in my opinion. For the latter, I see no problem with augmenting the exception message with file and line information (other than the ugliness inherent in C/C++ macros). For the former, you should simply exempt those instances from Mikhail's wholesale macrofication, I would say. I suppose our fundamental question indeed is whether Exception.Message is an end-user feature, or a diagnostic means. If it's the latter, then file/line are well suited there - but it's this premise I doubt. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Get started
Hi Roman, Max already have you some pointers, but one note on the following: I using VisualStidio 2005, so could you help me to get started? As far as I know, VS2005's compiler is not supported for the current code line anymore. You should get an Express edition of Visual Studio (it's for free, and lacks some features, but those are not essential for OOo work). Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [releases] Re: [l10n-dev] Re: [releases] Re: [l10n-dev] changed strings in 310_m1
Hi Pavel,
We might have a communication problem. In my understanding, changing
resources so that the effective strings stay the same, but maybe
identifiers change, or strings are moved within files, or such, is an
alloed change.
string is and ordered set of: { actual string, identifier }.
If you change identifier, the string is changed.
Okay, this is completely new to me (and I bet I'm not the only one).
Apologies for the problems caused in OOO310.m1 then, and I'll know the
next time.
Ciao
Frank
--
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] changing the patch mechanism for external sources
Hi Ause, in the current scenario, there is only one active patch per source tarball which has to contain all required changes for the build. as discussed in issue 40246, this may lead to duplication and hard to maintain patches. with the changes done in the cws ause099, each change now will reside in its own patch. for the local module makefiles, the only visible change is PATCH_FILE_NAME - PATCH_FILES. this variable now hold the list (and apply prder) of the existing patches. That's great news indeed, it will make patch maintenance (and more importantly getting rid of patches) much easier. Thanks! Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] idlc warnings - why ?
Hi Oliver,
can one give me a hint, why i get warnings for the following *.idl files ??
...
module bw {
module stv {
module tvs {
module structedit {
module tool {
interface XGetSomething :
com::sun::star::uno:: XInterface {
string saySomething([in] string
_something);
};
};
};
};
};
};
I suppose both the warning are triggered by the underscore at the
beginning of the in-param. (one warning explicitly when compiling the
file, one warning implicitly when including the file in the service
definition IDL).
IIRC, this violates UNO naming conventions, though, admittedly, I think
the convention is bogus in this case :)
Ciao
Frank
--
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] RSS feed to EIS?
Hi Bernd, Well the fine grained control suggestes by you Frank is not as easy to implement as it might first look like: there´s lot of places where different kinds of changes to data in EIS is being made and each one would have to be reviewed and decided upon wether and what kind of mail users on such CC list should get when a change occurs. For example owners and QA Reps already get mails on status changes, so I suppose users on such a CC list should get them too except that for the situation that they are also the owner or qa rep than they should not get 2 identical mails for the event of course. And what about comments added would you want users on such a CC list to get email for that or not. And what about other minor important information like when somebody changed the location field of the CWS or just did set the flag that the CWS is help relevant would you want an extra email for that too or not and so on... We could *define* such a CC field as if you're subscribed here, *every* change is notified to you. Period. Finally, that's how other tracking systems (and I really think CWS data in EIS in this respect is pretty much the same as issue data in IssueZilla) work, too. As for the duplicate mails: I suppose making the set of reciepients unique immediately before sending the mail shouldn't really be difficult. With such a feature, we would have the subscribe for selected changes in all CWS - that's the RSS feeds, and the subscribe to all changes of in selected CWS - that's the CC list. So, something for everybody :). I of course would use the latter ... Btw. I'd also say that members of a CWS, as well as the owner/QA-rep, should be handled as if they were subscribed to the CC list. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Moving files in a Subversion CWS
Hi Bjoern, As an (ugly, very ugly) workaround for now, we might need a command in the cws tool that registers the moved files by their old name (the name it is known as on the master) somewhere. This could be either in a svn property (on trunk??) or in a administrative file somewhere. It should at least be noted, if changes to a file are wandering to /dev/null. Perhaps a postprocess hook which sends mails to EIS, keeping track of moved files, and issueing warnings upon integration when some change is about to be lost? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Moving files in a Subversion CWS
Hi Heiner, I wouldn't call for a complete ban but it looks like one has to be extra careful. Restructuring should be done in CWS which lives only a very short time. Best, say, opened on one milestone and integrated in the next (as first CWS) this would minimize the potential for data loss. I'd say that anything which does not *eliminate* the potential for data loss should be a no-go. Sorry, but I really do not like finding out short before a release (or even short after it) that some important fixes done during the last 6 months just silently vanished. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] RSS feed to EIS?
Hi Ariel, I'd like to keep truck of some CWS activities in EIS (well, mostly when they get integrated), are there RSS channels to this kind of info? I've been searching with no luck, so I guess there is none, but... I'd love to have some kind of CC functionality to EIS. That is, you can subscribe yourself to a CC list for a given CWS, and then all changes to this CWS are mailed to you. Pretty much how CC lists in issue tracking systems work. Would be most fine grained control over how many mails you get (only the ones you're really interested in), and should on the other hand be pretty simple to implement :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] RSS feed to EIS?
Hi Ariel, I'd like to keep truck of some CWS activities in EIS (well, mostly when they get integrated), are there RSS channels to this kind of info? I've been searching with no luck, so I guess there is none, but... I'd love to have some kind of CC functionality to EIS. That is, you can subscribe yourself to a CC list for a given CWS, and then all changes to this CWS are mailed to you. Pretty much how CC lists in issue tracking systems work. so this means: No there is no such a functionality. Uhm - well yes, I really wasn't too explicit here :) Would be most fine grained control over how many mails you get (only the ones you're really interested in), and should on the other hand be pretty simple to implement :) does this mean Please, file an issue? In that case, who owns that (component/subcomponent/owner)? Not sure if EIS RFEs are handled via IssueZilla, too. I'd say component=tools, subcomponent=??, owner=bei (Bernd Eilers). Usually, Bernd is reading here and picking up easy-to-fix ideas quickly, but an issue might help. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Moving files in a Subversion CWS
Hi Stephan, So, back to good old manual merging: Remember which files you moved in your CWS, and after every rebase, check whether they miss any changes to the original files. Sigh. With the additional hurdle that nobody will warn you about the lost changes. If the compiler finds them, that's fine, but if you just lose a small bug fix, then may not notice this at all. However, what worries me deeply is the [not] true data loss scenario upon svn merge --reintegrate described at http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html#svn.branchmerge.advanced.moves . A disaster waiting to happen, I would say. Or am I missing something? I tend to agree here. Just recently asked Heiner about this, and in my opinion, both scenarios effectively mean we should completely ban svn move, as it has a pretty large potential to silently destroy our code base. Which is a pity, as this is *the* feature of SVN which made it worth suffering the additional complexity introduced with it. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Build m37 breaks with HsqlDatabase.java:53: package helper does not exist
Hi Eike, Looks like connectivity/prj/build.lst needs a dependency on qadevOOo, or am I mistaken? You aren't, /me thinks. Feel free to write me a P1 issue, so we can fix this in the next build. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Build m37 breaks with HsqlDatabase.java:53: package helper does not exist
Hi Rene, Looks like connectivity/prj/build.lst needs a dependency on qadevOOo, or am I mistaken? You aren't, /me thinks. Feel free to write me a P1 issue, so we can fix this in the next build. but please guard this with an ENABLE_QADEVOOO or however it is caled variable so that it doesn't break when --disable-qadevooo is specified. Sure. And can such stuff please be communicated? Which such stuff? Assuming that I didn't introduce the build breaker intentionally, the conclusion is that I simply wasn't aware of the fact that connectivity did not yet depend on qadevOOo, and that I forgot to check this. That said, there was nothing to announce, since I can't announce what I am not aware of. So, what do you refer to here? Or is it that you don't share the above assumption? TIA Whatever that means. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Who can closes an issue[ was: Fwd: [l10n-dev] Spanish version : issue in OLH
I find it very abnormal that the person who shoots an issue can't close it. abnormal is a somewhat strong word :), but yes. I suppose the ability to resolve/close issues is bound to the canconfirm privilege - which users don't initially have, instead they need to apply for it. Sadly, we don't really have control over IssueZilla, so it's effectively impossible to change/enhance IZ's permission system. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] SVN and lineends
Hi, modifying a .cxx file on Windows, and committing it to SVN, followed by a svn diff -r PREV file, shows me that *the complete* file changed with the commit. Doing a svn diff -r PREV -x --ignore-eol-style file shows me only the changes which I just did. Conclusion: We have a problem with our line endings - we certainly do *not* want to have a thousands-line-change-set for every file we modify/commit on Windows, do we? Shouldn't we set to svn:eol-style property to a reasonable value (native, probably) for all our source files, globally? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN and lineends
Hi Heiner, Let me hear your thoughts. Should we go to svn:eol-style native? For which file types? Or should we stay with Unix and require that people use editors which preserve the line end conventions? Is that even possible for the more popular editors (I use vim, so I wouldn't know). This requirement can hardly be fulfilled, I assume. At least not without alienating a lot of developers. For instance, there is (AFAIK) no such option in Microsoft Visual Studio, and I would *hate* to switch between two applications when debugging/editing a source file. For the file types, I'd be happy with an initial list containing .cxx .hxx .src .hrc .txt .mk .pmk .java .cpp .h. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Subversion precommit hook
Hi Björn, Given that pre- and postcommit hooks are basically working the same, using this precommit hooks as a base to create a postcommit hook should be easy. See issue 95199 for my currently prepared (and already implemented) solution, though a post-commit hook also sounds interesting. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Subversion precommit hook
Hi Bjoern, I just tried to add an svn:ignored dir. That works. Sure - svn:ignore is just for ignoring the item in status and recursive commits. If someone does a svn diff in a module, and sees: ? source/somenewfile.cxx ? source/somenewfile.hxx he might be tempted to do a 'svn add *; svn ci -m my message' and goes to grap a coffee. When he returns he has happily commited the output trees. That seems kinda dangerous to me. Well, admittedly the intention for my svn:ignore request was never to prevent people from committing them. As I wrote in my original mail, it's about the noise produced by svn status which bothers me. (For instance because I usually check my CWS for uncommitted files before passing it to QA or finally deleting it). If somebody really commits an output tree, we can still a) shot her and b) do an svn delete (which nowadays is much easier than fixing the same problem in CVS would have been.). If we svn:ignore output trees, we should also prevent them from being commited (if we have a list of platforms that are svn:ignored, we could also specifically look for those in the precommit hook). I am undecided here. If you wish - do it. It might be harder to achieve, as it requires people to update the script when new platforms are born, and in opposite to updating svn:ignore, that's nothing an ordinary developer can do. BTW this is just as dangerous when having the output trees in global ignore in the config. I never claimed to invent the idiot-proof solution :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] SVN-ignored files
Hi, now that we start working with SVN-based CWSes, those module output trees (common[.pro], unxlngi6[.pro], wntmsci12[.pro] etc.) become somewhat inconvenient, as they clutter your svn status output, for example. http://wiki.services.openoffice.org/wiki/OOo_and_Subversion#Ignoring_output_trees discusses this, and suggests to add those names to the global ignore list, claiming this is better than adding them as per-directory property. I beg to disagree, for the following reasons: The global ignore list applies to each and every location in the source tree, where we actually want to ignore those output trees only in the module directories. So, using the global list is overkill, and makes using files/folders, which match the respective pattern, in other locations unnecessarily difficult. Second, using the global ignore list for that purpose is something which everybody needs to do for himself (and for those of us working on different Windows machines without roaming profiles, it means doing it on every machine). Third, The Book, in http://svnbook.red-bean.com/en/1.5/svn.advanced.props.special.ignore.html, has a sentence which also suggests we should use svn:ignore instead of the global ignore list: The global list of ignore patterns tends to be more a matter of personal taste and ties more closely to a user's particular tool chain than to the details of any particular working copy's needs. Surely the our output tree names/locations are a facet equal across all working copies, so we should address the issue in the repository. In short: Can we please add the platform-dependent output tree names as svn:ignore property to all modules? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN-ignored files
Hi Heiner, On 10/16/08 11:00, Malte Timmermann wrote: In short: Can we please add the platform-dependent output tree names as svn:ignore property to all modules? +1 +1 -1 I tried to explain why I think the property-approach is better, please also elaborate why you think it isn't. Just saying no without explaining why has a small taste of ... dictatorship. (And the only your argument I saw so far, on the Wiki page, is it's clumsy, which isn't really convincing.) Thanks Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN-ignored files
Hi Heiner, Well, this +1 or -1 one in s a kind of vote and you normally don't have to explain your votes. Note that I didn't say We will not do this, I'm the maintainer of this stuff, basta! :-) Just a vote. Ah, okay ;) These are roughly 50 platforms times 191 top level dirs, about 9550 entries to maintain. That I call clumsy. Since most of the platforms are only interesting to a few people I feel that having this in the so called global ignore list might not be unreasonable. (Didn't know we have that much platforms ...) Well, every time we switch to a new compiler on a new platform (which happened quite some times in the younger past), every developer working on the respective platform has to adjust the global ignore list in his Unix Home, and in $(APPDATA)\Subversion on each and every Windows machine he's regularly using. Multiplying all those developers with all those profiles probably does not sum up to 50*191, but in opposite to maintaining the SVN property (which can be done by simple scripts), maintaining the config files is manual work. So, I still think putting the stuff into SVN is better ... (Hey, what did we do the migration for if we don't use all the cool new SVN features?) ... at least for the *most common* platforms - what the *#+%$# is unxhpxr? And how many people will ever encounter it in real life, compared with unxlngi6, unxmacxi, and wntmsci12? As for I can't use the platform names in the ignore list readily: Well this is a good(TM) thing. You should not use this names, they are reserved for the build process. Well, yes, sure. Except that the ignore list you suggested in the Wiki also excludes files like common_data.txt ... Also, the reservation of those names only is true for the module root folders (i.e. the location where the prj sub folder resides), not for other locations. At least this would be my understanding, though you could say that the names are (by definition) reserved globally, and I'd easily accept that. If you insist on using them, well there is always the --no-ignore switch to svn add, or you just explicitly add a path with this name. Once a path is under version control the ignore list has no effects anyway. I know (I meanwhile read the FM :) - I intentionally wrote makes it difficult, not makes it impossible. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN-ignored files
Hi Heiner, [...] Well, you probably already noticed that I'm somehow not very enthusiastic about maintaining these 1 entries. Remember, you'll have to add the properties every time someone invents a new top level directory, which means with most milestones. We have 191 modules so far, and certainly *much* more milestones than 191, so the most is surely exaggerated. And you have to change all 200 of them if someone adds a new platform. But if someone volunteers for this task I won't veto it. Oh, and it can easily be introduced by a CWS, so no Releng is needed for this :-). Sigh. I'll take the list of platforms you mentioned (is it complete? Is it correct), and Just Do It (TM). Finally, this will give me a chance to practice my Perl, and (more important) to play a little with SVN, which is still pretty new to me. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: testautomation the effects on the CWS process
Hi Thorsten, I know that developers want to start it from the command line. Well, developers want a way to easily judge the quality of their work. I don't care whether testtool can be run from command line, it's just the environment I'm used to ... If you give us a possiblity to run testtool scripts by pressing a button in a web front end - well, fine (for now, until we have the all-in-one-QA-solution we recently talked about :). So, please consider make a tool to well, do something. In the majority of cases, it's currently used to compile and build and link and ... But there's no technical reason it cannot be used to run tests, all kind of tests, that is, including UI tests. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCS Keywords in License Headers
Hi Heiner, Yes, this can (and should) be done by RE, if we decide drop the VCS keywords. Most probably not m33, but at some time in the near future. would be good. Another huge change which could be done in the same milestone is to convert tabs to 4 spaces, something I know Kendy and some others are advocating. Uhm - but this will *certainly* give *a lot* of resync conflicts, won't it? As much as I am for having spaces instead of tabs, the trouble we would get with such a global conversion is not worth it, IMO. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCS Keywords in License Headers
Hi Heiner, 'svn merge -x -b' is your friend ... You mean ... I really should go reading this Handbuch? :) Could be done, and the earlier the better I guess. As long as we still have CVS-based CWS'es, which need to be migrated ... not sure. Finally, migration will probably usually happen by create a CWS in SVN, based on the latest milestone, and *patch* in the changes of the CVS-CWS. In this case, svn merge is of no help. Instead, it would require people to create the SVN-CVS on an pre-tab-replaced-by-spaces-milestone, then apply the patches, then lift the SVN-CWS to a post-tab-replaced-by-spaces-milestone. Not a good workflow, IMO. So, if we really want to do this replacement, I would do this only when we can really rely on the power of svn merge being available in all cases. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCS Keywords in License Headers
Hi Heiner, As long as we still have CVS-based CWS'es, which need to be migrated ... not sure. Finally, migration will probably usually happen by create a CWS in SVN, based on the latest milestone, and *patch* in the changes of the CVS-CWS. In this case, svn merge is of no help. Instead, it would require people to create the SVN-CVS on an pre-tab-replaced-by-spaces-milestone, then apply the patches, then lift the SVN-CWS to a post-tab-replaced-by-spaces-milestone. Not a good workflow, IMO. So, if we really want to do this replacement, I would do this only when we can really rely on the power of svn merge being available in all cases. The trick would be to migrate CVS stuff to a SVN based branch @m32 and then rebase with svn merge to something newer ... = problem solved. Yes, that's what I tried to describe above - it's a two step migration of the CWS, instead of a one-step one. I don't have a feeling for working with SVN, yet, so I cannot judge whether this is really a big overhead. Not to mention that even if it isn't, people will forget it's two-step instead of one-step ... Finally, I wouldn't do everything now and immediately, just because it could be done easily. Let's just get this SVN migration done (and I'd consider it done when people *halfway* know how to use it, and when no CVS-based CWS for DEV300 exist anymore), and then let's start with something else - like tab replacement. Doing too much at the same time just makes life unnecessarily difficult. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCS Keywords in License Headers
+1 for the proposal +1 Is this something which can/should be done by release engineering, for instance with the switch from m32 to m33, globally? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] STL Implementations clash
Hi Andrey, I am writing an OO.org extension that is a thin wrapper around a C++ library, which is compiled externally. I think the latter is the problem - you need to compile the library within the same environment as you compile OOo, in particular against STLPort. Note that that's a requirement before releasing the final version of the extension, anyway: Since the library will to be part of your extension, anything except compiling both with the very same settings would open the door to too much compatibility problems. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] help sought: building moz2seamonkey01 on Windows
Hi Christian, What I am looking for is a volunteer who could do the Windows build the CWS moz2seamonkey, including the Mozilla-build (i.e. without the above-mentioned configure-time switches which effectively disable it). If this said volunteer could work with Pierre/me to solve any problems which might appear during the build, this would be even better, if course :) I could build that CWS on our Windows buildbot. All I have to do is fiddling the configure parameters...(because Mozilla is imho disabled per default on that Bots). I'll buy that one then, thanks. (I admit I had hope that some of the people saying please replace the stone-aged Mozilla code with something new would step in :) I think I'll stop by your office for the details Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] help sought: building moz2seamonkey01 on Windows
Hi Rene, (I admit I had hope that some of the people saying please replace the stone-aged Mozilla code with something new would step in :) Not on windows, no :) :) We're glad about any help on the other platforms as well. Currently, Pierre does Linux, and Eric builds on Mac (and /me has to find the time for Windows). Any helping hand on other platforms (and probably even on the same platforms, with some other compilers or the like) is appreciated. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Basehttp://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sitz der Gesellschaft: - - Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten - - Amtsgericht München: HRB 161028 - - Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer - - Vorsitzender des Aufsichtsrates: Martin Häring - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] the NEW STYLE service may import great complexity to implementation.
Hi Juergen, Hoping to see your marcos soon~ hehe. i am not fan of macros and the skeletonmaker can be already used for both (declaration and forwarding). I think it is no real overhead and changes are not so often. Which is merely wrong - in case we're talking about API which is currently being developed. In such a situation, I often come across new facets of the problem which require the API to be adjusted (yes, this might be a deficiency of mine - finally, one should be able to first design properly, and then implement, right? :) About the overhead: Feeding skeletonmaker with the type library path and the like arguments is not really fun. Doing this *every time* is *definitely* overhead compared to typing DECLARE_XFOO just *once* in the header. I agree that it would be or can be smart for the developer but not for people who wants to read/understand Hmm? What's difficult to read about DECLARE_XFOO or FORWARD_XFOO? or debug the code later on. Every decent debugger has a step into feature. Applying this to a FORWARD_XFOO line in the header is not much different from applying it to an explicit forwarding in the .cxx file. Anyway i will think about it ... This is also what you said last time I brought up this idea/request :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] the NEW STYLE service may import great complexity to implementation.
Hi Juergen, This is also what you said last time I brought up this idea/request :) really, maybe you should submit a feature request ;-) Ah, you caught me, Go visit IssueZilla! is usually the response *I* give to *others*, not the other way round :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] deliver's verbosity
Hi, just noticed that in m18, deliver isn't as gossipy as before: doing a deliver in a module just prints deliver -- version 1.127 Module 'module' delivered successfully. x files copied, y files unchanged. While this is nice in contexts where you are not interested in *what* got actually delivered, it seems there is no way to revert to the old behaviour: deliver -help doesn't list an option to be more verbose (though it lists deliver -quiet, which does the same as deliver, funnily). I find this unfortunate, since I sometimes indeed want to know what's going on, and would be *really* interested which files were actually delivered. Is there an option I missed? If not, is there a possibility to introduce one? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] deliver's verbosity
Hi Caolan, deliver -verbose also works That's the one I was looking for ... well, I could have thought of this, couldn't I? Thanks Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Where to find cvs tag for the three-layer patch?
Hi Jan, I assumed it would live in cws_dev300_sb83, but I get cvs -d :pserver:[EMAIL PROTECTED]:/cvs co -r cws_dev300_sb83 framework/desktop cvs [checkout aborted]: no such tag cws_dev300_sb83 How do I find the right tag to generate the patch? The CWS sb83 was created on SRC680, so the CVS tag is cws_src680_sb83, since it is nailed down at creation time of the CWS, and never changed. *) This patch broke the layout engine's test program and looking at the patch may give me a clue as to why UCB won't initialize. Stephan is on vacation ATM, but I seem to remember he recently fixed a number of issues related to various tools not working in the 3 layer office. Those fixes are in CWS sb87 AFAIK, which is in QA. Perhaps you want to check your test program in this CWS before diving deeper into sb83's changes. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCL UI Rework
There was some resistance to nominating this for 3.0 because ChristianL wanted to re-do the translation work to use Java Properties instead of the new transex tool we wrote that translated complete XML files per-lang. This is bogus, I discussed with Jan that in my opinion it is a cleaner solution to use the Java Properties file for translation as I think the current way of doing it does not fit with the OOo translation database and tooling. Other than than, having one one XML file per language sounds pretty wasteful to me. *Maintaining* different versions of the same dialog for different languages is certainly a no-go, since they would soon get out-of-sync. And if we automatically create (by whatever means) different-language versions from one master XML file, then I don't see a reason why this should/could not be done at runtime, instead of compile time. Which implies we need to separate the UI description from the translation - and here Java Properties files are an established concept which has proven to work, and even already has an implementation in OOo. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OO.o 3 - it does not register file extensions
Jacek, I have been testing OO.o 3.0.0 since DEV m3. I noticed that starting from m10 installation program does not register file extension in the system and it is impossible to open any document file just by double-clicking on it. The same applies to both BEA m1 and m2 versions. Somebody else in some other list (forgot who and where) suggested to do a setup.exe WRITE_REGISTRY=1 - this will also do the file associations during setup. The associations have been intentionally disabled, AFAIK, to not let the Beta conflict with an existing OOo installation. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] List of 2730 uncallable methods in DEV300_m10
Hi Caolan, See http://people.redhat.com/caolanm/callcatcher/DEV300_m10/ for full list. Top three offenders are... sorry for the dumb question, but what are uncallable methods? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] The evil that is cppu::getCaughtException
Hi Stephan, And all this weird code in except.cxx is only necessary because our C++ UNO exceptions do not make plain C++ RTTI available (see Frank's post)! This got me thinking: What about actually changing the C++ UNO binding, conditionally for _MSC_VER = 1500 only, for OOo 3.0, by adding a virtual destructor to com::sun::star::uno::Exception? Well, as much as I'd appreciate RTTI for our Exceptions, doing this on one platform only is pretty dangerous. People developing on this platform might be tempted to use RTTI outside of getCaughtException, and such code will *silently* fail on other platforms. IMO, this is a predetermined breaking point - if not now, then next year, or the year after, for some new developer not knowing the backgrounds. So, for the sake of code quality, I'd give a -1 to this. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] The evil that is cppu::getCaughtException
Hi Stephan, I do not see any elegant solution for this problem. Potential but ugly solutions would include: All are ugly, aren't they ... Judging from myself: I first got introduced to ::cppu::getCaughtException when I tried to dynamically determine the type of the caught exception in an catch( const Exception e ) block - which was impossible, since RTTI doesn't work with our exceptions. I could easily live without getCaughtException, *if* there was another means getting the same functionality. I think I could hardly live without it - it makes a certain class of code much easier to write and maintain, and less error prone. - Remove all calls of the---dangerous anyway---cppu::getCaughtException from the OOo code base (http://lxr.go-oo.org/ident?i=getCaughtException lists 245 references in 102 files). See above. If we make the C++ UNO binding incompatible, in that we add some polymorphism to the Exception class, so RTTI works, then I'd be fine with that. - Make sure the relevant compiler runtime libraries will always be installed system wide when running OOo. (This had been discussed before, but dismissed.) This is what I consider the only viable option. - Use only compilers for which runtime libraries need not be installed either syste wide or next to every DLL that uses them (e.g., older Microsoft compilers, or GCC). Unrealistic. - Turn the Three Layer Office back into a Two Layer Office, where the URE and Basis layers are united (and the above scenario would again only use one instance of msvcr90.dll loaded into the process, and everything would probably work fine; there is also an instance of msvcr90.dll in the Brand layer, but that should not interfere with any cppu::getCaughtException calls). Well ... I suppose there's a reason why the three layer architecture was introduced ;), so this is probably not an option, too. Other than that - is there really *no* possibility to teach shared libs where to load the runtime libraries from? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Update: Removing external header guards
Hi Thorsten, Frank Schönheit - Sun Microsystems Germany schrieb: I'm all in for somebody else doing work :), and I do not doubt that it is *reasonable* to remove external include guards /in general/. I only suspect that the minor gain we get from this is not worth the potential medium or big pain it will cause. Frank, are your objections still valid? I still hope to be wrong in assuming that this will cost us a lot of work in resyncing, but well ... My CWS which did the most changes in this area is meanwhile integrated, the other open CWS'es don't touch that much of the includes, so go ahead Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Update: Removing external header guards
Hi Thorsten, With dbaccess as well? Yes. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] uno controls can not persistence the invisible status
Hello Jianhua, Create a uno control in Calc, and make it invisible by Basic, Save the docuemnt, and then reload it, the uno control still visible. This because ODF do not support this property. does we have any plan for supporting this feature? No plans. Note that for consistency, one would need to introduce a *model* property Visible, which then is respected by the *control*(s) which belongs to the model. This is the way it works with other properties, for instance Enabled. Also note that this is not absolutely straight-forward: Visibility is used for some other purposes, too. For instance, when the document with the controls is in form control design mode, then all controls are invisible (as you could easily check with an oControl.isVisible from Basic). In UNO dialogs, which use pretty much the same control implementations, visibility is set automatically according to the Step property of the dialog, which allows implementing wizards. So, if we really had a Visible property at the control model, then high care had to be taken to properly merge this explicit visibility flag with implicit visibility flags. All that said, I am not sure whether an explicit visibility flag makes sense. Can you describe use cases where you think you need it? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] RFC: java 1.5
Hi Hubert, I don't know if you have noticed, but they are been several request from people to have OOo ported to embedded devices like Maemo and iPhone, for which Java is likely to be an even bigger problem. Come on. When we ever port OOo to one of those platforms, Java is one of our smallest problem. For the concrete case, this means that any other third-party library we could use will most probably also not run on those platforms. So effectively, you say don't use third-party libraries. So without judging the concrete case, the argueing with possible future ports to platforms without Java is simply not a valid point, IMO. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Removing external header guards
Hi Thorsten, I cannot imagine changes to OOo code that do not potentially cause pain someone somewhere. The thing is, it's a change for the better, removes a ton of unnecessary, fragile hard to maintain code, and there simply won't be a better time for this. Sure. Again: The question is whether the gain is worth the pain. Personally, I somehow doubt it. Are you suggesting to do this incrementally? In which way would that help, for the individual developer, who needs to resync one or more CWSs against the inevitably changed include portion of her files? The developer has better control. If I touch includes in any file of any module of any CWS, and have to resync to the big-bang-MWS (the one containing incguards01), I will almost certainly get a conflict. This happens for all people touching any include in any file of any module of any CWS. If I touch includes in any file of any module of any CWS, and let the script run immediately before I pass the CWS to QA, then at least for this particular CWS, and this particular module (more precise: all files in this module where I tampered with the includes), I will not have conflicts. IoW: There's a little less pain. Still, I am unsure whether the reduced pain is worth the gain. But if we minimize the former, I'd perhaps be willing to sacrifice this uncertainty to the higher abstract goals of removing some uglyness ;) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Removing external header guards
Hi Nikolai, The uglyness IMHO is not subjective, and a defect. Maintainability is a major problem in any project as huge as OOo, Sure. - unnecessary code Which is true for a lot of other places, too. I usually fix those incrementally :) - a potential cause for difficult to find errors, when internal include guards change. If an internal include guard changes - this only means that the external include guard does not apply anymore (i.e. the #ifndef evaluates to false), so the file is unconditionally included, effectively. Where's the difficult-to-find error here? I think we should welcome the opportunity that somebody is willing to do this work. I'm all in for somebody else doing work :), and I do not doubt that it is *reasonable* to remove external include guards /in general/. I only suspect that the minor gain we get from this is not worth the potential medium or big pain it will cause. That's why I still think the all-in-one thing is not the best approach here. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Removing external header guards
Hi Thorsten, kendy and me now intend to execute the once-postponed plan to remove external header guards (that #ifndef STUFF #include STUFF #endif ugliness). A bit more background: http://blog.thebehrens.net/2008/02/05/obsolete-external-header-guards/ We already discusses this a little bit by PM, so you know I have to ask this here :) What, except removing some ugliness, which is alway highly subjective, is the gain of this change? I suppose there will be some pain in all CWS which are resynced after the integration of incguard01, so IMO we should have some good reason to do this change. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Any workaround for auto file extension always on?
Hi Mathias, Sounds like the decision to remove the box was perhaps ... premature? No, just the way it was done is wrong. We should do it the following way: if the file name contains something that looks like an extension, leave it alone. If it doesn't contain a dot, add the extension. This simulates the automatic removal of auto-extension for all names containing dots. This implies that if your file name contains a dot, you need to specify the desired extension automatically, where previously you could rely on OOo adding it. That is, in 2.3 you could save a file foo.bar with AutoExtension=ON, the it became foo.bar.odt. If you really wanted foo.bar, you could turn AutoExtension OFF. With the current behaviour, it is impossible to save as foo.bar. With your suggested behaviour, it requires to enter foo.bar.odt if you really want this name. Which is okay for a foo.bar case, but will probably be forgot for a file name like Letter to Mom, 1.3.2003 - that is, if in your file name, you use dots as part of other non-extension text. So, with the AutoExtension option, there's a trap for a certain class of users. Without it, there's a trap, too. I am uncertain, actually, which one is worse. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] REMINDER: use specification templates for specifications
Hi Bernd, Well yes it´s a rather simple algorithm and well normally your expectation would be right that in this case the text from the first paragraph of the abstract would be used. But well here it´s special. The spec document has been changed in a way that the abstract can not be extracted anymore because ... Okay, but in general re-using specifications (which IMO makes a lot of sense) means the generated release notes are wrong, correct? Looking into the allfeatures mailing list (did I already say kudos to you for working around collab.net's bug, so this list now works, again?), of the last 10 feature mails, 8 contained a specification link, where 5 referred to older-and-extended specs (including the broken one). Means that half of the auto-generated release notes is wrong. Hmm, we should improve on this. I suppose that *first* using the mail, *then* using the spec, as already suggested here, could help. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] automatic release notes (was: [dev] REMINDER: use specification templates for specifications)
Hi Bernd, Looking into the allfeatures mailing list (did I already say kudos to you for working around collab.net's bug, so this list now works, again?), of the last 10 feature mails, 8 contained a specification link, where 5 referred to older-and-extended specs (including the broken one). Means that half of the auto-generated release notes is wrong. Interesting argument. Let me make it even more interesting. (Side note: There's one new feature mail since some hours ago, which leads to 11 mails, 9 with spec link, 5 referring to old/extended specs.) Of the 4 last postings which contained a link to a newly written spec, the following are the first paragraphs of 2 of them: The support for regular expressions is extended by “backward references”. This specification documents changes made to the Calc options dialog. Which adds to: Of the 11 most recent feature announcements, the take the abstract from the spec-process will produce wrong or only-slightly-useful descriptions in 7 cases. Well the *then* using the spec is kind of not really an option. ... I see. To me this means we should get rid of the spec-abstract thingie. I suggest a feature mail contains a release note abstracts field and a comprehensive description field. EIS should distinct them both in the UI, when writing a mail. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] REMINDER: use specification templates for specifications
Hi Bernd, Just have a look at http://development.openoffice.org/releases/2.3.0.html to get an impression, these are the actucal release notes for the 2.3.0 user Release. And that´s the result of what we currently semi-automatically generated for the 2.0.3 Release by parsing (or not being able to parse) specification documents. Out of curiosity: What will the automatisms do with http://www.openoffice.org/servlets/ReadMsg?list=allfeaturesmsgNo=3270? It has become a habit (rightfully so) to extend existing extensions when the respective feature evolves, and to put the URL of the complete specification into the feature mail. Does this mean our release notes will contain the abstract of the complete specification? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VOS removal
Hi Philipp, while I`d generally agree, there is the infamous Solarmutex of vcl which is a derivative of the vos::IMutex interface and needs that to do refcounting. I don`t think sal`s Mutex class has virtual methods. Of course you could move that interface out of vos to vcl, if the SolarMutex is the only instance left that actually needs that derivation. Oh, please let's do it. The VOS mutex had the advantage of being able to, for instance, add additional code in non-product builds to find code with wrong locking behavior. I miss this from the very time we moved to the OSL mutex ... Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: remove dead corpses from so3
Hi Mathias,
Perhaps we should follow up on this elsewhere.
You're right, issue 81309 is not the proper place. [EMAIL PROTECTED] might be
better.
The problem is when people use code without asking its owner (if someone used
so3 without asking me or mav that would be the case)
Come on. We used the Paste Special dialog from so3. You are not going to
say that if somebody uses a helper class from
unotools/comphelper/svtools/whatever, he must ask the owner of that
module/code, are you? And if not: What's the difference between so3 and
svtools? And, more important, how is the ordinary developer to know this
difference?
No, sorry, ask the owner of the module before using helper code
exported by this module is no valid concept.
or when people make big
changes like the ResMgr change without really having a strategy to find all
the
pitfalls and without a comprehensive testing.
I don't think testing would have been a help here. After dealing with
the topic, I think Paste Special in Base might have been the only
place where the problem struck.
Also, I doubt Philipp didn't have a strategy, though I admit that in
this special case, he could have found the problem with a little more
digging. Nonetheless, if we wouldn't have this dead code, there would
have been no need at all to invest the time ...
There is no difference between so3 and binfilter.
In fact there is. binfilter contains code used for the binary filters,
and only such code. And this is a pretty well-known fact. For so3, this
isn't known (I'd claim).
I'd even bet we didn't have a chance of knowing this. Has there been an
API changes mail module so3 is deprecated? Can't remember having read
it ... which is one more reason why I regret the fact API changes are
out of fashion nowadays. Nobody has a chance knowing what's going on on
such a low level. We're lucky if we know what features were implemented
in the other applications, but we can't know what code exists in our
application, even if this would be of great interest to all core developers.
Both are modules only used to
load and save old binary files. As you write you don't care about the size of
binfilter I don't know why you care for the size of so3.
I don't care (too much) for the size. As I tried to explain in the
issue, I care for dead code lingering around, producing effort in later
API chances, and offering pitfalls for the people who do not know its dead.
I don't know why base crashes due to problems in so3.
Because it uses a dialog which is loaded with a NULL-ResMgr.
I didn't check this in CVS, but I assume it was like this: The code to
use the dialog was introduced a few years ago, but existed in a CWS
only. With moving dialogs into a load-on-demand library, the dialog was
duplicated in CVS, but not removed from so3. Also, there was no API
changes mail saying Don't use this dialog from so3 anymore.. So, all
went fine. Until the ResMgr change happened, which unfortunately, in
this particular case, caused all resources in SO3 to be constructed with
a NULL-ResMgr, which isn't valid anymore.
side note: If the man who did
ResMgr* SoDll::GetResMgr()
{
// resources are in the default res mgr (OFA)
return NULL;
}
would have done this change - from an own SoDll::pResMgr to the OFA res
mgr - *properly*, and would have removed this function, together with
all - unused for years - .src files in the module, then we wouldn't do
those long discussions years later. But alas, a simple return NULL
probably was considered the easier and faster solution.
This fast solution is one reason why Edit/Paste special crashes in
2.3/Base. I continue to think it would have been worth the effort to
implement the real solutions instead of the quick ones, in all places
which contributed to this crash.
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: remove dead corpses from so3
side note: If the man who did
ResMgr* SoDll::GetResMgr()
{
// resources are in the default res mgr (OFA)
return NULL;
}
would have done this change - from an own SoDll::pResMgr to the OFA res
mgr - *properly*, and would have removed this function, together with
all - unused for years - .src files in the module, then we wouldn't do
those long discussions years later.
Hmm, at least here I was too fast. Thinking more about it, the
possibility to keep this hack (implicitly delegate to the OFA res mgr by
having an own NULL res mgr) in a central location was a good idea, in
general.
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: the issue about the programme freezed when switch to another input method
Hello Du Yunfen,
one thing beforehand: Great to see you think I'm the right person for
this kind of problem :), but actually this touches code areas which I
barely know. Thus, I think this discussion is best continued at
[EMAIL PROTECTED] I send this mail to the list, and would like to ask
you to reply to the list, too.
Further comments inline (and full quote for the new readers).
Hi, Mr Schönheit
It's still on the issue mentioned last time.
the operation steps as follows:
.create a new writer(or base ,calc ,draw ...).
.click view-datasource.
.choose a local datasource of nodes ,connect.
.activate the context.
.switch to another input method .
then the application will freeze.We had Tracked the threads and I found
when it is freezed, the application is still
activated in the thread *[3640]rtl_cache_wsupdate_all* and always in a
cycle which is in ../sal/source/rtl/alloc_cache.c :
rtl_cache_wsupdate_all (void * arg)
{..
while (!g_cache_list.m_update_done)
{ ..
}
},
and
This doesn't tell me anything, sorry.
in the thread *[3888]desktop::GetURL_Impl*, the programme run to
ERROR_MORE_DATA in osl_acceptPipe(oslPipeImpl * pPipe=0x02dec57c) which
in ../sal/osl/w32/pipe.c.
So I want to know what are modules( *sal* and *vos* ) used to achieve
and the possible contact between switch the input method and connected
a local datasource ?
I don't know ... sal is the system abstraction layer, vos is some
older code for low-level system independent stuff, where nearly
everything in vos has a modern replacement in sal or osl.
Thanks.
Best Wishes.
duyunfen
ps: the threads:
[3100]WinMain
ntdll.dll!7c92eb94()
user32.dll!77d194be()
user32.dll!77d1b42d()
user32.dll!77d184fc()
user32.dll!77d185a4()
user32.dll!77d1b3f9()
user32.dll!77d1b393()
vcl680mi.dll!SalFrameWndProcW(HWND__ * hWnd=0x001008e4, unsigned int
nMsg=80, unsigned int wParam=1, long lParam=-534640636) Line 6060 + 0x16 C++
user32.dll!77d18734()
user32.dll!77d18816()
imm32.dll!7630e489()
user32.dll!77d1f805()
user32.dll!77d189cd()
user32.dll!77d18a10()
vcl680mi.dll!ImplDispatchMessage(const tagMSG * lpMsg=0x0101f698) Line
200 + 0xa C++
vcl680mi.dll!ImplSalDispatchMessage(tagMSG * pMsg=0x0101f698) Line 716 +
0x9 C++
vcl680mi.dll!ImplSalYield(unsigned char bWait='', unsigned char
bHandleAllCurrentEvents=0) Line 746 + 0x9 C++
vcl680mi.dll!WinSalInstance::Yield(bool bWait=true, bool
bHandleAllCurrentEvents=false) Line 791 + 0xd C++
vcl680mi.dll!Application::Yield(bool bAllEvents=false) Line 554 C++
vcl680mi.dll!Application::Execute() Line 516 + 0x7 C++
soffice.exe!desktop::Desktop::Main() Line 1803 C++
vcl680mi.dll!ImplSVMain() Line 255 C++
vcl680mi.dll!SVMain() Line 296 C++
soffice.exe!sal_main(int __formal=1, int __formal=1) Line 82 C++
soffice.exe!WinMain(void * _hinst=0x0040, void * _dummy=0x,
char * _cmdline=0x00051f0a, int _nshow=1) Line 74 + 0x39 C++
soffice.exe!WinMainCRTStartup() Line 390 + 0x1b C
kernel32.dll!7c816fd7()
ntdll.dll!7c935b4f()
This thread *might* be part of the problem, since it seems that
dispatching a message blocks for whatever reasons. However, I don't know
enough about that kind of stuff.
[3640]rtl_cache_wsupdate_all
ntdll.dll!7c92eb94()
ntdll.dll!7c92e9c0()
kernel32.dll!7c8025cb()
kernel32.dll!7c802532()
sal3.dll!rtl_cache_wsupdate_wait(unsigned int seconds=10) Line 1450 C
sal3.dll!rtl_cache_wsupdate_all(void * arg=0x000a) Line 1547 + 0x9 C
kernel32.dll!7c80b683()
[3956]oslWorkerWrapperFunction
ntdll.dll!7c92eb94()
ntdll.dll!7c92e9c0()
kernel32.dll!7c8025cb()
ntdll.dll!7c946abe()
kernel32.dll!7c802532()
sal3.dll!osl_waitCondition(void * Condition=0x0f48, const
TimeValue * pTimeout=0x03d7ff54) Line 112 + 0xe C
vos3MSC.dll!vos::OCondition::wait(const TimeValue * pTimeout=0x03d7ff54)
Line 75 + 0x10 C++
vos3MSC.dll!vos::OTimerManager::run() Line 492 + 0x14 C++
vos3MSC.dll!vos::threadWorkerFunction_impl(void * pthis=0x02de6eb4) Line
50 + 0xc C++
sal3.dll!oslWorkerWrapperFunction(void * pData=0x03313eb0) Line 81 + 0xd C
msvcr71.dll!63fb9565()
ntdll.dll!7c946abe()
kernel32.dll!7c80b683()
ntdll.dll!7c946abe()
[3888]desktop::GetURL_Impl
ntdll.dll!7c92eb94()
ntdll.dll!7c92e9c0()
kernel32.dll!7c8025cb()
ntdll.dll!7c92fb6c()
ntdll.dll!7c92da69()
kernel32.dll!7c802532()
kernel32.dll!7c831608()
sal3.dll!osl_acceptPipe(oslPipeImpl * pPipe=0x02dec57c) Line 418 + 0x17 C
vos3MSC.dll!vos::OPipe::accept(vos::OStreamPipe Connection={...}) Line
232 + 0xf C++
soffice.exe!desktop::OfficeIPCThread::run() Line 575 + 0x13 C++
vos3MSC.dll!vos::threadWorkerFunction_impl(void * pthis=0x02e0a804) Line
50 + 0xc C++
sal3.dll!oslWorkerWrapperFunction(void * pData=0x0330e778) Line 81 + 0xd C
msvcr71.dll!63fb9565()
kernel32.dll!7c80b683()
soffice.exe!desktop::GetURL_Impl(const String rName={...}) Line 2786 +
0xd C++
soffice.exe!desktop::GetURL_Impl(const String rName={...}) Line
