> "Michael" == Michael Meeks writes:
Michael> I guess we should add an 'easy hack' for some gdb / python
Michael> goodness to expand / annotate Basic stack frames prettily in
Michael> the debugger too ;-) [ we can but wish ].
FWIW Phil Muldoon is working on a new gdb/Python feature called "f
On 12/02/2011 12:59 PM, Michael Meeks wrote:
IMHO it is not much effort to fold that remote-control-ness into a few
lines of code inside soffice.bin itself that we could run with a test
parameter, and rid ourselves of the separate remote-control process and
make things easier to debug (mo
On Fri, 2011-12-02 at 11:55 +0100, Stephan Bergmann wrote:
> It loads the document and executes the contained BASIC code via a remote
> css.frame.XComponentLoader.loadComponentFromURL/css.frame.XNotifyingDispatch.dispatchWithNotification
>
> sequence. Might actually also work for Python script
On 12/02/2011 11:39 AM, Bjoern Michaelsen wrote:
On Fri, Dec 02, 2011 at 10:14:59AM +, Michael Meeks wrote:
Cool. Please lets do that by having some magic parameter to
soffice.bin: eg. --load-run-test=/foo/baa/test.py or somesuch, so that
it is all executed in the same process: rathe
On Fri, Dec 02, 2011 at 10:14:59AM +, Michael Meeks wrote:
> Cool. Please lets do that by having some magic parameter to
> soffice.bin: eg. --load-run-test=/foo/baa/test.py or somesuch, so that
> it is all executed in the same process: rather than doing this
> hard-to-debug remote-control
On Thu, 2011-12-01 at 23:50 +0100, Bjoern Michaelsen wrote:
> Well, more tests are always good! If you could write some proof-of-concept
> (e.g. one test running against an soffice instance) I would help integrating
> that into gbuild and from that point on it would be pretty easy to add lots
> mo
Hi Laurent,
On Thu, Dec 01, 2011 at 07:57:48AM +0100, Laurent Godard wrote:
> > So, who would be willing to invest time if it were written in python?
> > With C++ at least Markus is already showing interest.
>
> I must admit that i would be more comfortable writing tests in python
> than c++
>
>
>From the point of view of porting LibreOffice (suitable parts of it)
to new and exciting platforms, unit tests in C++ only are definitely
preferred.
--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailma
On Wed, 2011-11-30 at 23:16 +0100, Bjoern Michaelsen wrote:
> On Wed, Nov 30, 2011 at 04:20:28PM -0500, Kohei Yoshida wrote:
> > Let me cast my vote for the use of C++ too. Markus has already outlined
> > the benefit of using C++ for debugging point of view.
>
> Oh, I have no opposition against
Hi all
> So, who would be willing to invest time if it were written in python?
> With C++ at least Markus is already showing interest.
I must admit that i would be more comfortable writing tests in python
than c++
and could then help for some
Laurent
On Thu, 2011-12-01 at 01:17 +0100, Bjoern Michaelsen wrote:
> Hi,
>
> On Wed, Nov 30, 2011 at 06:22:11PM -0500, Kohei Yoshida wrote:
> > So, this suggests that we first write test in python, then later rewrite
> > it in C++, or would python tests stay in python?
>
> It wouldnt scare me if quite a
Hi,
On Wed, Nov 30, 2011 at 06:22:11PM -0500, Kohei Yoshida wrote:
> So, this suggests that we first write test in python, then later rewrite
> it in C++, or would python tests stay in python?
It wouldnt scare me if quite a few would not be promoted to C++, so I wouldnt
force people to do rewrite
On Thu, 2011-12-01 at 00:15 +0100, Bjoern Michaelsen wrote:
> Hi Kohei,
>
> On Wed, Nov 30, 2011 at 05:35:33PM -0500, Kohei Yoshida wrote:
> > Also, by "funky garbage collection" if you are referring to the
> > ref-counted cssu::Reference memory management that UNO API uses (since C
> > ++ doesn't
Hi Kohei,
On Wed, Nov 30, 2011 at 05:35:33PM -0500, Kohei Yoshida wrote:
> Also, by "funky garbage collection" if you are referring to the
> ref-counted cssu::Reference memory management that UNO API uses (since C
> ++ doesn't even have memory management natively), doesn't python have
> the same i
Hi Bjoern,
On Wed, 2011-11-30 at 23:16 +0100, Bjoern Michaelsen wrote:
> Oh, I have no opposition against writing C++ tests. When have the
> infrastructure for that in the build system and it certainly has advantages
> once the test is there. However, as Michael pointed out a dynamic language has
Hi Kohei,
On Wed, Nov 30, 2011 at 04:20:28PM -0500, Kohei Yoshida wrote:
> Let me cast my vote for the use of C++ too. Markus has already outlined
> the benefit of using C++ for debugging point of view.
Oh, I have no opposition against writing C++ tests. When have the
infrastructure for that in
On Wed, 2011-11-30 at 19:13 +0100, Markus Mohrhard wrote:
> >> hmmm i wonder if it would make sense to have UNO API tests written
> >> in Python: that should be much easier on the eyes than boilerplate-heavy
> >> C++/Java... and i think there is a need for tests at the UNO API level
> >> no ma
Hey,
> Looks very promising. Just one minor comment, I would move away from the
> "unoapi" name (and corresponding qa/unoapi directory). The concept of the
> qadevOOo unoapi tests was to use more-or-less generic code to test all the
> interfaces of all the UNO objects exposed by OOo (so that all
Hey,
>
> IMHO the pragmatic solution to this is to run them as subsequentests when
> dependencies are getting ugly. Writing them in sane C++ is of course better
> that using Junit, but nontrivial tests depending on the full product is not a
> big bug IMHO. I think by now pretty much everyone build
Hey,
thanks a lot for your answers.
2011/11/30 Michael Stahl :
>> - having test files instead of code that fills the cells make it
>> easier to use the test data outside of the test ( e.g. debugging a
>> problem, having a testdocument with known result for some actions)
>
> hmm... am somewhat uns
On Wed, Nov 30, 2011 at 06:24:19PM +0100, Michael Stahl wrote:
> On 30/11/11 14:59, Markus Mohrhard wrote:
> > The test itself is a bit ridiculous
>
> so it is a faithful reproduction of the qadevOOo tests :)
One can consider qadevOOo to be fuzzy testing with a minimal intelligence RNG.
> > - d
On 30/11/11 14:59, Markus Mohrhard wrote:
> after we enabled subsequenttests in sc again we have now a lot of
> failing tests. Instead of debugging the java based tests I plan to
> rewrite them in c++ and fix them during that.
>
> The test itself is a bit ridiculous
so it is a faithful reproduct
On 11/30/2011 02:59 PM, Markus Mohrhard wrote:
Do you have comments or suggestions?
Looks very promising. Just one minor comment, I would move away from
the "unoapi" name (and corresponding qa/unoapi directory). The concept
of the qadevOOo unoapi tests was to use more-or-less generic code t
Hi Markus,
On Wed, 2011-11-30 at 14:59 +0100, Markus Mohrhard wrote:
> after we enabled subsequenttests in sc again we have now a lot of
> failing tests. Instead of debugging the java based tests I plan to
> rewrite them in c++ and fix them during that.
Wow - that's lovely :-)
> I have a
Hey guys,
after we enabled subsequenttests in sc again we have now a lot of
failing tests. Instead of debugging the java based tests I plan to
rewrite them in c++ and fix them during that.
I have attached a first patch that is only porting one part of a
failing test to c++. It would be nice if so
25 matches
Mail list logo
