Re: [dev] proposal for change of cws policies
Martin Whitaker <[EMAIL PROTECTED]> writes: > Unfortunately they will also get assertions with a vanilla build, > which makes this less useful. I wasted a lot of time trying to > track down the cause of an assertion, assuming it was due to a > change I had introduced, before discovering it still occurred > with a clean checkout. > Hi Martin, I didn't say that there ain't things horribly messed in CVS HEAD. ;-) OTOH, this is not to suggest that things _are_ messed there - maybe it's just that a dev has been over-cautious... B-) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Terms of Use of GullFOSS and sun.com
Dear Ooo Developers at SUN, My name is Maho Nakata, ja-nl project lead. I'd like to ask the developers at SUN, about terms of use the contents of GullFOSS. I reagard the contents of GullFOSS is very important, and Japanese should know these contents, direct voice from the brilliant developers. Usually I see via planet.go-ooo.org :) also - we want to translate to Japanese. This is very constructive, I belive. Hirano-san forwarded to our local mailing list [ja-translate] at least GullFOSS and sun.com. http://ja.openoffice.org/servlets/ReadMsg?list=translate&msgNo=2876 http://blogs.sun.com/GullFOSS/entry/improving_calc_usability_autosum http://ja.openoffice.org/servlets/ReadMsg?list=translate&msgNo=2867 http://www.sun.com/software/star/openoffice/index.xml and Nakamoto-san claimed that these posts might not permitted by copyright holder, and possible copyright infringement, and should be removed immdeately. (there was other posting that merely copy'n'paste from other web site as well). Khirano admitted that he didn't obtain agreement. So Nakamot-san was right. I'll remove these mails immideately. Well, khirano is wrong, and Nakamoto is right, but we'd like to share the good infomations of OpenOffice.org and StarOffice/Suite. However, I'm not sure the terms of use, so I glanced blogs.sun.com/GullFOSS and sun.com. So I ask here, what is the terms of use of GullFOSS and sun.com? I think - very strict terms of use is not constructive at all. * We just want to forward to our mailing list. * We just want to transltate into their native language. This is very constructive. How do you think? All the best, -- Nakata Maho ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
On Wed, 2007-07-18 at 22:25 +0200, Thorsten Behrens wrote: Kohei Yoshida <[EMAIL PROTECTED]> writes: 1) The use of "product" and "non-product" terms seems unclear to me. What do they mean exactly? Hi Kohei, a "product" version is one that has .pro suffix at the output trees (that's the default case). A "non-product" has no such suffix, and gets enabled via --enable-dbgutil at the configure line. We should rather advertise this a bit more, because people then get assertions if they break stuff horribly. ;-) Unfortunately they will also get assertions with a vanilla build, which makes this less useful. I wasted a lot of time trying to track down the cause of an assertion, assuming it was due to a change I had introduced, before discovering it still occurred with a clean checkout. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
On Thu, 2007-07-19 at 07:15 +0200, Frank Schönheit - Sun Microsystems Germa?ßISO-8859-1?Q?ny wrote: > Hi Kohei, > > > 1) The use of "product" and "non-product" terms seems unclear to me. > > What do they mean exactly? > > http://wiki.services.openoffice.org/wiki/Non_Product_Build Excellent. Thank you, Frank. :-) Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: Link-Error with Boost (attachment)
Forgotten attachment ../unxlngi6/slo/edtwin.o: In function `SwEditWin::KeyInput(KeyEvent const&)': edtwin.cxx:(.text+0x45c3): undefined reference to `SwFormatClipboard::Erase()' ../unxlngi6/slo/edtwin.o: In function `SwEditWin::MouseButtonUp(MouseEvent const&)': edtwin.cxx:(.text+0x9e07): undefined reference to `SwFormatClipboard::Paste(SwWrtShell&, SfxStyleSheetBasePool*, bool, bool)' edtwin.cxx:(.text+0x9e12): undefined reference to `SwFormatClipboard::HasContent() const' ../unxlngi6/slo/edtwin.o: In function `SwEditWin::UpdatePointer(Point const&, unsigned short)': edtwin.cxx:(.text+0xab3c): undefined reference to `SwFormatClipboard::HasContentForThisType(int) const' ../unxlngi6/slo/edtwin.o: In function `SwEditWin::MouseMove(MouseEvent const&)': edtwin.cxx:(.text+0xd75d): undefined reference to `SwFormatClipboard::HasContent() const' ../unxlngi6/slo/edtwin.o: In function `SwEditWin::MouseButtonDown(MouseEvent const&)': edtwin.cxx:(.text+0xf69b): undefined reference to `SwFormatClipboard::HasContent() const' ../unxlngi6/slo/view.o: In function `SwView::~SwView()': view.cxx:(.text+0x377e): undefined reference to `SwFormatClipboard::~SwFormatClipboard()' ../unxlngi6/slo/view.o: In function `SwView::~SwView()': view.cxx:(.text+0x3cbe): undefined reference to `SwFormatClipboard::~SwFormatClipboard()' ../unxlngi6/slo/view.o: In function `SwView::~SwView()': view.cxx:(.text+0x41fe): undefined reference to `SwFormatClipboard::~SwFormatClipboard()' ../unxlngi6/slo/view.o: In function `SwView::SwView(SfxViewFrame*, SfxViewShell*)': view.cxx:(.text+0x4628): undefined reference to `SwFormatClipboard::SwFormatClipboard()' ../unxlngi6/slo/view.o: In function `SwView::SwView(SfxViewFrame*, SfxViewShell*)': view.cxx:(.text+0x5f9e): undefined reference to `SwFormatClipboard::SwFormatClipboard()' ../unxlngi6/slo/view1.o: In function `SwView::StateFormatPaintbrush(SfxItemSet&)': view1.cxx:(.text+0x3d): undefined reference to `SwFormatClipboard::HasContent() const' view1.cxx:(.text+0xc0): undefined reference to `SwFormatClipboard::CanCopyThisType(int) const' ../unxlngi6/slo/view1.o: In function `SwView::ExecFormatPaintbrush(SfxRequest&)': view1.cxx:(.text+0x11c): undefined reference to `SwFormatClipboard::HasContent() const' view1.cxx:(.text+0x131): undefined reference to `SwFormatClipboard::Erase()' view1.cxx:(.text+0x206): undefined reference to `SwFormatClipboard::Copy(SwWrtShell&, SfxItemPool&, bool)' collect2: ld returned 1 exit status dmake: Error code 1, while making '../unxlngi6/lib/libsw680li.so' ---* tg_merge.mk *--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: Link-Error with Boost
Thanks for answer.. Yes, I have an external boost. I think, that was a bad idea. ;-) I moved it to EXCEPTIONSFILES but now I have another linker error (attachment). Is there a solution without recompiling everything? Does I need it for database-development or can I ignore and disable that part of OOo? Regards, André Caolan McNamara wrote: > This likely means that OOo has been configured to use the external boost > headers. The copy that OOo has internally has hacked some of the headers > to disable exceptions IIRC, and so it is likely that the file > formatclipboard.cxx is in a "no exceptions" makefile.mk in sw. > > So, quick workaround is to add formatclipboard.obj to the > EXCEPTIONSFILES section of the makefile.mk in sw/source/ui/uiview like > one of the other examples there. > > C. signature.asc Description: OpenPGP digital signature
Re: [dev] Link-Error with Boost
On Thu, 2007-07-19 at 16:45 +0200, A. Klitzing wrote: > Hi again, > > What does I need to do to fix that problem? > > > Regards, > André > -ltl680li -li18nisolang1gcc3 -lcomphelp4gcc3 -lucbhelper4gcc3 > -luno_cppuhelpergcc3 -luno_cppu -lvos3gcc3 -luno_sal > -luno_salhelpergcc3 -licuuc -li18nutilgcc3 -lavmedia680li -lxml2 -ldl > -lpthread -lm -Wl,-Bdynamic -lstlport_gcc_stldebug > ../unxlngi6/slo/formatclipboard.o: In function > `boost::detail::shared_count::shared_count(SfxPoolItem*)': > formatclipboard.cxx:(.text._ZN5boost6detail12shared_countC1I11SfxPoolItemEEPT_[boost::detail::shared_count::shared_count(SfxPoolItem*)]+0x66): > undefined reference to `boost::throw_exception(std::exception const&)' > collect2: ld returned 1 exit status > dmake: Error code 1, while making '../unxlngi6/lib/libsw680li.so' > ---* tg_merge.mk *--- This likely means that OOo has been configured to use the external boost headers. The copy that OOo has internally has hacked some of the headers to disable exceptions IIRC, and so it is likely that the file formatclipboard.cxx is in a "no exceptions" makefile.mk in sw. So, quick workaround is to add formatclipboard.obj to the EXCEPTIONSFILES section of the makefile.mk in sw/source/ui/uiview like one of the other examples there. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] To OOo Builders ...
Just created another patch to make deliver.pl less verbose ... http://udk.openoffice.org/issues/show_bug.cgi?id=79798 Kay Ramme - Sun Germany - Hamburg wrote: Hi builders, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Link-Error with Boost
Hi again, I have a link error with boost here in m221. I tried it with boost 1.33.1 and 1.34.0. I only find a "helpful" documentation in boost [1] about that function. What does I need to do to fix that problem? Regards, André [1] http://www.boost.org/libs/utility/throw_exception.html -- Making: ../unxlngi6/lib/libsw680li.so g++ -Wl,-z,noexecstack -Wl,-z,combreloc -Wl,-z,defs -Wl,-rpath,'$ORIGIN' -shared -L../unxlngi6/lib -L../lib -L/home/andre/SRC680_m221/solenv/unxlngi6/lib -L/home/andre/SRC680_m221/solver/680/unxlngi6/lib -L/home/andre/SRC680_m221/solenv/unxlngi6/lib -LNO_JAVA_HOME/lib -LNO_JAVA_HOME/jre/lib/i386 -LNO_JAVA_HOME/jre/lib/i386/client -LNO_JAVA_HOME/jre/lib/i386/native_threads -L/usr/lib ../unxlngi6/slo/sw_dflt_version.o -o ../unxlngi6/lib/libsw680li.so ../unxlngi6/slo/swmodule.o ../unxlngi6/slo/swdll.o ../unxlngi6/slo/acccell.o ../unxlngi6/slo/acccontext.o ../unxlngi6/slo/accdoc.o ../unxlngi6/slo/accembedded.o ../unxlngi6/slo/accfootnote.o ../unxlngi6/slo/accframe.o ../unxlngi6/slo/accframebase.o ../unxlngi6/slo/accfrmobj.o ../unxlngi6/slo/accfrmobjmap.o ../unxlngi6/slo/accfrmobjslist.o ../unxlngi6/slo/accgraphic.o ../unxlngi6/slo/accheaderfooter.o ../unxlngi6/slo/acchyperlink.o ../unxlngi6/slo/acchypertextdata.o ../unxlngi6/slo/accmap.o ../unxlngi6/slo/accnotextframe.o ../unxlngi6/slo/accpage.o ../unxlngi6/slo/accpara.o ../unxlngi6/slo/accportions.o ../unxlngi6/slo/accpreview.o ../unxlngi6/slo/accselectionhelper.o ../unxlngi6/slo/acctable.o ../unxlngi6/slo/acctextframe.o ../unxlngi6/slo/grfatr.o ../unxlngi6/slo/ndgrf.o ../unxlngi6/slo/paratr.o ../unxlngi6/slo/calbck.o ../unxlngi6/slo/cellatr.o ../unxlngi6/slo/fmtfollowtextflow.o ../unxlngi6/slo/fmtwrapinfluenceonobjpos.o ../unxlngi6/slo/format.o ../unxlngi6/slo/hints.o ../unxlngi6/slo/swatrset.o ../unxlngi6/slo/edfldexp.o ../unxlngi6/slo/edtab.o ../unxlngi6/slo/acorrect.o ../unxlngi6/slo/autofmt.o ../unxlngi6/slo/edatmisc.o ../unxlngi6/slo/edattr.o ../unxlngi6/slo/eddel.o ../unxlngi6/slo/edfcol.o ../unxlngi6/slo/edfld.o ../unxlngi6/slo/edfmt.o ../unxlngi6/slo/edglbldc.o ../unxlngi6/slo/edglss.o ../unxlngi6/slo/editsh.o ../unxlngi6/slo/edlingu.o ../unxlngi6/slo/ednumber.o ../unxlngi6/slo/edredln.o ../unxlngi6/slo/edtox.o ../unxlngi6/slo/edundo.o ../unxlngi6/slo/edws.o ../unxlngi6/slo/edsect.o ../unxlngi6/slo/bookmrk.o ../unxlngi6/slo/callnk.o ../unxlngi6/slo/crbm.o ../unxlngi6/slo/crsrsh.o ../unxlngi6/slo/crstrvl.o ../unxlngi6/slo/crstrvl1.o ../unxlngi6/slo/findattr.o ../unxlngi6/slo/findcoll.o ../unxlngi6/slo/findfmt.o ../unxlngi6/slo/findtxt.o ../unxlngi6/slo/pam.o ../unxlngi6/slo/paminit.o ../unxlngi6/slo/swcrsr.o ../unxlngi6/slo/trvlcol.o ../unxlngi6/slo/trvlfnfl.o ../unxlngi6/slo/trvlreg.o ../unxlngi6/slo/trvltbl.o ../unxlngi6/slo/unocrsr.o ../unxlngi6/slo/viscrs.o ../unxlngi6/slo/scrrect.o ../unxlngi6/slo/vdraw.o ../unxlngi6/slo/viewimp.o ../unxlngi6/slo/viewsh.o ../unxlngi6/slo/viewpg.o ../unxlngi6/slo/vnew.o ../unxlngi6/slo/vprint.o ../unxlngi6/slo/pagepreviewlayout.o ../unxlngi6/slo/dview.o ../unxlngi6/slo/dcontact.o ../unxlngi6/slo/dflyobj.o ../unxlngi6/slo/drawdoc.o ../unxlngi6/slo/dobjfac.o ../unxlngi6/slo/dpage.o ../unxlngi6/slo/swacorr.o ../unxlngi6/slo/sw3convert.o ../unxlngi6/slo/swblocks.o ../unxlngi6/slo/SwXMLBlockImport.o ../unxlngi6/slo/SwXMLSectionList.o ../unxlngi6/slo/SwXMLBlockExport.o ../unxlngi6/slo/SwXMLBlockListContext.o ../unxlngi6/slo/SwXMLTextBlocks.o ../unxlngi6/slo/SwXMLTextBlocks1.o ../unxlngi6/slo/atrfrm.o ../unxlngi6/slo/anchoredobject.o ../unxlngi6/slo/anchoreddrawobject.o ../unxlngi6/slo/calcmove.o ../unxlngi6/slo/colfrm.o ../unxlngi6/slo/findfrm.o ../unxlngi6/slo/flowfrm.o ../unxlngi6/slo/fly.o ../unxlngi6/slo/flycnt.o ../unxlngi6/slo/flyincnt.o ../unxlngi6/slo/flylay.o ../unxlngi6/slo/flypos.o ../unxlngi6/slo/frmtool.o ../unxlngi6/slo/ftnfrm.o ../unxlngi6/slo/hffrm.o ../unxlngi6/slo/layact.o ../unxlngi6/slo/laycache.o ../unxlngi6/slo/layouter.o ../unxlngi6/slo/movedfwdfrmsbyobjpos.o ../unxlngi6/slo/newfrm.o ../unxlngi6/slo/objectformatter.o ../unxlngi6/slo/objectformattertxtfrm.o ../unxlngi6/slo/objectformatterlayfrm.o ../unxlngi6/slo/objstmpconsiderwrapinfl.o ../unxlngi6/slo/pagechg.o ../unxlngi6/slo/pagedesc.o ../unxlngi6/slo/paintfrm.o ../unxlngi6/slo/sectfrm.o ../unxlngi6/slo/softpagebreak.o ../unxlngi6/slo/sortedobjs.o ../unxlngi6/slo/sortedobjsimpl.o ../unxlngi6/slo/ssfrm.o ../unxlngi6/slo/tabfrm.o ../unxlngi6/slo/trvlfrm.o ../unxlngi6/slo/unusedf.o ../unxlngi6/slo/virtoutp.o ../unxlngi6/slo/wsfrm.o ../unxlngi6/slo/dbg_lay.o ../unxlngi6/slo/atrstck.o ../unxlngi6/slo/EnhancedPDFExportHelper.o ../unxlngi6/slo/frmcrsr.o ../unxlngi6/slo/frmform.o ../unxlngi6/slo/frminf.o ../unxlngi6/slo/frmpaint.o ../unxlngi6/slo/guess.o ../unxlngi6/slo/inftxt.o ../unxlngi6/slo/itradj.o ../unxlngi6/slo/itratr.o ../unxlngi6/slo/itrcrsr.o ../unxlngi6/slo/itrform2.o ../unxlngi6/slo/itrpaint.o ../unxlngi6/slo/itrtxt.o ..
[dev] Little Helpers updated
Hi, I updated all scripts at http://wiki.services.openoffice.org/wiki/Little_Helpers to generate positive directory lists dynamically instead of assuming a fixed set of subdirectories per module. For those not knowing the page: it's about how to use utilities like GNU id-utils, ctags and cscope to tame the OOo code base. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to this [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] Thanks. pgppvfnkmgV6X.pgp Description: PGP signature
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Ollie,
sorry for not replying earlier.
Oliver Braun wrote:
Kay Ramme - Sun Germany - Hamburg wrote:
Some of the reasons for the namespace problems we are facing are IMHO
simply non optimal placings, e.g. "com::sun::uno::Reference" would
have belonged into "cppu" ("cppu::Reference" or may be simply
"uno::Reference". As probably most people agree with, the whole
"com::sun::star" namespace became obsolete when open sourcing
StarOffice and should have been renamed to "OOo" (or similar), and I
am sure there are more aspects one currently would like to see being
reflected in the namespaces, but ... we want to stay API and ABI
compatible, more or less rendering these thoughts useless ;-)
What about new interfaces / services ? Would it be feasible to create
"uno::" aliases for "com::sun::star::uno::" and "com::sun::star::lang"
and start using org::openoffice namespace for new interface/service
definitions ?
In general I think it would be feasible, but please see below ...
Or even better, move the basic types to ::uno and make aliases for those
in the old namespace(s) ?!
To preserve API (build) compatibility, right?
Other aliases (e.g. for beans etc.) might need to get added over time,
but at least we could start the transition.
I take the opportunity to comment on compatibility ;-) though we are
going to have a BOF at the OOo Conf 2007 regarding this topic, lead by
Juergen.
Wikipedia differentiates between forward and backward compatibility
(http://en.wikipedia.org/wiki/Computer_compatibility), the compatibility
we are here talking about is backward compatibility.
There are two types of compatibility,
- ABI (Application Binary Interface) compatibility - meaning that a
program compiled for one binary environment is able to run on another
binary environment, as long as these environments are binary (or ABI)
compatible.
- API (Application Programming Interface) compatibility - meaning that
the source code of a program compilable for one API environment may be
compiled for another API environment (without change) as long as these
environments are API compatible.
ABI compatibility is in general harder to achieve (you must know the
very detail regarding how parameters are passed, how symbols are mangled
etc. etc.) and offers less opportunity for improvement (e.g. you can not
change a function from being outline to inline). ABI compatibility is
what proprietary software vendors classical provide / require through
their lines of operating systems, applications etc.
API compatibility is superior wrt optimization, simplification,
flexibility etc., but requires the source code to be recompiled. API
compatibility is what most / many open source products provide only,
leading to the situation that it is some times hard for commercial
(without the source) vendors to provide binary (ABI compatibility
requiring) products e.g. for different Linux distributions. This is what
the LSB (Linux Standards Base) deals with.
Compatibility in general is about the "cost of adaption". Staying
compatible reduces the cost of ISVs etc. to adapt their products to
later environments, while it increases the costs of the environment
provider, as he/she explicitly needs to take steps to preserve backward
compatibility.
With OOo we currently provide ABI and API compatibility. The compatible
interfaces OOo offers are AFAIK:
- Various Uno language bindings
- Binary Uno
- C++ Uno
- Java Uno
- CLI Uno
- Python Uno
- Remote Uno
- ...
- OOo BASIC
- OOo API
- Configuration Items
- Some deployment parameters (e.g. "UserInstallation")
(http://wiki.services.openoffice.org/wiki/Uno/Binary/Spec/Bootstrapping)
- Other: Document compatibility (e.g. ODF, .DOC), ...
As we stay compatible on all these interfaces, we carry the costs of
doing so, allowing ISVs and others to reduce their costs of adaption to
a minimum. At least until now we thought this to be necessary, to get
new ISVs interested and to keep already supporting ISVs
Unfortunately it seems, and this is actually the reason for my long
comment, that staying backwards compatible hinders us to clean up stuff,
which really deserves it ...
From a theoretical standpoint, compatibility could be ensured by
leaving old things alone (may be after a reasonable life time) and only
introducing new stuff, though in practice this seems to be unreasonable.
Taking a look at Mozilla, it seems that they become incompatible once a
while, at least with every major version (please correct if am wrong),
and that this seems to acceptable for ISVs etc. The Linux kernel seems
to become incompatible as so often, only keeping the system call
interface stable, once a while leading to problems with binary only
drivers e.g. from NVidia or ATI.
So, the questions is, would it be acceptable for our ISVs etc. that we
become incompatible e.g. with every major? That would give us the
opportunity to clean up things (fix the namespaces), may be
