how to acquire an ScDocument reference "from scratch"

Hello List,

I'm trying to get hold of an ScDocument "from scratch".  I have naively
attempted to replicate another section of code, but for the life of me
can't figure out what I'm missing.  My code crashes with a SIGSEGV on
this line:

aDocShell = new ScDocShell();

I think I've boiled it down to a null pointer dereference (see attached,
please), but that implies the existing code is incorrect, which I'm not
yet ready to admit.

Any pointers very welcome.

Thanks,

Kevin

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Hello Kevin,

2011/11/23 Kevin Hunter <[hidden email]>:
Can you explain in a bit more detail what you want to do. You can't
just create a new ScDocShell, you always need to do some
initialisation before. Depending on what you want to do you should not
need to create the ScDocShell yourself.

Regards,
Markus
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

At 7:56pm -0500 Wed, 23 Nov 2011, Markus Mohrhard wrote:
> Can you explain in a bit more detail what you want to do. You can't
> just create a new ScDocShell, you always need to do some
> initialisation before. Depending on what you want to do you should
> not need to create the ScDocShell yourself.

Well, I'd like to have some way of creating a new ScDocument.  In
looking through sc/qa/unit/ucalc.cxx, it /appears/ that all I need do is:

m_xDocShRef = new ScDocShell(
    SFXMODEL_STANDARD
  | SFXMODEL_DISABLE_EMBEDDED_SCRIPTS
  | SFXMODEL_DISABLE_DOCUMENT_RECOVERY
);

I'm clearly missing something, likely in regards to
BootstrapFixture::setUp() and ScDLL::Init().  Help!

Thanks,

Kevin
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Wed, 2011-11-23 at 20:33 -0500, Kevin Hunter wrote:
> At 7:56pm -0500 Wed, 23 Nov 2011, Markus Mohrhard wrote:
> > Can you explain in a bit more detail what you want to do. You can't
> > just create a new ScDocShell, you always need to do some
> > initialisation before. Depending on what you want to do you should
> > not need to create the ScDocShell yourself.
>
> Well, I'd like to have some way of creating a new ScDocument.

And could you tell us what you need to do that for?  Providing more
details as to what area of code you are modifying, including the file
name and class name (if applicable), and what end result you want to see
would give us more context of what you are doing.

Kohei

--
Kohei Yoshida, LibreOffice hacker, Calc

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

2011/11/24 Kevin Hunter <[hidden email]>:
Still my question. Ehat do you want to do. We have several ways to
create a new document depending on the place in the code. The method
used in ucalc is nothing we should do outside of a unit test. So you
please explain with some sentences for what you need a new document,
which part of the code you want to modify and why you think that you
need to create an own ScDocShell?

Regards,
Markus
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

At 8:45pm -0500 Wed, 23 Nov 2011, Kohei Yoshida wrote:
This was answered and responded to out-of-band as follows:

I wanted to create an ScDocument to work with in a new test file.  I was
thinking in terms of test driven development and having some tests such
that I could execute only them, as something akin to:

$ make  just_this_set_of_tests

I was educated that because each separate test file needs an entirely
separate invocation of soffice (and all that that entails), this is not
a desirable avenue for the general use-case of running all tests.  LO is
nowhere near able to work in a TDD environment, and, short of much
rewriting, will not be there anytime soon.  Thus, the answer to my
question boiled down to: during development or bug hunting, comment out
all superfluous tests in another, existing test file.

Kevin
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Wed, 2011-11-23 at 16:59 -0500, Kevin Hunter wrote:
Probably boils down to needing the call to
comphelper::setProcessServiceFactory in
test::BootstrapFixtureBase::setUp in
unotest/source/cpp/bootstrapfixturebase.cxx

C.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Hi Kevin,

On Thu, 2011-11-24 at 01:05 -0500, Kevin Hunter wrote:
> I wanted to create an ScDocument to work with in a new test file.  I was
> thinking in terms of test driven development and having some tests such
> that I could execute only them, as something akin to:
>
> $ make  just_this_set_of_tests

        Ah - you just want to run a smaller set of tests, and faster than
running all of the 'make unittest' changes in master ?

> I was educated that because each separate test file needs an entirely
> separate invocation of soffice (and all that that entails),

        Nah - it's not soffice; but a unit test linked with some biggish chunks
of code.

> Thus, the answer to my question boiled down to: during development
> or bug hunting, comment out all superfluous tests in another, existing
> test file.

        I would suggest two things:

        a) we can add an environment variable and check for it in
           gnumake such that only one set of tests is run:

        make TEST_SUBSET=filters-test unitcheck

        or somesuch.

        b) we could (try) to hack cppunit to stringify the test-name in
           it's macros; so you could specify just one test to run:

        make TEST_SUBSET=filters-test TESTS=testDatabaseRanges unitcheck

        And do some cunning filtering somewhere there - might require more
