Re: [Libreoffice] [PATCH] replace Saxon/J XSLT extension functions with libxslt/c++ equivalent
Asking here Tor and Fridrich if they are ok with the possibility of breaking the windows build Well, it has already been broken for several weeks, I doubt it would make the situation much worse. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [GSoc] Students and mentors, apply now!
Hi all, this reminder is for both the students and the mentors: please apply now on Google Melange. http://www.google-melange.com/gsoc/org/show/google/gsoc2011/libreoffice * Students applications can be filed from March 28th (yesterday) to April 8th (less than 2 weeks). * Mentors need to apply now too in order to be able to participate in the applications selection process after that period. Don't hesitate to tell me if you have any trouble to apply. -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] GSoC: Wizards, Java to Python conversion
Hi Xisco, On Mon, 2011-03-28 at 11:16 +0200, Xisco Faulí wrote: I was wondering if this task is suitable for the GSoC and if there is anyone who's willing to be a mentor of it. http://wiki.documentfoundation.org/Easy_Hacks#Wizards:_Java_to_Python.3F_conversion I could help on the Java side, but would be much less proficient on the Python one. I think that could fit as a GSoc task, but you need to carefully evaluate which wizards would be migrated at the end... not too much, but enough ;) Regards, -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Development-/Future-Builds of LibreOffice with special naming posible?
Hi Andreas, On Mon, 2011-03-28 at 20:39 +0200, Andreas Mantke wrote: the development of LibreOffice and its features are growing every day and week ;-) Exciting isn't it :-) In my opinion it would be a good idea to have a special build (nightly build or something similar) with a special naming, maybe LibO-Future This is happening already but only for Mac and Linux. http://dev-builds.libreoffice.org/daily/ Fridrich is working on getting the existing Windows tinderboxes to up-load their result - having said that, master is not building that well on Windows currently :-) so that it is posible to install that build in parallel on your PC. Such a build could help QA-People and documentation writers for example to get in touch with the new features and report bugs early. The parallel install is something I know nothing about on Windows; and may involve some development work - if so, it'd be great to have help on that. ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fdo#34908
Hi Lubos
On 25/03/11 18:52, Lubos Lunak wrote:
printf( %p %p %s %p %p %s %p %p %s\n, ptr, dynamic_cast void*( ptr ),
typeid( *ptr ).name(), pFieldmark, dynamic_cast void*( pFieldmark ),
typeid( *pFieldmark ).name(), pCheckboxFm, dynamic_cast void*(
pCheckboxFm ), typeid( *pCheckboxFm ).name());
(where 'ptr' is what you get from the pMarksAccess-makeNoTextFieldBookmark()
call before casting to anything)
Okay, managed to put in some debug
here the code snippet(s) were the debug was done ( same for
distro/no-distro except for some text to distinguish one from the other )
ww8par3.cxx: ( SwWW8ImplReader::Read_F_FormCheckBox )
[...]
if (aBookmarkName.Len()0)
{
IDocumentMarkAccess* pMarksAccess = rDoc.getIDocumentMarkAccess( );
//IFieldmark* pFieldmark = dynamic_castIFieldmark*(
pMarksAccess-makeNoTextFieldBookmark(
IFieldmark* ptr = ( pMarksAccess-makeNoTextFieldBookmark(
*pPaM, aBookmarkName,
rtl::OUString::createFromAscii( ODF_FORMCHECKBOX ) ) );
IFieldmark* pFieldmark = dynamic_castIFieldmark*( ptr );
OSL_ENSURE(pFieldmark!=NULL, hmmm; why was the bookmark not
created?);
if (pFieldmark!=NULL) {
IFieldmark::parameter_map_t* const pParameters =
pFieldmark-GetParameters();
ICheckboxFieldmark* pCheckboxFm =
reinterpret_castICheckboxFieldmark*(pFieldmark);
OSL_TRACE( distro ( Read_F_FormCheckBox ) %p %p %s %p %p
%s %p %p %s reinterpret %p %s\n,
ptr, dynamic_cast void* ( ptr ), typeid( *ptr ).name(),
pFieldmark, dynamic_cast void* ( pFieldmark ),
typeid( *pFieldmark ).name(),
pCheckboxFm, dynamic_cast void* ( pCheckboxFm ),
typeid( *pCheckboxFm ).name(),
reinterpret_castICheckboxFieldmark*( ptr ), typeid(
(*reinterpret_castICheckboxFieldmark*( ptr ))).name() );
OSL_TRACE(dynamic_castICheckboxFieldmark*( ptr ) %p,
dynamic_castICheckboxFieldmark*( ptr ));
[...]
docbm.cxx ( MarkManager::makeNoTextFieldBookmark )
[...]
sw::mark::IMark* pMark = makeMark( rPaM, rName,
IDocumentMarkAccess::CHECKBOX_FIELDMARK );
sw::mark::IFieldmark* pFieldMark =
dynamic_castsw::mark::IFieldmark*( pMark );
sw::mark::ICheckboxFieldmark* pCBmark =
dynamic_castsw::mark::ICheckboxFieldmark*( pMark );
OSL_TRACE( distro (makeNoTextFieldBookmark ) %p %p %s %p %p
%s \n, pMark, dynamic_cast void* ( pMark ), typeid( *pMark ).name(),
pCBmark, dynamic_cast void* ( pCBmark ), typeid( *pCBmark ).name( )
[...]
and the results..
disto 32-bit
distro (makeNoTextFieldBookmark ) 0x8d013a4 0x8d01370
N2sw4mark17CheckboxFieldmarkE 0x8d013a4 0x8d01370
N2sw4mark17CheckboxFieldmarkE
(interesting in the library the implementation is in the dynamic_cast
works )
distro 0x8d013a4 0x8d01370 N2sw4mark17CheckboxFieldmarkE 0x8d013a4
0x8d01370 N2sw4mark17CheckboxFieldmarkE 0x8d013a4 0x8d01370
N2sw4mark17CheckboxFieldmarkE reinterpret 0x8d013a4
N2sw4mark17CheckboxFieldmarkE
dynamic_castICheckboxFieldmark*( ptr ) (nil)
( and here it doesn't so I guess there is some symbol confusion.. but I
don't see it )
output from nm:
nm unxlngi6.pro/lib/libswli.so | c++filt | grep ICheckboxField
00343c90 t sw::mark::ICheckboxFieldmark::ICheckboxFieldmark()
00344bdc t sw::mark::ICheckboxFieldmark::~ICheckboxFieldmark()
00344d98 t sw::mark::ICheckboxFieldmark::~ICheckboxFieldmark()
00344f36 t sw::mark::ICheckboxFieldmark::~ICheckboxFieldmark()
00ebc9c0 d construction vtable for
sw::mark::ICheckboxFieldmark-in-sw::mark::CheckboxFieldmark
00ebe3a0 V construction vtable for
sw::mark::IFieldmark-in-sw::mark::ICheckboxFieldmark
00ebe460 V construction vtable for
sw::mark::IMark-in-sw::mark::ICheckboxFieldmark
00ebdea0 V typeinfo for sw::mark::ICheckboxFieldmark
00d4ef30 V typeinfo name for sw::mark::ICheckboxFieldmark
00ebe360 V VTT for sw::mark::ICheckboxFieldmark
00ebe280 V vtable for sw::mark::ICheckboxFieldmark
00344bbe t virtual thunk to
sw::mark::ICheckboxFieldmark::~ICheckboxFieldmark()
00344d7a t virtual thunk to
sw::mark::ICheckboxFieldmark::~ICheckboxFieldmark()
00344bcd t virtual thunk to
sw::mark::ICheckboxFieldmark::~ICheckboxFieldmark()
00344d89 t virtual thunk to
sw::mark::ICheckboxFieldmark::~ICheckboxFieldmark()
nm unxlngi6.pro/lib/libmswordli.so | c++filt | grep ICheckboxField
0023b9b8 V typeinfo for sw::mark::ICheckboxFieldmark
001f303c V typeinfo name for sw::mark::ICheckboxFieldmark
non - disto 32-bit
==
no-distro (makeNoTextFieldBookmark ) 0x8c8c2ec 0x8c8c2b8
N2sw4mark17CheckboxFieldmarkE 0x8c8c2ec 0x8c8c2b8
N2sw4mark17CheckboxFieldmarkE
no-distro 0x8c8c2ec 0x8c8c2b8 N2sw4mark17CheckboxFieldmarkE 0x8c8c2ec
0x8c8c2b8 N2sw4mark17CheckboxFieldmarkE 0x8c8c2ec 0x8c8c2b8
N2sw4mark17CheckboxFieldmarkE reinterpret 0x8c8c2ec
N2sw4mark17CheckboxFieldmarkE
dynamic_castICheckboxFieldmark*( ptr ) 0x8c8c2ec
nm
Re: [Libreoffice] plugin for advanced engineering calculationsand
Thank you for your attention. I'm working on a university project, where the goal is to develop solutions for advanced calculations. eg. (integrals, derivatives, polynomials ... etc) a range of funçções. But as I said do not believe it useful to go into details of the source code. I can not script vba for this? I started compiling the code and am downloading it is necessary? would be interesting to have this built-in code? I use linux:) think it will facilitate. I intend to start as soon as possible, but as I said above ... would be interesting to use scripts or leave vba embedded in the source code. Hugs; 2011/3/29 Michael Meeks michael.me...@novell.com Hi Luiz, On Tue, 2011-03-29 at 08:08 -0300, Luiz Henrique Natalino wrote: I'm having a task to develop a plugin for advanced engineering calculationsand use this resource in libreoffice, like the lords of the ropes. Nice ! :-) So - I guess the first question is: does it really need to be a plugin ? if these are generally useful formulae (or whatever) it can be best to simply have them included in the product itself. Inclusion really helps you - maintained by other people, helps to scale contribution, translation goes through the normal flow etc. etc. 1) What do you interface development Usage? Well; VCL if you're writing C++, failing that there is some horrible UNO interface for VCL in the toolkit/ module. 2) You can place this contribution in libreoffice? Of course - it is more than welcome; it needs to be dual-licensed MPL/LGPLv3+ to be included though - a license template is in bootstrap/ 3) where the documentation located? Good question :-) there is sparse-to-non-existent documentation around the place. Some of the UNO interfaces are documented, but in general asking people on IRC is a good move, and/or finding an existing plugin or feature that is most similar to what you want :-) First - get a build that you can compile and run, that is easiest on Linux of course. For calc (for example), the code is in the sc/ module - have a poke around in there. If you just want to add some functions scaddins/ has some UNO based function implementations that might be fun to base on. What else - is there an existing dialog that does something similar to what you want ? we can dig out the code for that for you to read. All the best, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot -- Att. Luiz Henrique Natalino ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Development-/Future-Builds of LibreOffice with special naming posible?
Hi Michael, Fridrich, *, Am Dienstag, 29. März 2011, 10:55:53 schrieb Michael Meeks: Hi Andreas, On Mon, 2011-03-28 at 20:39 +0200, Andreas Mantke wrote: the development of LibreOffice and its features are growing every day and week ;-) Exciting isn't it :-) yeah :-) In my opinion it would be a good idea to have a special build (nightly build or something similar) with a special naming, maybe LibO-Future This is happening already but only for Mac and Linux. http://dev-builds.libreoffice.org/daily/ I got it. But it works not like I expected. If I try to install it on my openSUSE 11.3-x64 many packages conflicts with those from 3.3.2 (e.g. the impress-rpm). It would be usefull, if the daily build could be installed in parallel to the last stable version. That makes it easier for testing and evaluating regressions etc. Fridrich is working on getting the existing Windows tinderboxes to up-load their result - having said that, master is not building that well on Windows currently :-) so that it is posible to install that build in parallel on your PC. Such a build could help QA-People and documentation writers for example to get in touch with the new features and report bugs early. The parallel install is something I know nothing about on Windows; and may involve some development work - if so, it'd be great to have help on that. I would be satisfied, if it works on Linux ;-) Regards, Andreas -- ## Developer LibreOffice ## Freie Office-Suite für Linux, Mac, Windows ## http://LibreOffice.org ## Support the Document Foundation (http://documentfoundation.org) ## Meine Seite: http://www.amantke.de ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Bug 35673 depends on bug 35602, which changed state. Bug 35602 Summary: .docx no comments saved https://bugs.freedesktop.org/show_bug.cgi?id=35602 What|Old Value |New Value Resolution||DUPLICATE Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSoc] Students and mentors, apply now!
(2011/03/29 14:18), Cedric Bosdonnat wrote: * Mentors need to apply now too in order to be able to participate in the applications selection process after that period. I have applied as a mentor. id = vuhung ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Development-/Future-Builds of LibreOffice with special naming posible?
Andreas Mantke wrote (29-03-11 17:40) This is happening already but only for Mac and Linux. http://dev-builds.libreoffice.org/daily/ It would be usefull, if the daily build could be installed in parallel to the last stable version. That makes it easier for testing and evaluating regressions etc. For me, this info has always worked: http://wiki.services.openoffice.org/wiki/Run_OOo_versions_parallel I would be satisfied, if it works on Linux ;-) And me having Linux 32 bits (deb, or rpm) Cor -- - http://nl.libreoffice.org - giving openoffice.org its foundation :: The Document Foundation - ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] replace Saxon/J XSLT extension functions with libxslt/c++ equivalent
Am 29.03.11 15:15, schrieb Jan Holesovsky: Hi Peter, On 2011-03-29 at 11:37 +0200, Jan Holesovsky wrote: How wrong I was ;-) - the best is expose the Inflater / Deflater classes as you did, so I pushed your stuff as it was. :-) Only did a small follow-up hack, and that was moving them to ZipUtils namespace, so that they do not pollute the global one. I also added the library definition for Windows, hopefully it will work there. Thanks a lot Thank you again! :-) Hey, thank you for reviewing that! Peter Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Purpose of easy task 'Get rid of sal_uLong' ?
Hi Lubos, On Tue, 29 Mar 2011 15:11:44 +0200 Lubos Lunak l.lu...@suse.cz wrote: Why not? I generally just need a number and int fits that perfectly. I really don't care how many bits it has as long as it works and don't need to wonder if I should use sal_Int32, sal_UInt16, sal_Int64 or whatever. For example you will create a lot of needless work for people who want to get the code warning-free (which is a valid goal, see Caolans commits for example) because of comparisons between different types (signed/unsigned or different ranges). Almost every numeric data you have in the codebase has been marshalled once, or will be (it was either loaded, will be saved or is available though the API). All these points are friction points. And LO is not a small project and will be ported to new platforms. And the next platform will not be different that the previous ports, there will always be some trouble. Using non sal_* numeric types is just asking for trouble in the long run, because some day you will need to marshall that stuff somewhere. How is that different from having different sal_whatever in the code and marshalling with that? sal_* Types are typedefs and can be changed as a whole or be defined different on different (or new) platforms. That eases a lot of trouble. It's more typing and it's foreign to anybody not used to the codebase. Sure, that may sound like silly reasons Indeed. And its wrong too. As unsigned int is for example a lot longer to type than sal_*. Also its really not something only LO does: http://www.gtk.org/api/2.6/glib/glib-Basic-Types.html http://doc.qt.nokia.com/4.7-snapshot/datastreamformat.html Also, you are not making it easier for the newcomers at all: If he gets a sal_* type from one source and a creatively selected other type from another source, you are making life hard for him. If he gets the same types there is no trouble for him. Besides, I have already seen a number of commits changing BOOL/sal_Bool to bool, so at least some people seem to see the value of abandoning the sal_ types where not necessary. That is a Strawman: I was talking about numeric types and numeric types only, which the bool/BOOL/sal_Bool/FASTBOOL madness is completely different from. Also sal_Bool and bool map perfectly and the same way on all platforms(*). That is not at all the case for numeric types (for example long). Someone writing code on *nix might easily store a sal_uInt64 in a long on 64-Bit and create havoc on Windows in interesting and hard to reproduce ways. Best Regards, Bjoern (*) unless viciously abused. -- https://launchpad.net/~bjoern-michaelsen signature.asc Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [WIP] Remove most of dead code in libs-core
Hi,
pushed the framework part. Again a lot of files changed their place so
it was quite a lot of work to apply the patch. Additionally I removed
lots of dates, comments above removed commented methods, {} not needed
anymore after the if () has gone and changed
if ( bState = sal_True) to if ( bState == sal_True) in test.cxx.
Hope you don't mind that the additional changes are pushed under your name?
What about these comments (task.hxx):
/*-//**
@short-
@descr-
@seealso-
@seealso-
@param-
@return-
@onerror-
*//*-*/
I'd suggest to remove them...
Christina
Am 20.03.2011 00:52, schrieb Xisco Faulí:
Here we go with the first round of patches.
Whitespaces are not deleted anymore and all the bogus have been
deleted. Everything builds allright.
Part 1 --
http://dl.dropbox.com/u/1274885/removed-commented-code-part1.tar.gz
I'll post the second part soon
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] subsequenttests now run headless
Hi all, subsequenttests runs headless now by default and seem to be very stable that way. These tests are very good to parallelize. On my machine I see: subsequenttests [ __.oO SCK ] loaded modules: chart2 comphelper configmgr dbaccess editeng forms framework linguistic ooo padmin qadevOOo sal sfx2 sot svl svtools svx sw toolkit tools ucb unotools unoxml vbahelper xmloff real17m51.257s user3m6.720s sys 0m18.650s subsequenttests -j [ __.oO SCK ] loaded modules: chart2 comphelper configmgr dbaccess editeng forms framework linguistic ooo padmin qadevOOo sal sfx2 sot svl svtools svx sw toolkit tools ucb unotools unoxml vbahelper xmloff real5m33.555s user3m4.350s sys 0m18.020s In these five and a half minutes, you get a _lot_ of code coverage. If you want to run the tests without headless, you do a: subsequenttests gb_JunitTest_HEADLESS= and get all the blinkenlights. Be aware that by doing that you are not only testing LibreOffice, but also stress testing your X11 implementation and WM (esp. when you enable parallelization). ;) Best Regards, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] First-time build fails
Hi Joe, Joe Hillenbrand wrote: Hi all, I am trying to build libo from git source for the first time, so that I can apply to GSoC. I am able to make just fine, but when I try to make dev-install it fails (please see the errors at the end of the email). Please pardon my ignorance, -Joe Hillenbrand Did you run make 21 | tee build1.log before trying to run make dev-install? Andy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] removing the executable mode from some source files
Hi there, On Tue, 2011-03-29 at 14:05 -0300, saito wrote: Here is a list of files that are not supposed to have executable bit set on Unix/Linux. Great; so I cleaned it up a bit more - the unxlngi6.pro files are build intermediates that are not in git; I removed .bat and .btm files from the list (perhaps that exec bit helps for them on Windows). It is ordered by extension and is just a filtered list from the output of the tool I have sent before. Yep; otherwise, this was ideal - I batched these up into groups, and pushed ~10k file executable bits removals in your name :-) That leaves under two thousand left; it might be nice to manually check re-visit these extensions to ensure that there are none that truly need a executable bit set, and send a cleaned up and updated list (?) Thanks ! :-) Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [tdf-discuss] Re: EasyHack on EasyHacks
On Tue, 2011-03-29 at 22:51 +0200, Bjoern Michaelsen wrote: Hi Nuno, First - great work :-) and good to have you helping out here Nuno. Second - this is a page of incredible importance to developers, and as such - any changes to it need to be discussed and decided on the developer list. Thirdly - I'd like to see it changed only after more thought, and I am out tomorrow so can't be involved in that. I made an attempt to split it under my user pages, http://wiki.documentfoundation.org/User:Njsg/EasyHacksIndex Looking great IMHO! Personally I dislike pages that fragment and hide the information I'm looking for behind some high-latency switch-tab / middle-click / re-load-page stuff. They also tend to make it much harder to search within that category quickly (ctrl-F style), now I have to do ctrl-F/alt-N/switch-tab/ctrl-F/alt-N/alt-N/switch-tab/ctrl-F etc. etc. I agree the information is not as cleanly structured as it could be; and that perhaps a separate index to the same data might be good (though it might also have maintenance problems). Possibly just re-structuring that page would help. It is. Anyone vetoing Nunos great work? Opinions? (I am hoping for a lot of +1s here for your effort.) IMHO the discuss list is the wrong venue for any number of +1s when it comes to developer focused marketing / infrastructure. I'm also fairly convinced that at a first approximation sorting by easy-ness is what people most want when they hit that thing; rather than by more vague categories. Then again - if we have -enough- tasks in each of the categories perhaps it could be made to fly, but ... needs thought. I'd also like to hear from some of our new developers that liked that page - again, on the dev list. HTH, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] subsequenttests now run headless
On Tue, Mar 29, 2011 at 10:22:43PM +0200, Bjoern Michaelsen bjoern.michael...@canonical.com wrote: subsequenttests runs headless now by default and seem to be very stable that way. These tests are very good to parallelize. On my machine I see: Hi, I'm sure this is a newbie question, but what is the relation between unit tests, smoketest and subsequenttests? If I'm not mistaken, the later two is integration test, while cppunit is about lowlevel unit testing - does that mean that we want to get rid of smoketest in the long run? Thanks. pgpMiJcP14ehg.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] First-time build fails
Joe Hillenbrand wrote: So you think build1.log is the missing file? Not the log file but the other part. Last weekend I did a clean build and forgot to run that step, the full process is at [1], and got the same error when I tried to do the make dev-install. I got pointed to [1] when I joined the dev list and wanted to build for my own use. [1] http://wiki.documentfoundation.org/Development/How_to_build Another suggestion is that when replying to messages in the dev list is to use Reply all to keep the thread in the list. Andy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [tdf-discuss] Re: EasyHack on EasyHacks
On Tue, Mar 29, 2011 at 4:04 PM, Michael Meeks michael.me...@novell.com wrote: I'd also like to hear from some of our new developers that liked that page - again, on the dev list. The easy hack page has hugely grown since I started. I guess that is a good thing, but in my opinion it's current form is not very practical nor inviting. I think that grouping easy-hack by 'nature' and then by difficulty do make sense. Difficulty is a very subjective measure, and something that is a 'easy gui hack' for someone may be a daunting task for someone else... when I was parsing this list I would first look at the title, then the skill required and _then_ the degree of difficulty announced - mostly to verify my first impression based on the previous 2 items. So, I do like the 'nature' oriented classification proposed, but maybe we could keep a one line overview of each task with a link for a dedicated page per task That way, a given task can be expended with as much information as needed without flooding the main page, including volunteer's progress report, declaration of intent and/or questions/answer section to clarify the task if need be. That way the main page still give a global overview of all easy-hack, but become much more readable... If the task are limited, on the main page to a one-liner, then the ToC doesn't have to be 3 pages long Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] (no subject)
Very impressed with the programme (or should I say 'program' ), but, as a newcomer to Linux, I found the installation procedure a pain in the butt. Brian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] subsequenttests now run headless
Hi Miklos, lengthy answer to your innocent question ahead -- brace for impact. On Tue, 29 Mar 2011 23:18:20 +0200 Miklos Vajna vmik...@frugalware.org wrote: I'm sure this is a newbie question, but what is the relation between unit tests, smoketest and subsequenttests? There is a whole lot of terms flying around wrt tests, which is rather unfortunate. There are: - unit tests (the real ones, somewhere in $MODULE/qa) - smoketest (in module smoketestoo_native) - subsequent tests including: - complex tests (mostly in $MODULE/qa/complex) - unoapi tests (in $MODULE/qa/unoapi and qadevOOo) - testtool tests Unittests are run during the build. The smoketest tests the full product so that it doesnt crash right upon start or while loading a document. It requires a full installation for that of course. Subsequent tests do various additional tests that require a full installation. Complex tests are manually written realworld scenarios that use a feature in the way intended on development. Unoapi tests just do some very basic tests (setting a value, reading the value back, checking if it is the same). They are no useful realworld scenarios and highly synthetic. And finally there is the VclTesttool which simulates mouseclicks and GUI events and hooks into the UI toolkit. If I'm not mistaken, the later two is integration test, while cppunit is about lowlevel unit testing - does that mean that we want to get rid of smoketest in the long run? IMHO not at all. The list above is exactly in order of the test usefulness (with real unittests being the most useful). However, the real unittests are also the hardest to get: Some parts of code require so much infrastructure (UNO, Config, GUI etc.) that you need to do a lot of trickery to test it without a complete installation. That is unfortunate because: - it is a lot of extra work. - the trickery might be fragile and hard to maintain. The best solution would be to refactor your code to real small and nifty units. But that is a lot of code change and for refactoring you might want to have tests before you change (and break) everything. This is were the complex tests come in IMHO: You first write a complex test running real world scenarios on your code area. It requires a full installation, but still it is better than manually testing over and over again. Then you refactor mercilessly, kill of useless dependencies and end up with a nifty small unit worth the name unit. Then you write a small unit test for the code that can be run during the build, which should be easy (or at least easier) now. You leave the complex test around because it doesnt hurt to have it (if it fails, it might be worth a look). The unoapi tests are still somewhat useful because of their code coverage. But I dont think it is worth it to invest too much time into writing new ones, when we can better write real unittest (and complex tests -- to get real unittests). As for the testtool tests -- I dont find them worth the effort. They are very fragile (because they rely on timing and things like that) and rarely are helpful in triaging bugs. There is one scenario I remember them to be useful though: When migrating modules to the new build system, they found missing resources sometimes. But that is a rather special case and not really worth the long runtime and fragile results. Running smoketest before pushing a nontrivial changeset is a good idea. tl;dr: I dont think we should get rid of subsequenttests or smoketest as of now as they are cheap to keep. But whenever it is possible to write real unit tests that should be preferred. Best Regards, Bjoern P.S.: BTW not all subsequent tests are in Java, some are in C++ too. Thus also not every cppunit test is run during the build currently. P.P.S.: Here is how I personally usually run the tests: unit tests: on every build (doh) smoketest: before nontrivial pushes along with manual testing after a major rebuild because of changes on master (some branch integration for example) complex tests: on the module I code along with manual testing twice a week (before going to lunch) on releases (starting with 3.4.X) unoapi tests: as complex tests testtool tests: not at all unless forced by some policy -- https://launchpad.net/~bjoern-michaelsen signature.asc Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Staroffice module build fail
Hello there, After ./g pull -r and doing make clean make build failed for dbaccess and starmath modules. I referred the wiki and did a prtial build for dbacess which came out clean. But still I've got build issue with starmath module related to some JUnit test. please have a look here http://pastebin.com/7XPGxB3B Thanks and regards -- Anurag Jain Final yr B.Tech CSE SASTRA University Thanjavur(T.N.)-613402 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Staroffice module build fail
On Wed, 2011-03-30 at 05:21 +0530, Anurag Jain wrote: Hello there, After ./g pull -r and doing make clean make build failed for dbaccess and starmath modules. I referred the wiki and did a prtial build for dbacess which came out clean. But still I've got build issue with starmath module related to some JUnit test. Hello Anurag, So, I personally don't know what exactly the problem is there, but you might try passing --without-junit to the configure script (or autogen.sh script) to see if that lets you disable those junit tests. I remember having issues with junit myself, and my build script contains --without-junit which solved the problem for me. Worth a try. HTH, Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSoc] Students and mentors, apply now!
On 03/29/2011 12:18 AM, Cedric Bosdonnat wrote: Hi all, this reminder is for both the students and the mentors: please apply now on Google Melange. http://www.google-melange.com/gsoc/org/show/google/gsoc2011/libreoffice * Students applications can be filed from March 28th (yesterday) to April 8th (less than 2 weeks). * Mentors need to apply now too in order to be able to participate in the applications selection process after that period. Don't hesitate to tell me if you have any trouble to apply. Hello, I will be applying to LibreOffice for GSoC. I haven't put together my proposal yet, because the wiki says that applicants need to fix a bug to be accepted. I'm still working on the Print current page Easy Hack, but I have midterms this week, so I haven't had much time to dedicate to that this week. My question is this: Should I finish fixing my bug before making and submitting my proposal, or should I submit my proposal and just get my bug fixed ASAP? Thanks in advance -- Skyler Hawthorne a.k.a. Cosmopolitan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Purpose of easy task 'Get rid of sal_uLong' ?
On Tue, Mar 29, 2011 at 6:51 PM, Bjoern Michaelsen bjoern.michael...@canonical.com wrote: Maybe we should use those even in sal/types.h by now? sure, modulo a bit of work to teach windows about standards... as C99 is way to recent of a standard for MS to have implemented it... Poor things, surely no sane person could imagine that they'd turn around on a dime and add a pair of include file in their distribution in less than 10 years and 4 major release of their C/C++ compiler. they simply don't have the ressource to do that : http://connect.microsoft.com/VisualStudio/feedback/details/345360/visual-c-should-support-c99 I think we could use boost/cstdint.hpp or http://code.google.com/p/msinttypes/source/browse/trunk/stdint.h or http://www.azillionmonkeys.com/qed/pstdint.h or write our own I still have some fear in me from all the places in sw and elsewhere, where I saw stuff like 0x and intended use of integer overflow. But maybe thats just paranoia. I would argue that that practice is broken. use instead UINT[16/32/64/]_MAX (or SAL_MAXUINT[8/16/32/64] if you _must_ use SAL_ :-) ) note that a quick grep in writer give 74 match for , about half of them being clearly irrelevant to this discussion. So I think that soothing your paranoia with regard to this particular point should not be that hard to do :-) Globally it is a bit harder to count as there are quite a bit of noise, but there are indeed quite a few magic constant. It is almost never ok to use actual numbers a in a source, all these 0x to indicate 'not-positioned' or 'not-found', should really be some kind of defined symbol. For example, starmath/inc/dialog.hxx define #define CATEGORY_NONE 0x which is almost right, it should be #define CATEGORY_NONE SAL_MAX_UINT16 Actually in general I'm indeed concerned with: #define FOO almost always that should be #define FOO ((numeric_type_cast)) Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
