Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index


On 30/09/14 19:57, nicholas ferguson wrote:
I didn't understand your answer.  I think you said you would not give me the
samples of turning a cppunit test into a standalone executable ..because you
find me unskilled and I would then ask too many questions....  Is it your
english?

No. It's the way we do it in the Open Source world. You are expected to
scratch your own itches, not expect someone else to do it for you.

You haven't made a very good impression here. Okay, so you don't
understand the culture, as you point out there may be some language
issues with people (though not Michael, he speaks English - that is,
REAL English :-)

And that first you want to see some contributions from me, to the
LibreOffice code base.... patches...

Which is what is expected of EVERYONE - you're no different. Or some
other contribution. You're coming over as very demanding, wondering why
nobody else has tried to do the same as you, and expecting them to drop
what they're doing and help you.

Except they're not doing it, because they see no value in doing it! And
why should they waste their valuable time helping someone else, unless
they get a kick out of the sheer act of helping? (Most of us, we're NOT
paid ...)

If I missunderstood your things... can you then tar up an example and send
it to me.

"git pull" is your friend. :-)

You're coming over as a typical American - barging into someone else's
community, expecting them to change everything (that works fine for
them) just to suit you, and then wondering why nobody likes you. I
notice Michael is pretty much the only person in your email threads now
(and I strongly suspect he is PAID to be nice to everyone).

The problem is, as has been pointed out, you are working on a very
thorny issue - build systems. On a system that very few developers use
(Windows). And one that a lot of developers despise and don't want to
touch! A lot of your emails have been right over my head, for one. If
anyone is going to help you, it will take a lot of effort for them to
get up to speed on what you're trying to do. And those people (like
Michael) who are being paid to work on LibreOffice are few in number,
and have a lot of more serious priorities.

I don't want to say "you're on your own", but the reality is that most
people here don't see what you're doing as either important, or of
interest to them. Which means you aren't going to get much help (not
because people don't want to, but because they don't understand what -
or why - you are trying to achieve).

And by coming over as demanding, you just guarantee that the people who
*could* help, will likely tune you out.

Sorry, it's just the way things work :-(

Cheers,
Wol

nick

-----Original Message-----
From: LibreOffice [mailto:libreoffice-bounces@lists.freedesktop.org] On
Behalf Of Michael Meeks
Sent: Tuesday, September 30, 2014 2:54 PM
To: nicholas ferguson
Cc: 'libreoffice-dev'; 'Tor Lillqvist'
Subject: Re: examples to manage docs using LibreOffice as a major component

Hi Nicholas,

On Tue, 2014-09-30 at 13:43 -0400, nicholas ferguson wrote:
you will need to solve a truck-load of bootstrapping issues

Wow.  So in the past seven years, not a single successful attempt

      There are several successful attempts. It is certainly not
impossible to do this. Those attempts have however been done by people
skilled and experienced in the art of wrestling the LibreOffice octopus -
I've personally broken the back of a couple of them. My concern here is not
feasibility in the abstract, only the danger of yet more noisy and
time-consuming remote debugging by mailing-list to no useful purpose - ie.
ending up with something that is not contributed back.

 at transforming a unit test.. and spinning it off into a separate 
executable...a unit test like filters_test.cxx

      Sure - those unit tests run under cppunittester - a separate
executable; as you can see if you read the make output and/or read the
Makefiles ;-) Separately, if you use LibreOfficeKit (under Linux) you can
write your own separate executable (eg. gtktiledviewer) really extremely
easily - though you are limited by the currently exposed API there; failing
that you can link the code into an Android or iOS binary for yet another
incarnation. All of it is do-able (with some hard work).

Hard to believe....  These unit tests have so much functionality 
exposed... some hacker would seem to be naturally attracted to 
transform them into an independent executable.

      They are already executed as shared libraries loaded into a separate
executable post compilation. That however happens inside the warm,
nurturing, and rather painfully constructed context of a live LibreOffice
build tree.

      But of course - as with -any- community / code problem - you are by
far more than welcome to contribute to fixing the situation and meeting your
own need. Indeed, I encourage you to get stuck into fixing whatever
perceived gaps there are, all of us are responsible for improving things
here as their means allow :-) I look forward to your patches.

      ATB,

              Michael.

--
 michael.meeks@collabora.com  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice



_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.