cppunit patching / tweaking [ if that is not there already, perhaps it
is ].

        But of course; the easy & quick way out is to comment these out I
guess.

        HTH,

                Michael.

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On 11/24/2011 12:25 PM, Michael Meeks wrote:
If you want to execute the CppUnit tests in some file like
sc/CppunitTest_sc_filters_test.mk you can

   cd sc && make -r
"${SRC_ROOT?}/workdir/${INPATH?}/CppunitTest/sc_filters.test.test

Stephan
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

At 6:25am -0500 Thu, 24 Nov 2011, Michael Meeks wrote:
> On Thu, 2011-11-24 at 01:05 -0500, Kevin Hunter wrote:
>> I wanted to create an ScDocument to work with in a new test file. I
>> was thinking in terms of test driven development and having some
>> tests such that I could execute only them, as something akin to:
>>
>> $ make  just_this_set_of_tests
>
> Ah - you just want to run a smaller set of tests, and faster than
> running all of the 'make unittest' changes in master ?

Sorry for the late response ... in short, exactly.  More specifically, I
wish there were a way to run exactly and only one test (i.e. a single
::testFunction()).  Instead, they're currently bundled together in
various files such that I can do what Stephan suggested ($ make
/path/to/test.test).  I would find it helpful if in the development
cycle, there were a way to run just what I want to run, to finer
granularity than a file.

As already pointed out to me, this is currently time-infeasible for the
common use case that compiles the whole project (given that each test
would have to be _individually_ linked and executed); regardless, all I
really wanted was a howto for my own personal machine in terms of the
boiler plate I was apparently missing to accomplish this for the tests
and LO code on which I'm currently working.  Having this would enable me
to drastically reduce my compile wait time.  On my old hardware, that
translates a 15-20s turnaround time about 3-4s.

Thus, commenting out was suggested, and is currently what I'm working with.

Thanks,

Kevin
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On Thu, 2011-12-08 at 13:05 -0500, Kevin Hunter wrote:
> > Ah - you just want to run a smaller set of tests, and faster than
> > running all of the 'make unittest' changes in master ?
>
> Sorry for the late response ... in short, exactly.  More specifically, I
> wish there were a way to run exactly and only one test (i.e. a single
> ::testFunction()).

        Fine, sounds like a worthy goal. I suggest you hack cppunit to add some
magic macro wrappers to stringify the function name, and allow some
run-time parameter that will filter the tests immediately on entry down
to the one you want.

> Having this would enable me to drastically reduce my compile wait time.
> On my old hardware, that translates a 15-20s turnaround time about 3-4s.

        Sure, sounds good - so hack it up :-) patches gratefully recieved to
improve unit tests; for extra bonus points ;-) when a test fails it
should print the command-line to get just that one test running.

        Also - it seems Noel Grandin is working on a (somewhat different)
re-hash of the note storage thing in his tree - worth not treading on
his feet there; but of course the more unit tests for note stuff the
merrier.

        ATB,

                Michael.

