Re: [dev] Create a blank chart in OpenOffice
Hi Houh, Hi I want to create a blank chart with no data using openoffice API. Looking at the openoffice 1.1 developer's guide, openoffice creates an initial bar chart with no data and then populates the data as requested. the call is: aChartDoc = aChartHelper.insertOLEChart( BarChart, aPos, aExtent, com.sun.star.chart.BarDiagram ); This is depicted from OpenOffice 1.1 Developer's guide Setting the Chart Type The default when creating a chart is a bar diagram with vertical bars. If a different chart type is required, apply a different diagram type to this initial chart. For example, | to create a pie chart, insert the default bar chart and change it to a pie chart. Is there a way to call the API so that a blank chart is created with no bars.?? No, not directly. A chart always has a Diagram, which needs to be of some type. The question is why do you want an empty document? Maybe you just want to have no data. A new chart is always created with some 3x4 dummy data (which wouldn't be necessary via API, but it still behaves this ways for historical reasons). You can set a new data array (XChartDataArray) with no data at the chart. Then, you should get an empty chart. -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Warning about hidden function
Hi,
on Solaris I get a warning in this situation:
class A
{
private:
foo( int );
};
class B : public A
{
private:
foo(); // - warning: hidden A::foo( int )
};
This appears strange to me, how can I hide a private function of the
base class, it should be hidden anyway. Is this a false alarm of the
compiler, or did I miss something?
-Bjoern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning about hidden function
Hi Daniel,
Bjoern Milcke schrieb:
Hi,
on Solaris I get a warning in this situation:
class A
{
private:
foo( int );
};
class B : public A
{
private:
foo(); // - warning: hidden A::foo( int )
};
This appears strange to me, how can I hide a private function of the
base class, it should be hidden anyway. Is this a false alarm of the
compiler, or did I miss something?
I have had the same problem. After asking around there seems to be no
other solution than to rename one function, to make all compilers happy.
Thanks, I did that. As the methods have different signatures they, not
surprisingly, have also slightly different purposes, so renaming is not
the worst thing to do in that situation, anyway. (And foo is not very
clear, too ;-) )
-Bjoern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] [api-dev] Debugging on Linux with remote access
Hi Eike, Hi Björn, On Thursday, 2007-06-28 08:55:49 +0200, Björn Milcke wrote: 1. Start StarOffice like this in a shell: [...] 2. I start gdb this way: gdb soffice.bin PID of soffice.bin [... set breakpoints ...] = The office freezes, gdb no longer reacts, the API test does nothing. Just by chance, did you start the gdb 6.3 from within the setsolar unxlngi6 baseline environment? I once had a similar experience and using the local machine's gdb 6.5 without a setsolar environment solved the problem. Please draw Hamburg RE's attention to this problem, sorry for not having done so earlier. I just tried gdb 6.6, and it worked well, but the issue is already fixed, so I have no direct comparison. ;-) Well, seems to be an improvement, anyway. Would make sense to have this in the environment rather than a broken gdb. -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] [api-dev] Debugging on Linux with remote access
Hi, for checking an API test (take a look at Issue 78873) I do the following without success: 1. Start StarOffice like this in a shell: ./soffice -accept=socket,host=0,port=8100;urp -nologo -calc -norestore = I get a process soffice and a sub-process soffice.bin 2. I start gdb this way: gdb soffice.bin PID of soffice.bin 3. I type cont (maybe after setting some breakpoints) 4. From a different shell I call checkapi -o sch.ChXChartData::com::sun::star::chart::XChartData -tdoc local path to testdocuments = The office freezes, gdb no longer reacts, the API test does nothing. Without the debugger this test crashes, so I expected to do this as well with the debugger being attached. It is possible to stop the API test (checkapi) with Ctrl-C. The debugger can only be killed, same for soffice. I noticed that I get a second process soffice.bin with the same arguments than the one before, so probably it is forked for the remote access? So, where does this come from, is this a new way to do remote access? BTW, attaching with another gdb instance to this new process does not work. Please, anybody who has an idea, what can I do? -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Can we do more regression testing?
Hi all, Hi, thanks for the many replies so far. As far as I see it, there are three major concerns: - The regression tests might take too long to run, - the regression tests might be too cumbersome to execute, - the findings of the regression tests might not justify the efforts to run them. Just a note from experience: We (the chart team) have a CWS (chart05) for which we started the auto-tests ourselves. Jogi helped us with installing the basics, which is a one-time effort (having some links and stuff to click on). Once this was done, all I did was selecting the the patch of our CWS build, installed it via an install tools (SUT). After this was finished, I just started the Test-Tool Launcher, selected the tests I want to run and clicked on Start. Then, the tests ran (they did over last week-end). Now, the tests are all finished, and there was one error in a test that was due to a change I did in the CWS. It was no regression, in this case it was a test that relied on a false behaviour. However, we found this problem before we sent the CWS to QA, and saved the time of ping-pong or the time of a QA engineer to find out why the test fails (I did the change in the code, so it is probably easier for me to know what goes wrong there). All in all, I think this was a success. Apart from the one-time effort (which was also less than an hour), it is a rather quick procedure (for me, not the machine doing the tests ;-) ), and we proved that it can show problems before a CWS is set to Ready for QA. So, for me all three concerns were no issues. Ok, I must admit that it is not always possible to run tests over the week-end and that for other modules the tests might run longer than two days, but you are flexible in this respect, you can just select a couple of tests which you think may be worth checking. -Bjoern P.S.: I must admit that I don't know how much of the infrastructure I used is also available to non-Sun-employees, but I think the idea is to make everything available to everybody in the long run. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] IMPORTANT ANNOUNCEMENT: HEDABU DOESN'T EXIST ANYMORE
Hi Frank, I know that cwsresync cannot detect everything. No automated tool can, and knowing and understanding what you do instead of relying on automatisms is always a good idea :) However, Mathias seemed to suggest that cwsanalyze is able to detect problems which are not detected by cwsresync. At least this is how I understood his mail. And that's the part I don't understand. I don't understand that, too. But, I have evidence that it is true. I have a file that I branched from version 1.11 and did changes on on my CWS. Current branch revision is 1.11.76.14 and the anchor tag after the last resyncs (before hedaburemove01) is 1.14. The HEAD is 1.15 and dead, i.e. the file was removed (moved, but from cvs's point of view just removed), because of hedaburemove01. Now, this is the output of cwsresync: Resyncing 'inc/SchXMLExportHelper.hxx' remove file: removed, schedule commit. This is the output of cwsanalyze: A inc/SchXMLExportHelper.hxx file removed on MWS but changed on CWS M inc/SchXMLExportHelper.hxx 1.14 - 1.11.76.14 I don't see why cwsresync should not be able to find out that the resync will remove the file although there are commits on the branch. With cwsanalyze I found a couple of files for which I would simply have missed changes on the CWS without. So, I strongly recommend that cwsresync alerts in this case. And I advise all people resyncing to = m210 to do a cwsanalyze to find out this kind of moved files. -Bjoern P.S.: moving files and modifying them at the same time (i.e. remove a file and commit it with some changes at another place) is something that is really bad to deal with with cvs. (That's what hedaburemove01 did.) 1. Check out the version of your anchor at place A (to some temp-file) 2. do a diff between this file and the new file at place B 3. Apply those changes to the file you changed on your branch at place A 4. copy the patched file to place B and commit it 5. remove the file at place A - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Regression Graphs
Hi Paul, To whom it may concern, I recently installed Debian on an old box I had, learned everything to date I know about Linux, and promptly typed out an advanced chemistry lab report in Calc, created graphs to prove that flipping coins had a 50% reaction rate when turning heads to tails, created best fit lines, and ground to a screeching halt when I went to add the regression statistics to the graphs. By regression statistics I mean the following: In Microsoft Excel one can add the equation and accuracy (r^2) value of a given regression type (linear, power, etc.) to a graph. This is highly useful for determining the best regression for a given graph. While it is currently possible to use linest or another function to evaluate the accuracy of a regression, it is not convenient nor visually appealing, nor on the graph itself. So. I have experience in Java and figured that since open office is open source, there probably was something I could do about this. I have a few preliminary questions about this endeavor: #1 I've done some internet searching and haven't found how to add regressions to graphs except possibly by macro. I'm assuming this is in fact something that cannot be currently done... if someone with some programming insight or a lot more experience with open office than myself could let me know if I've simply missed how to do this it would be great. In other words: is this in fact a feature yet to be implemented or did I miss it? Insert Statistics or the tab Statistics of the properties of a data series is the place to create regression curves. Note, that there is an Issue [1] in OOo 2.2, that only linear regression lines are painted, the other types are missing. It is fixed but not yet available as a patch. It will get into OOo 2.2.1. Showing formulas and the r^2 value is on the list [2] but not implemented yet. Regards, -Bjoern [1] http://www.openoffice.org/issues/show_bug.cgi?id=75991 [2] http://www.openoffice.org/issues/show_bug.cgi?id=7998 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] secondary Y
Hi DeeVee, Description There is no way to name the secondary Y axes. (Calc / Graphs} Yes, that's not possible yet. It will also not be in the new implementation. See Issue 1163 (http://www.openoffice.org/issues/show_bug.cgi?id=1163). Regards, -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Removed hedabu: Some non-existant headers in svx delivered
Hi, I noticed that many headers in svx were delivered twice in svx/prj/d.lst. After the hedaburemove01 CWS was integrated some of those remained, one fixed and one in the old version. The following headers are affected: svdattr.hxx xhatch.hxx xoutx.hxx xpoly.hxx I presume that removing the delivering out of svx/inc can be removed as the files no longer exist there. However, I wonder why so many headers were delivered twice? Was there a hedabu twice does something different than only once effect? And I wonder also, why delivering a non-existent file is no error. -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] IMPORTANT ANNOUNCEMENT: HEDABU DOESN'T EXIST ANYMORE
Hi Vladimir, IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT === Hi all, the ongoing SRC680 m209 build brings important change to our build environment. Since that milestone hedabu procedure will not work. To make it happen, many headers are moved to module's include specific folder, ie $MODULE/inc/$MODULE, where $MODULE is the name of a module. The new files in $MODULE/inc/$MODULE folder correspond to the last revision of their prototypes, ie m208. IMPORTANT(!!) for all cws owners: if your on the SRC680 based CWS has changes in headers - please resync the CWS to the m209(or later). Achtung(!) - if header was moved in m209 - the changes will not be reflected in new reincarnation of the file, so you have to make your changes in the new file MANUALLY. What changes? What do we have to do? What did the CWS fix? In Issue 72503 there is exactly *NO* description of what has been done. Was the only thing the move of some headers? Delivered headers only? Do we have to do any changes in CWS chart2mst3, where we added a new module with new headers? -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] IMPORTANT ANNOUNCEMENT: HEDABU DOESN'T EXIST ANYMORE
Hi Rüdiger, Bjoern Milcke wrote: Hi Vladimir, IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT === [...] Do we have to do any changes in CWS chart2mst3, where we added a new module with new headers? -Bjoern I more detail: If you did not touch headers, no action is required. If you changed existing headers or introduced new ones, check in prj/d.lst, whether those headers are subject to 'headbu' action. If they are not: no action required. If your header was 'hedabu'ed it most probably got removed by Vladimir and moved to an new location, as stated above. Moving files is not really supported by cvs. Therefore you have to check your changes, i.e. cvs diff -r CWS_ANCHOR -r cws_branch file and apply those changes to the moved header. If you introduced a new one subject to hedabu, move it to the appropriate directory and adapt include directives (i.e. for the above svx example change #include myheader.hxx into #include svx/myheader.h where needed). Finally, adapt d.lst. Thanks a lot. That clarified it! -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] binfilter subtlety with EXPORT_OASIS flag
Hi, while fixing a problem I stumbled over a subtle problem with the EXPORT_OASIS flag of the filter in xmloff for embedded objects. The flag EXPORT_OASIS is not set when your filter exports to the OOo XML format. This flag should not be used explicitly in the export code, however in most filters it is, nonetheless. If you use it in the export code, you might have a problem (like I had), otherwise you might stop reading here. When you write a binary file, the current document is exported as OOo XML flat (!), which is passed to binfilter. The flat-filter has the following problem: The usual export code in xmloff only creates the OASIS format. To have the OOo XML format, the OASIS format is transformed using the transformer code (xmloff/source/transform). This is controlled by not setting the EXPORT_OASIS flag. In flat format, the EXPORT_OASIS flag is set for embedded objects, because if it wouldn't, the embedded object would be transformed twice, once by the filter code of the embedded object, and then again by the container, because the container transforms the whole stream, including the embedded object. (That's what flat means). As a consequence, when you have: 1. An embedded object 2. That you export to binary format (or directly to flat OOo XML) 3. and you use something like if( getExportFlags() EXPORT_OASIS ) in your export code, you might get a problem, because although you export to OOo format, the EXPORT_OASIS flag is set. I admit, this is not a very common case, but it lead to problems in the chart code (the most common embedded object), and may also appear in other situation. Sorry, for writing such long, confusing stuff here, just wanted to make sure everybody knows about this. Regards, -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Renaming #openoffice.org into #dev.openoffice.org?
Hi all, as you probably know, several people want to do this operation on freenode.net: renaming current #openoffice.org channel to #dev.openoffice.org My +1 mail seems to have gotten lost, so here it is again. So, what are you guys waiting for? We are currently only 4 people in that chat :-) -Bjoern P.S.: We should also rename #go-oo to #dev.openoffice.org ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Renaming #openoffice.org into #dev.openoffice.org?
Hi Pavel, Hi, as you probably know, several people want to do this operation on freenode.net: renaming current #openoffice.org channel to #dev.openoffice.org This should free #openoffice.org (the default guess) channel afterwards for generic OOo channel, mainly oriented to support our users. +1 for #dev.openoffice.org And +1 for renaming #go-oo to #dev.openoffice.org as well ;-) just my 6cts (the taxes were increased in Germany) -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning: operator += enforces hidden conversion
Hi Stephan, Bjoern Milcke wrote: Hi Stephan, I came across the following piece of code: String a; xub_StrLen n = 0; n += a.Len(); This breaks on Windows (due to -werror). Because of the warning: warning C4244: '+=' : conversion from 'int' to 'USHORT', possible loss of data (in the last line of the fragment) [...] Does anybody have an idea what the problem is here? By the holy standard, x += y where x, y are short works by promoting x, y to int x', y', adding x' + y', converting int x' to short x'' and assigning x'' back to x. MSC chose to warn about this (about the potentially lossy converting int x' to short x'' part). Where is that in the standard? Is there a C-Standard, or is this in the C++-Standard. I couldn't find it. C++ Standard, 5.17/7, 5.7/1, 5/9, 4.5/1. 5.17/7 just says that a += b is equivalent to a = a + b, except that a is evaluated only once. This is only a proof that MSVC++ has a bug that (short) = (short) + (short) is not a warning. Why did you mention 5.7./1 and 5.9? Well, anyway, the conversion is described in 4.5./1. I also found this but is says that rvalues of type char and short *can* be converted to int. Well, it does not say that it actually does. (And it doesn't say how big the probability is that a compiler does this ;-) ) Anyway, the warning is not really a big problem. It was nasty, but I can live with it. However I would prefer to have a warning for: (short) = (int) but not for (short) = (short) op (short) I usually don't use short (or sal_Int16) anyway, but especially if you have typedefs like xub_StrLen, I really think this warning is a nuisance. To avoid this warning I would have to cast all typedefs where I don't know to what integral type they are currently defined (maybe compiler-dependent). sal_Foo a = 4, b = 3; a = static_cast sal_Foo ( a + b ); // instead of a += b; is just not so nice. I still see this conversion as compiler-internal and I just don't see *any* benefit of having this warning (in this particular case). If it is because the compiler cannot distinguish between a downcast that's in the code and one that it enforced itself, well, fair enough. Then we have to live with that. -Bjoern P.S.: When I was compiling some code for warning-freeness I really had the situation for one directory: unxlngi6.pro - removed some warnings till being warning-free unxlngi6 - removed some more warnings wntmsci10.pro - some more new warnings to remove wntmsci10 - more warnings to remove unxsols4.pro - yet another warning not yet being covered I know all compilers are different, but it would be nice to have a set of warnings that is almost equal between compilers. Otherwise we are forced to compile all platforms in our CWSes not only two of them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Quickstarter on Linux
Hi Frank et al, since when do we have a quick-starter for Linux? I thought this was not Since michael and kendy deemed one necessary and CWS gtkquickstart got integrated in m187. Aha. Was there an announcement? http://www.openoffice.org/servlets/ReadMsg?list=allfeaturesmsgNo=3145 Oops, right. Sorry, must have slipped through my eyes. In my m189, the checkbox is named Enable systray quickstarter. No mention of a system start - as you said, this would not be possible. So, enable means start the quickstarter next time I start OOo (if it is not already running)? Unfortunately, there's some open questions such as the ones you raised, since the feature mail did not contain much information, and there was no beforehand-information. See the thread at [1] for a discussion of this ... Ah that thread is about this feature? Well, the discussion was so general that I also lost track there ;-) (there is just too much to read ...) Why don't we have the quick-starter as an optional install item anyway? I usually disable tray-installers on Windows if they are in the setup of a program. Not sure how this would be possible on Unix (we would need a separate rpm, wouldn't we?), but on Windows, the quickstarter actually *is* a separate item in the installer. But can you really disable installation via the MSI installer? (Probably doing setup /a too often). But, coming back to a more technical stand-point, how does this work? Are there several libraries pre-loaded and occupy memory forever, or is the memory freed again, when you start other applications that need more memory? Of course the pre-loaded libraries would be swapped out in this case, but then you would probably no positive effect on startup any longer. I am just always sceptical if any process just takes some of my precious memory just for being prepared when it needs some. (It reminds me a bit on a towel that you put on a deck-chair to mark it yours ;-) ) -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Warning: operator += enforces hidden conversion
Hi,
I am a bit late with warning-freeness, I just now resynced against a
master build that contains warnings01 and pals. Maybe this problem here
is not new, but I didn't find anything about this.
I came across the following piece of code:
String a;
xub_StrLen n = 0;
n += a.Len();
This breaks on Windows (due to -werror). Because of the warning:
warning C4244: '+=' : conversion from 'int' to 'USHORT', possible loss
of data (in the last line of the fragment)
String is a typedef to UniString. UniString::Len() returns xub_StrLen.
So, here we have a xub_StrLen::operator+( xub_StrLen ), which should
work without conversion, no matter what xub_StrLen is. Actually,
xub_StrLen is currently a typedef to USHORT which is a typedef to
sal_uInt16 which is a typedef to unsigned short on Windows.
The only explanation I have for this is that there is no operator+= for
xub_StrLen, therefore the expression is expanded to:
n = (unsinged short)( (int)n + (int)(a.Len()) );
But why? There should be a lossless operator+= (and also +) for unsinged
short. And a typedef should be more or less an alias? And it is a POD
type, too.
Does anybody have an idea what the problem is here?
Rewriting this to
n = n + a.Len();
works. But it doesn't look much different.
Just checked:
unsigned short foo() { return 42; }
void bar()
{
unsigned short n = 0;
n += foo();
}
also creates the warning. So it doesn't have to do with typedefs. This
looks like a compiler bug to me.
Confused,
Bjoern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Quickstarter on Linux
Hi, since when do we have a quick-starter for Linux? I thought this was not necessary, as the libraries are kept in memory after the first start anyway, except if a lot of other programs are started meanwhile. So, is it for the first start only? When I install OOo (even the archive version without system integration) on a Linux machine using the Display on a Solaris server, I get the quick-starter icon in the system bar of my Solaris JDS workspace. (Maybe this vanishes after quitting the linux session window) The checkmark Start quick starter on system launch (or the like) is checked. How does this work as a simple (non-root) user? -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning: operator += enforces hidden conversion
Hi all,
I came across the following piece of code:
String a;
xub_StrLen n = 0;
n += a.Len();
This breaks on Windows (due to -werror). Because of the warning:
warning C4244: '+=' : conversion from 'int' to 'USHORT', possible loss
of data (in the last line of the fragment)
[...]
Just checked:
unsigned short foo() { return 42; }
void bar()
{
unsigned short n = 0;
n += foo();
}
Also checked:
short a = 1;
short b = 2;
a += b; // warning: conversion from int
(Warning: signed short, unsigned short. No warning: signed int, unsigned
int)
This also breaks due to the warning. Hm, looks indeed like there was no
operator += for short but only for int.
-Bjoern
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning: operator += enforces hidden conversion
Hi Stephan, I came across the following piece of code: String a; xub_StrLen n = 0; n += a.Len(); This breaks on Windows (due to -werror). Because of the warning: warning C4244: '+=' : conversion from 'int' to 'USHORT', possible loss of data (in the last line of the fragment) [...] Does anybody have an idea what the problem is here? By the holy standard, x += y where x, y are short works by promoting x, y to int x', y', adding x' + y', converting int x' to short x'' and assigning x'' back to x. MSC chose to warn about this (about the potentially lossy converting int x' to short x'' part). Where is that in the standard? Is there a C-Standard, or is this in the C++-Standard. I couldn't find it. I still think this warning doesn't make sense. I am not interested what the compiler does internally as long as the result is what I expect (adding 60,000 + 60,000 is an overflow and that's what I expect when adding shorts. If a possible overflow would cause a warning, almost any arithmetic operation would have to warn for any type.) I noticed that we didn't have this warning in an m172. Is there a new warning that is responsible for this? Or is this a general warning for possible-loss conversions (I thought we had already some before). Rewriting this to n = n + a.Len(); works. But it doesn't look much different. Yes, MSC does not warn about that one, I guess it is a bug. What? You mean short = short + short is also converted to short = (short)((int) + (int)) ? If it would be a warning, I could never add two short values while having -werror! I can't believe that! Still confused, -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Quickstarter on Linux
Hi Philipp et all, since when do we have a quick-starter for Linux? I thought this was not Since michael and kendy deemed one necessary and CWS gtkquickstart got integrated in m187. Aha. Was there an announcement? The checkmark Start quick starter on system launch (or the like) is checked. How does this work as a simple (non-root) user? The same way as on windows: on first start you select the icon once to siwtch the quickstarter off and a second time to end it. Yes, I know. That's the only thing I do with the quick-starter, too :-) No, I meant, how can I, as a non-root user, tell the system to start the quick-launcher on startup? That's simply not possible. If the user-startup (login) is meant, the launch would have to be in one of the $HOME/.* files. Is it? Or is this just a fake checkbox? Why don't we have the quick-starter as an optional install item anyway? I usually disable tray-installers on Windows if they are in the setup of a program. -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as ready for CWS usage?
Hi all, _A) Reasons to always fix the issues on the next milestone_ After a milestone is announced on [EMAIL PROTECTED], developers nearly immediately start working on that milestone, they create childworkspaces or resync their existing CWS against it. For doing so they rely on having the cvs tags fixed. What could be a reason to re-open an existing milestone? 1) A milestone could pass smoketest but nevertheless contain issues rendering it useless for parts of the stake holders. Example: current issue i67982 causing writer to crash on red linig or tables, build issues making a milestone totally unusable (build breaks) for OOo community developers. 2) A milestone could contain code integrated 'by accident' which is not allowed to be in the code line. For example license protected code not allowed to be distributed. Well, this should never happen! If it does we have a problem, because this stuff is checked in on a branch and can be obtained by anyone how can deal with cvs. If it does happen thogh, I suspect everyone could live with this special rebuild for legal reasons. What I really see as problematic is to have two different m179 (or whatever) Masters. If a Master was built and declared as Ready for CWS use (whatever this implies), it should never change. This leads only to problems. In this case it is better to announce: m179 will not be tested, so resync all m179-CWSes to =m180. IMHO this is a rule we should stick to. The other question is, what does Ready for CWS use mean. I would like it to mean Smoketest passed + Automated Tests passed. However, I see that automated tests take too long. One obvious way to fix this is no new idea: make the automated tests faster! :-) If automated tests cannot be made faster, I think maybe Smoketest passed is enough. In the normal case, where the automated tests find no severe bugs (the chance for them should be low, and it is from looking at the past. That's why we introduced CWSes), developers can immediately resync. In the rare occasion we just faced, it should then be announced that the master will not be tested and all CWSes based on it have to resync against the next one. I think we could live with that. -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as ready for CWS usage?
Martin Hollmichel wrote: Hi, _A) Reasons to always fix the issues on the next milestone_ -1 for this one. I object because the _always_ is too strict. We had in the past situations, where we did for a single platform or a build configuration a fix, where a full rebuild for all platforms was not needed. Often these kind of errors were reported days or weeks after a release. So, as an exception, I strongly recommend to allow such kind of fixes after careful review. This makes communication about the _final_ milestone of a release erasier than communicating which milestones for what releases are relevent. If fixes on an existing master are done in this same master it is absolutely *necessary* that this is *very* clearly communicated! -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning free code: the missing modules
Hi Stephan, M8 sch. Depending on svx. Do we want to make it warning clean, or do we want to wait for chart2? IMO making sch warning free is a complete waste of time, as it will be replaced. All time we invest there is missing for developing chart2. As you also mentioned the delivered headers memchrt.hxx and schdll.hxx, those probably must be made warning-free to avoid warnings in the projects that include them. I think schdll.hxx is not very complex and similar to scdll.hxx, sddll.hxx etc., so fixing this might be no problem (you never know, though ;-) ) For memchrt.hxx the question remains how much effort it would be to make it warning-free. It contains a lot of inline-code. I suppose there is no option to ignore warnings for a single file (like preprocessor directives)? Regards, Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning free code: the missing modules
Hi Stephan, I can add EXTERNAL_WARNINGS_NOT_ERRORS=TRUE to every makefile.mk in sch on CWS sb58 to effectively exempt it from warning-freedom, just as I did for binfilter. Yes, please. testhxx only found (very few) problems in memchrt.hxx, and only on wntmsci10[.pro], so getting those headers into shape so that they do not break sc/sd/sw is hopefully no big deal (and can probably done in one of the CWS for sc/sd/sw?). That sounds good. The CWS to fix this in could be the same where the variables in makefile.mk are added, so we have only one warnings-CWS that contains sch. -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to use gdb with OO
Kay Ramme writes: Aditya, unfortunately gdb does not seem to be an easy beast ;-). I tried various versions by myself, what I found working quite well, is: gdb --version GNU gdb 6.3-debian [...] I am also using this version, and it works indeed good, however it still has the problem that breakpoints in constructors do not work, which is sometimes a real nuisance! -Bjoern -- Bjoern Milcke mailto:Bjoern.Milcke'at'Sun.COM Software Engineer http://www.sun.com/staroffice (Star|Open)Office Chart http://graphics.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to use gdb with OO
Kay Ramme writes: Aditya, unfortunately gdb does not seem to be an easy beast ;-). I tried various versions by myself, what I found working quite well, is: gdb --version GNU gdb 6.3-debian [...] I am also using this version, and it works indeed good, however it still has the problem that breakpoints in constructors do not work, which is sometimes a real nuisance! -Bjoern -- Bjoern Milcke mailto:Bjoern.Milcke'at'Sun.COM Software Engineer http://www.sun.com/staroffice (Star|Open)Office Chart http://graphics.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
