: 500 Internal Server Error

[Stephan Bergmann]

Fetching 
 
(as linked from e.g., 
) 
results in just a "500 Internal Server Error" response:



$ curl -i 
https://wiki.openoffice.org/wiki/Documentation/DevGuide/Scripting/Writing_Macros
HTTP/1.0 500 Internal Server Error
Date: Thu, 03 Jan 2019 09:42:52 GMT
Server: Apache/2.4.18 (Ubuntu)
X-Content-Type-Options: nosniff
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Just a little side note on the scripting framework ...

[Stephan Bergmann]

On 14/06/18 20:54, Rony G. Flatscher (Apache) wrote:

A friend has LibreOffice installed (due to a better mail-merge-support I 
understand) and I came up
with a script to help her taking advantage of the writer component. The script 
is written in ooRexx
for which I authored an OOo scripting provider that works on OOo, making ooRexx 
an additional macro
language for OOo.

Now, installing that package on her machine the scripts work from outside of LO 
flawlessly, however
ooRexx does not get registered as another macro language in LO (missing from the 
"Macro" menu).
After researching this issue for quite some time now, it turns out that LO 
removed a method in
ClassLoaderFactory and changed the signature of the remaining method by 
removing the throws clause,
causing a need to compile the script language provider against OOo's 
ScriptFramework.jar, if the
script provider is to run against OOo, and having the need to compile it 
separately against LO's
version of ScriptFramework.jar, which is a PITA.


Running the original ScriptProviderForooRexx.oxt in LO should be fixed 
with  "Restore binary 
compatibility for ClassLoaderFactory" (see commit message for details). 
I hope to get that still backported into upcoming LO 6.0.5.


Thanks for reporting!

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 'LO URI 101'

[Stephan Bergmann]

Peter, I'm a bit puzzled that you got hold of that email directed at me, 
and forwarded it here including the review link.  My understanding is 
that FOSDEM staff asks presenters to review their own presentations, and 
that that task should be left to presenters, not random people that get 
hold of that (hard-to-guess) link by whatever means.


Stephan


On 05.02.2018 23:08, Peter Kovacs wrote:

Do we have the same implementation? ( I fear so)
Where is it?

 Forwarded Message 
Subject: Your FOSDEM 2018 talk titled 'LO URI 101'
Date: Mon, 5 Feb 2018 20:27:05 +0100
From: nore...@fosdem.org
To: Stephan Bergmann <sberg...@redhat.com>
CC: responsible for track Open Document Editors 
<ode-devroom-mana...@fosdem.org>




Hello!

The video of your FOSDEM 2018 talk titled

LO URI 101

is now available for review at:

[...]

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Query on C++ UCB XInteractionHandler interface - is it possible to have/write a non-UI-based interface to respond on?

[Stephan Bergmann]

On 02/02/2016 09:56 PM, John Dougrez-Lewis wrote:

I'm looking at coding a pet C++ project to use the Content Brokers provided
by the UCB/UNO subsystem.

I note that the XInteractionHandler-derived classes can be used to handle
responses to supply e.g. user/pswd details for Authentication etc.

 From a class diagram I've found, it looks like the XInteractionHandler may
be a UI/frame type class.

If I want to respond programmatically from my console (non-GUI) program, is
there a way of doing this - either by writing my own non-UI response
handlers or by using pre-existing handlers (if they exist)? Is there a
non-UI route in to providing a required response?

Any pointers/links would be gratefully appreciated.


Yeah, you need to implement your own XInteractionHandler.  The general 
one in uui/source/interactionhandler.cxx is indeed designed for GUI 
interaction, but there is e.g. 
desktop/source/lib/lokinteractionhandler.cxx in the LibreOffice code 
base that is an example of a more programmatic handling of interaction 
requests.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Incompatible change of oslFileError?

[Stephan Bergmann]

$ svn diff -c1705196 sal/inc/osl/file.h
Index: sal/inc/osl/file.h
===
--- sal/inc/osl/file.h  (revision 1705195)
+++ sal/inc/osl/file.h  (revision 1705196)
@@ -132,6 +132,7 @@
osl_File_E_USERS,
osl_File_E_OVERFLOW,
osl_File_E_NOTREADY,
+osl_File_E_LOCKED,
osl_File_E_invalidError,/* unmapped error: always last 
entry in enum! */
 osl_File_E_TIMEDOUT,
osl_File_E_NETWORK,


Are you sure that this incompatible change is worth it?  By placing the 
new enumerator somewhere in the middle of the existing enum, you 
unnecessarily not only break compatibility with older versions of AOO, 
but also with other OOo derivatives.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Extension Manager Add Crashes

[Stephan Bergmann]

On 04/02/2014 01:20 AM, Steele, Raymond wrote:

Following up again with more information. At runtime, when the
RuntimeException is thrown on line 249

nFunctionIndex = 3

pTypeDescr-nMapFunctionIndexToMemberIndex = 0


That means that the given pTypeDescr has not been initialized fully (see 
the comment about the three levels of initialization for 
typelib_InterfaceTypeDescription in typelib/typedescription.h), 
presumably because there was some error finding the UNOIDL type data 
(either compiled comprehensively into the cppumaker-generated headers, 
or obtained from .rdb files).  The initialization of 
nMapFunctionIndexToMemberIndex would happen in 
typelib_typedescription_initTables called from complete (both in 
cppu/source/typelib/typelib.cxx).


Stephan

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [tdf-discuss] macro compatibility between LO and AOO?

[Stephan Bergmann]

On 03/06/2013 09:00 AM, Andre Fischer wrote:

On 05.03.2013 18:29, Michael Meeks wrote:

On Tue, 2013-03-05 at 09:19 -0800, Fred Ollinger wrote:

I was wondering if libreoffice and aooo can't agree to
some basic level api for 3rd party developers?

It's an interesting discussion; but in the absence of any concrete
code, patches etc. it doesn't belong on the libreoffice developer list;


Talking about a concrete change is a good idea so please let me ask a
question similar to one I asked at FOSDEM but to which I got no clear
answer.  Probably because of my bad English that is even worse when I
speak it.

Stephan Bergman talked about Well-typed UNO, something that would
involve incompatible changes to the UNO API.  I would like to know if
LibreOffice and Apache OpenOffice could work together on this.  I am
just talking about changes on API level not the underlying
implementation.  That would be something that both projects would do
independently.


First off, depends on what you mean with UNO API.  One customary 
meaning is the set of UNOIDL entities (mainly) declared in udkapi/ and 
offapi/ .idl files.  (LibreOffice tries to meticulously track any 
incompatible changes it does there, see e.g., the API Changes section 
at http://www.libreoffice.org/download/4-0-new-features-and-fixes/.)


Another customary meaning is the broader concept of stable interface the 
URE offers, including C ABI, file formats, wire protocols, etc.  My hope 
is that my work on changing the type representation does not affect the 
former, only the latter (file formats etc.).  And, obviously, it will 
need to take care of a backward-compatibility plan.


That said, I can only repeat now what I already said at FOSDEM, that I'm 
going to well document all the changes to any specifications---just like 
I did for any other changes to UNO I did over the last ten years or so. 
 And, as always, any input is highly welcome.


Stephan

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [tdf-discuss] macro compatibility between LO and AOO?

[Stephan Bergmann]

On 03/06/2013 04:47 PM, Andre Fischer wrote:

On 06.03.2013 15:25, Stephan Bergmann wrote:

On 03/06/2013 09:00 AM, Andre Fischer wrote:

On 05.03.2013 18:29, Michael Meeks wrote:

On Tue, 2013-03-05 at 09:19 -0800, Fred Ollinger wrote:

I was wondering if libreoffice and aooo can't agree to
some basic level api for 3rd party developers?

It's an interesting discussion; but in the absence of any concrete
code, patches etc. it doesn't belong on the libreoffice developer list;


Talking about a concrete change is a good idea so please let me ask a
question similar to one I asked at FOSDEM but to which I got no clear
answer.  Probably because of my bad English that is even worse when I
speak it.

Stephan Bergman talked about Well-typed UNO, something that would
involve incompatible changes to the UNO API.  I would like to know if
LibreOffice and Apache OpenOffice could work together on this. I am
just talking about changes on API level not the underlying
implementation.  That would be something that both projects would do
independently.


First off, depends on what you mean with UNO API.  One customary
meaning is the set of UNOIDL entities (mainly) declared in udkapi/ and
offapi/ .idl files.  (LibreOffice tries to meticulously track any
incompatible changes it does there, see e.g., the API Changes
section at
http://www.libreoffice.org/download/4-0-new-features-and-fixes/.)

Another customary meaning is the broader concept of stable interface
the URE offers, including C ABI, file formats, wire protocols, etc. My
hope is that my work on changing the type representation does not
affect the former, only the latter (file formats etc.).  And,
obviously, it will need to take care of a backward-compatibility plan.


By UNO API I mean everything that affects a packaged extension, that
is basically your option B.  So if I understand you correctly that an
extension developer just has to recompile (for a C++ extension) the
source code, repackage the extension and is done (with respect to your
changes).  That sounds good.


It should basically boil down to:  If you include a types.rdb in your 
extension, you can translate it to the new format (or not, in which case 
your extension will work as long as we keep the backwards-compatibility 
code alive).  If you don't include something like that (and that's 
likely most extensions anyway, except for Calc Add-Ons), you don't need 
to do anything at all.



That said, I can only repeat now what I already said at FOSDEM, that
I'm going to well document all the changes to any
specifications---just like I did for any other changes to UNO I did
over the last ten years or so.  And, as always, any input is highly
welcome.


Great. Thanks.
Do you have a pointer to the relevant documentation?


Not yet.  As always, things progress more slowly than I'd hoped.  Stay 
tuned, though.  ;)


Stephan

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org