--
[hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

At 4:47pm -0500 Thu, 08 Dec 2011, Michael Meeks wrote:
> On Thu, 2011-12-08 at 13:05 -0500, Kevin Hunter wrote:
>> More specifically, I wish there were a way to run exactly and only
>> one test (i.e. a single ::testFunction()).
>
> Fine, sounds like a worthy goal. I suggest you hack cppunit to add
> some magic macro wrappers to stringify the function name, and allow
> some run-time parameter that will filter the tests immediately on
> entry down to the one you want.

Oh!  I didn't realize cppunit was open for hacking from our end.  Let's
see ... looking through that directory then ... the basic workflow is to
write a patch to apply before we compile Cppunit, yes?

> Also - it seems Noel Grandin is working on a (somewhat different)
> re-hash of the note storage thing in his tree - worth not treading
> on his feet there; but of course the more unit tests for note stuff
> the merrier.

Cheers.  If Noel is working on that, then I'll turn my attention to
something along the test lines.  Given my $REAL_LIFE constraints, maybe
what I work on should fall farther from the LO critical path ...

Thanks,

Kevin
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

I don't have any unit tests in my tree yet, so feel free to go ahead.

-- Noel Grandin

Kevin Hunter wrote:

At 4:47pm -0500 Thu, 08 Dec 2011, Michael Meeks wrote:

On Thu, 2011-12-08 at 13:05 -0500, Kevin Hunter wrote:

More specifically, I wish there were a way to run exactly and only
one test (i.e. a single ::testFunction()).

Fine, sounds like a worthy goal. I suggest you hack cppunit to add
some magic macro wrappers to stringify the function name, and allow
some run-time parameter that will filter the tests immediately on
entry down to the one you want.

Oh!  I didn't realize cppunit was open for hacking from our end.  Let's see ... looking through that directory then ... the basic workflow is to write a patch to apply before we compile Cppunit, yes?

Also - it seems Noel Grandin is working on a (somewhat different)
re-hash of the note storage thing in his tree - worth not treading
on his feet there; but of course the more unit tests for note stuff
the merrier.

Cheers.  If Noel is working on that, then I'll turn my attention to something along the test lines.  Given my $REAL_LIFE constraints, maybe what I work on should fall farther from the LO critical path ...

Thanks,

Kevin
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

---

Disclaimer: http://www.peralex.com/disclaimer.html


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

At 7:03am -0500 Fri, 09 Dec 2011, Noel Grandin wrote:
> I don't have any unit tests in my tree yet, so feel free to go
> ahead.

Ah, what I'm going to be working on is the implementation of Cppunit for
us such that we can have some niceties that would have helped me
tremendously while getting up to speed with Calc and the ScPostIt
stuffs.  Not unit tests per se.

I did write a couple of unit tests in that patch I sent your way a week
ago, and some comments on some of the unit tests that I thought needed
to be added, if you'd like to harvest so of that thought-process.

Kevin
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On 12/09/2011 12:55 PM, Kevin Hunter wrote:
Not really.  Keep in mind that LO's configure has --with-system-cppunit,
which people do make use of.  The existing patches fix bugs or warnings,
and should have been upstreamed if there were a living upstream.  They
do not introduce features.

That said, AFAIU, xUnit in general and CppUnit in particular does
support the notion of finer-grained test suites, allowing one to execute
only a subset of a given set of tests.  Never looked into how that
works, though.

Stephan
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

At 8:05am -0500 Fri, 09 Dec 2011, Stephan Bergmann wrote:
> On 12/09/2011 12:55 PM, Kevin Hunter wrote:
>> Oh! I didn't realize cppunit was open for hacking from our end.

> Not really. Keep in mind that LO's configure has
> --with-system-cppunit, which people do make use of. The existing
> patches fix bugs or warnings, and should have been upstreamed if
> there were a living upstream. They do not introduce features.

Oh.  Back to square 1.5.

> That said, AFAIU, xUnit in general and CppUnit in particular does
> support the notion of finer-grained test suites, allowing one to
> execute only a subset of a given set of tests. Never looked into how
> that works, though.

Thank you.  I was hoping as much.  In any event, gots to study what's
available to me with my couple hours a week ...

Cheers,

Kevin
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

If there is no living upstream, surely we shouldn't let the current state of affairs hold us back?
Why not add the features we need, and remove --with-system-cppunit?

I see unit-testing as a project-internal thing anyhow, and it's a build-time dependency, not a run-time dependency, so I don't see --with-system-cppunit as being that important.
But I could be wrong?

I'd just hate to see our unit-testing efforts held back by the lack of an upstream....

Stephan Bergmann wrote:

On 12/09/2011 12:55 PM, Kevin Hunter wrote:

At 4:47pm -0500 Thu, 08 Dec 2011, Michael Meeks wrote:

On Thu, 2011-12-08 at 13:05 -0500, Kevin Hunter wrote:

More specifically, I wish there were a way to run exactly and only
one test (i.e. a single ::testFunction()).

Fine, sounds like a worthy goal. I suggest you hack cppunit to add
some magic macro wrappers to stringify the function name, and allow
some run-time parameter that will filter the tests immediately on
entry down to the one you want.

Oh! I didn't realize cppunit was open for hacking from our end. Let's

Not really.  Keep in mind that LO's configure has --with-system-cppunit, which people do make use of.  The existing patches fix bugs or warnings, and should have been upstreamed if there were a living upstream.  They do not introduce features.

That said, AFAIU, xUnit in general and CppUnit in particular does support the notion of finer-grained test suites, allowing one to execute only a subset of a given set of tests.  Never looked into how that works, though.

Stephan
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

---

Disclaimer: http://www.peralex.com/disclaimer.html


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On 12/09/2011 03:26 PM, Noel Grandin wrote:
> If there is no living upstream, surely we shouldn't let the current
> state of affairs hold us back?
> Why not add the features we need, and remove --with-system-cppunit?

My hope would be that CppUnit already caters for our needs.  But sure,
if not, extending CppUnit would be a sensible approach.  Would best be
done by reviving upstream, however, I'd say.

Stephan
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice