Re: [Libreoffice] uno discoverability

[Stephan Bergmann]

On 11/17/2011 06:55 PM, Michael Meeks wrote:

On Wed, 2011-11-16 at 14:16 +0100, Stephan Bergmann wrote:

throw FooException("Failure loading file '%S' code %d",

...

This (as well as cooking something up using OSL_FORMAT) would have the
disadvantage that it potentially converts data from UTF-16 to char
("%S") and then from char to UTF-16 (as UNO Exception's Message is of
type rtl::OUString).


True - but by the time we throw an exception, efficiency already goes
to hell in a hand-cart (as it were) ;-) we start straining mind and limb
to find unwind info records, infer types, understand what is on the
stack and how to clean it up etc. An extra allocation or two isn't going
to hurt.


Its not any time/space overhead that makes me feel uneasy here, but the 
lack of elegance and of consistency.  We could come up with a mechanism 
now for composing exception messages using the new sal/log.h SAL_STREAM, 
like


  throw RuntimeException(rtl::OUString(SAL_STREAM("cannot open " << 
url).c_str()));


or even simplify that further with an additional macro like

  throw RuntimeException(SAL_STRING("cannot open " << url));

Then again, the standard LO idiom to create a literal rtl::OUString is 
rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("...")), and the standard LO 
idiom to compose a string from to substrings is s1 + s2.  This is not 
only so for the special case of composing messages of UNO exceptions, it 
is so across all the code.  It is somewhat long-winded and ugly, but 
within today's constraints we won't be able to come up with something 
that is substantially better with regard to space/time complexity.


If we would optimize the "user experience" of composing exception 
messages (where the resulting space/time overhead would be harmless), we 
would pessimize the standard idiom, relative to it, even more.  People 
would probably start to use the "optimization" in general code, too.


In short, I would not over-emphasize the issue of ugly string 
composition in current LO, and rather live with it until we come up with 
something substantially better, benefiting all use cases, in LO 4.



   We'll probably wait until either all relevant compilers
support C++11's new character types, or we incompatibly change
rtl::OUString to UTF-8 (whatever happens first).


Which would be wonderful :-) I'm cheering that on. Having said that -
if we go with gcc for cross-compile to Windows too, does that help us ?


The "Unicode String Literals" row at 
 suggests so.  But then 
again, we still depend on MSVC for Windows builds as of now.



For types.rdb, my vision is to either use an XML format or, IMO even
better, a new .idl format that is (a) less verbose (why the heck all
those ";" in there, etc.?) and (b) does not rely on a preprocessor.
Then, a types.rdb could effectively be just one large .idl file.


Great. Of course, types.rdb being huge and empty would be fine if we
didn't load and read it at startup a lot ;-) IIRC one use-case there was
the lack of in-lined property Name/Value struct ->  any conversions, so:

pArg.Name = rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "foo" ));
pArg.Value<<= ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "baa" ));

Is nice&  efficient, and in-line-able; until that pArg ends up inside
an Any itself - at which point we suck in types.rdb, start loading type
data, inferring C++ structure offsets, and so on - just to allocate and
construct the local Any (which I assume we could do&  in-line at compile
time).


The Any operator <<= for complex structures uses a generic 
(introspective) approach.  I guess that was mainly done to keep the code 
small (esp. given that anything else would have had to be inline-only).



Then again - perhaps we use introspection for something else more
serious on startup, or perhaps I'm out of date on this. Do you have a
feel for whether it is just a few silly cases like this that we could
work around ? or if there is some deep reason that types.rdb should be
necessary at startup ?


Any sort of bridging probably requires introspection already (and Kay's 
purpose-bridges are still used early on, IIRC).  Getting types.rdb out 
of the picture here could be done either via "comprehensively compiled" 
.hpp headers (that contain the type information in C code; but that 
would probably bloat the code if done everywhere) or replacing generic 
(introspective) algorithms with per-type-templated ones (that would 
again bloat the code).  Difficult to tell whether true benefit lurks 
there...


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

Re: [Libreoffice] uno discoverability

[Michael Meeks]

Hi Stephan,

On Wed, 2011-11-16 at 14:16 +0100, Stephan Bergmann wrote:
> > throw FooException("Failure loading file '%S' code %d",
...
> This (as well as cooking something up using OSL_FORMAT) would have the 
> disadvantage that it potentially converts data from UTF-16 to char 
> ("%S") and then from char to UTF-16 (as UNO Exception's Message is of 
> type rtl::OUString).

True - but by the time we throw an exception, efficiency already goes
to hell in a hand-cart (as it were) ;-) we start straining mind and limb
to find unwind info records, infer types, understand what is on the
stack and how to clean it up etc. An extra allocation or two isn't going
to hurt.

> It seems like all attempts at true improvement in this area always 
> collide with rtl::OUString being neither UTF-8 (i.e., layout compatible 
> with plain char) nor wchar_t (at least on Linux etc.; and using GCC's 
> -fshort-wchar would not help, as it breaks binary compatibility with 
> libstdc++).

Yep; although getting the most-common cases of having slower, but
easy-to-use, and small-object-code helpers for printf & exceptions would
be really helpful IMHO :-)

>   We'll probably wait until either all relevant compilers 
> support C++11's new character types, or we incompatibly change 
> rtl::OUString to UTF-8 (whatever happens first).

Which would be wonderful :-) I'm cheering that on. Having said that -
if we go with gcc for cross-compile to Windows too, does that help us ?

> For types.rdb, my vision is to either use an XML format or, IMO even 
> better, a new .idl format that is (a) less verbose (why the heck all 
> those ";" in there, etc.?) and (b) does not rely on a preprocessor. 
> Then, a types.rdb could effectively be just one large .idl file.

Great. Of course, types.rdb being huge and empty would be fine if we
didn't load and read it at startup a lot ;-) IIRC one use-case there was
the lack of in-lined property Name/Value struct -> any conversions, so:

pArg.Name = rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "foo" ));
pArg.Value <<= ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( "baa" ));

Is nice & efficient, and in-line-able; until that pArg ends up inside
an Any itself - at which point we suck in types.rdb, start loading type
data, inferring C++ structure offsets, and so on - just to allocate and
construct the local Any (which I assume we could do & in-line at compile
time).

Then again - perhaps we use introspection for something else more
serious on startup, or perhaps I'm out of date on this. Do you have a
feel for whether it is just a few silly cases like this that we could
work around ? or if there is some deep reason that types.rdb should be
necessary at startup ?

All the best,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

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

Re: [Libreoffice] uno discoverability

[Stephan Bergmann]

On 11/16/2011 11:25 AM, Michael Meeks wrote:

IMHO we need to make that code efficient by having a var-args style
helper:

throw FooException("Failure loading file '%S' code %d",
   aOUStr.pData, nCode);

That would also be fairly code size efficient as well vs. the
heavy-lifting, and big string-buffer construction madness :-)


This (as well as cooking something up using OSL_FORMAT) would have the 
disadvantage that it potentially converts data from UTF-16 to char 
("%S") and then from char to UTF-16 (as UNO Exception's Message is of 
type rtl::OUString).


It seems like all attempts at true improvement in this area always 
collide with rtl::OUString being neither UTF-8 (i.e., layout compatible 
with plain char) nor wchar_t (at least on Linux etc.; and using GCC's 
-fshort-wchar would not help, as it breaks binary compatibility with 
libstdc++).  We'll probably wait until either all relevant compilers 
support C++11's new character types, or we incompatibly change 
rtl::OUString to UTF-8 (whatever happens first).



It'd be great to use a more pleasant format like Stephan's new configmr
XML - if we can get the performance we need there; and of course add the
API docs to some parallel docs file, only loaded when needed
(interactively by developers). But of course it's a good idea.


For types.rdb, my vision is to either use an XML format or, IMO even 
better, a new .idl format that is (a) less verbose (why the heck all 
those ";" in there, etc.?) and (b) does not rely on a preprocessor. 
Then, a types.rdb could effectively be just one large .idl file.


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

Re: [Libreoffice] uno discoverability

[Michael Stahl]

On 16/11/11 11:25, Michael Meeks wrote:


On Tue, 2011-11-15 at 20:34 +0100, Michael Stahl wrote:



in a lot of UNO API implementations the only form of error reporting
used is "throw RuntimeException;", which leaves (as you correctly note)
a lot to be desired in terms of usability for the hapless API user.


Quite :-)


EasyHack filed:
https://bugs.freedesktop.org/show_bug.cgi?id=42982


this definitely ought to be an easy hack, as putting a more helpful
error message in there can really be done by anyone: patches welcome.


IMHO we need to make that code efficient by having a var-args style
helper:

throw FooException("Failure loading file '%S' code %d",
   aOUStr.pData, nCode);

That would also be fairly code size efficient as well vs. the
heavy-lifting, and big string-buffer construction madness :-)


Stephan recently added an OSL_FORMAT, that should be useful here...

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

Re: [Libreoffice] uno discoverability

[Michael Meeks]

On Tue, 2011-11-15 at 20:34 +0100, Michael Stahl wrote:
> > com.sun.star.uno.RuntimeException:
> >
> >  >>>

Presumably python is showing you the message embedded in the exception
(which is empty ?) or do we miss even that ?

> in a lot of UNO API implementations the only form of error reporting 
> used is "throw RuntimeException;", which leaves (as you correctly note) 
> a lot to be desired in terms of usability for the hapless API user.

Quite :-)

> this definitely ought to be an easy hack, as putting a more helpful 
> error message in there can really be done by anyone: patches welcome.

IMHO we need to make that code efficient by having a var-args style
helper:

throw FooException("Failure loading file '%S' code %d",
   aOUStr.pData, nCode);

That would also be fairly code size efficient as well vs. the
heavy-lifting, and big string-buffer construction madness :-)

On Tue, 2011-11-15 at 20:09 +0100, Michael Stahl wrote:
> but AFAIK currently the extensive API documentation that is in the
> IDL files is only available on the web; it ought to be possible to
> store that in the rdb files somehow and then have some thingy in UNO
> that allows programmatic access, so things like help in python can
> extract it?  hmm... maybe there's an easy-hack somewhere in there...

Certainly rather an 'advanced' easy hack but worth doing :-) I would be
-extremely- skeptical of putting more data into types.rdb though - that
is still using the hideous 'store' code that everyone should be eager to
see the back of, and which wastes space and I/O left and right like
nobody's business :-) Even after some work to shrink that we have
(commas added to size for effect):

-rw-r--r-- 1 michael users 10,649,600 Nov 11 20:44 offapi.rdb
-rw-r--r-- 1 michael users 13,647,356 Nov 16 10:21 offapi.rdb.regview-output
-rw-r--r-- 1 michael users  1,834,902 Nov 11 20:44 offapi.rdb.gz
-rw-r--r-- 1 michael users  1,375,023 Nov 16 10:21 offapi.rdb.regview-output.gz

It'd be great to use a more pleasant format like Stephan's new configmr
XML - if we can get the performance we need there; and of course add the
API docs to some parallel docs file, only loaded when needed
(interactively by developers). But of course it's a good idea.

ATB,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

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

Re: [Libreoffice] uno discoverability

[Laurent Godard]

Hi all

Thanks to Thorsten pointing the old (2004) pyUno

I revived it recently and made it workable again, removing some
unnecessary things but it is in
my plans to make it cleaner as a lot of things is outdated (eg. old OOo
links to idl reference - need to be updated). I hope to find time in a
near future

btw, here is the version i'm actally using

the basic use to instrospect an object at runtime is rather simple

inside a pyUNo script :

from pyXray import XrayBox
XrayBox(self.ctx, theUnoObject)

self.ctx, is the context

Feel free to include it in LibreOffice sources if you find it usefull,
provided the licence is ok (otherwise, i may ask my old employer,
but there should be no problem, just let me know)

I really hope that it will be usefull for someone (as an introspection
tool or sample of pyUno script). Let me know and feel free to ask if any
question

HTH

Laurent


# (C) Copyright 2004 Indesko SARL 
# Author: Laurent Godard  (old email)
# Laurent Godard 
# based on Xray Basic macro from Bernard Marcelly
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as published
# by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
# 02111-1307, USA.
#

import uno, unohelper

# UNO GUI toolkit
from com.sun.star.awt.WindowClass import TOP, SIMPLE
from com.sun.star.awt.PushButtonType import STANDARD as standard
from com.sun.star.awt.PushButtonType import OK as ok
from com.sun.star.awt.PushButtonType import CANCEL as cancel
from com.sun.star.awt.PushButtonType import HELP as help
from com.sun.star.awt.TextAlign import CENTER as center
from com.sun.star.awt.TextAlign import LEFT as left
from com.sun.star.awt.TextAlign import RIGHT as right

# used UNO listeners
from com.sun.star.awt import XActionListener
from com.sun.star.awt import XItemListener
from com.sun.star.awt import XMouseListener

# UNO typeClass handling for instrospection
from com.sun.star.uno.TypeClass import VOID as unoVoid
from com.sun.star.uno.TypeClass import CHAR as unoChar
from com.sun.star.uno.TypeClass import BOOLEAN as unoBoolean
from com.sun.star.uno.TypeClass import BYTE as unoByte
from com.sun.star.uno.TypeClass import SHORT as unoShort
from com.sun.star.uno.TypeClass import UNSIGNED_SHORT as unoUnsignedShort
from com.sun.star.uno.TypeClass import LONG as unoLong
from com.sun.star.uno.TypeClass import UNSIGNED_LONG as unoUnsignedLong
from com.sun.star.uno.TypeClass import HYPER as unoHyper
from com.sun.star.uno.TypeClass import UNSIGNED_HYPER as unoUnsignedHyper
from com.sun.star.uno.TypeClass import FLOAT as unoFloat
from com.sun.star.uno.TypeClass import DOUBLE as unoDouble
from com.sun.star.uno.TypeClass import STRING as unoString
from com.sun.star.uno.TypeClass import TYPE as unoType
from com.sun.star.uno.TypeClass import ANY as unoAny
from com.sun.star.uno.TypeClass import ENUM as unoEnum
from com.sun.star.uno.TypeClass import TYPEDEF as unoTypeDef
from com.sun.star.uno.TypeClass import STRUCT as unoStruct
from com.sun.star.uno.TypeClass import UNION as unoUnion
from com.sun.star.uno.TypeClass import EXCEPTION as unoException
from com.sun.star.uno.TypeClass import SEQUENCE as unoSequence
from com.sun.star.uno.TypeClass import ARRAY as unoArray
from com.sun.star.uno.TypeClass import INTERFACE as unoInterface
from com.sun.star.uno.TypeClass import SERVICE as unoService
from com.sun.star.uno.TypeClass import MODULE as unoModule
from com.sun.star.uno.TypeClass import INTERFACE_METHOD as unoInterfaceMethod
from com.sun.star.uno.TypeClass import INTERFACE_ATTRIBUTE as unoInterfaceAttribute
from com.sun.star.uno.TypeClass import UNKNOWN as unoUnknown
from com.sun.star.uno.TypeClass import PROPERTY as unoProperty
from com.sun.star.uno.TypeClass import CONSTANT as unoConstant
from com.sun.star.uno.TypeClass import CONSTANTS as unoConstants
from com.sun.star.uno.TypeClass import SINGLETON as unoSingleton

# file utilities
from os import sep
from os import mkdir

# path logo
from os import path
from sys import modules
logo_path = path.dirname (path.abspath (modules["pyXray"].__file__))
#logo_path = logo_path + sep + 'logo.jpg'
logo_path=""

#Browser for SDK Querying
from os import environ as OS_ENVIRON
#if sep == '/':
# problem on invoking konqueror
# http://aspn.activestate.com/ASPN/Mail/Message/python-Tutor/2184915
#if OS_ENVIRON['BROWSER']=='kfmclient openProfile webbrowsing':
#OS_ENVIRON['BROWSER']='konqueror'
import webbrowser
my_browser = webbrowser.get()

##

Re: [Libreoffice] uno discoverability

[Michael Stahl]

On 15/11/11 19:57, Kevin Hunter wrote:

Is it similarly as convoluted and difficult to have an explanation with,
say, RuntimeExceptions? For instance, with a document with only one
sheet, one should not be able to remove the last sheet, right?

 >>> doc.Sheets.removeByName('Sheet1')
---
com.sun.star.uno.RuntimeException Traceback (most recent call last)

/home/kevin/ram/temoa/branches/tmpp/ in ()

com.sun.star.uno.RuntimeException:

 >>>

Which is correct of course, but not terribly elucidating (note the empty
trailing colon). Would this be a simple case of putting an RTL...string
in removeByName in docuno.cxx?


in a lot of UNO API implementations the only form of error reporting 
used is "throw RuntimeException;", which leaves (as you correctly note) 
a lot to be desired in terms of usability for the hapless API user.


this definitely ought to be an easy hack, as putting a more helpful 
error message in there can really be done by anyone: patches welcome.


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

Re: [Libreoffice] uno discoverability

[Michael Stahl]

On 15/11/11 18:17, Thorsten Behrens wrote:

Kevin Hunter wrote:

One of the things that I find extremely frustrating is the lack of
discoverability from within the Python context.


Hi Kevin,

beyond the pure python functionality, that would indeed benefit from
some insightful help texts, there's introspection for UNO.


but AFAIK currently the extensive API documentation that is in the IDL 
files is only available on the web; it ought to be possible to store 
that in the rdb files somehow and then have some thingy in UNO that 
allows programmatic access, so things like help in python can extract 
it?  hmm... maybe there's an easy-hack somewhere in there...


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

Re: [Libreoffice] uno discoverability

[Kevin Hunter]

At 12:00pm -0500 Tue, 15 Nov 2011, Michael Meeks wrote:

there are some real issues here, inasmuch that it can't be known
until run-time what interfaces are supported, and lots of type
information disappears down the toilet around queryInterfaces and
'any's. Unfortunately, this makes the API hardly fit-for-purpose for
simple scripting use, but extending the API to make it fit (eg. by
having a flat set of implementation interfaces - complete with
default parameter types etc.) is conceptually problematic ;-)


Is it similarly as convoluted and difficult to have an explanation with, 
say, RuntimeExceptions?  For instance, with a document with only one 
sheet, one should not be able to remove the last sheet, right?


>>> doc.Sheets.removeByName('Sheet1')
---
com.sun.star.uno.RuntimeException Traceback (most recent call last)

/home/kevin/ram/temoa/branches/tmpp/ in ()

com.sun.star.uno.RuntimeException:

>>>

Which is correct of course, but not terribly elucidating (note the empty 
trailing colon).  Would this be a simple case of putting an RTL...string 
in removeByName in docuno.cxx?


Cheers,

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

Re: [Libreoffice] uno discoverability

[Thorsten Behrens]

Kevin Hunter wrote:
> One of the things that I find extremely frustrating is the lack of
> discoverability from within the Python context.
>
Hi Kevin,

beyond the pure python functionality, that would indeed benefit from
some insightful help texts, there's introspection for UNO. See this
announcement for a useful tool:

 http://markmail.org/message/kt2va3mc3ggwk4e2

It seems the original download link is dead, I found a random
version on my disk & uploaded it here:

 http://users.freedesktop.org/~thorsten/src/pyXray.zip

HTH,

-- Thorsten


pgpuNVGe1eXPR.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] uno discoverability

[Michael Meeks]

Hi Kevin

On Tue, 2011-11-15 at 11:49 -0500, Kevin Hunter wrote:
> One of the things that I find extremely frustrating is the lack of
> discoverability from within the Python context.  The interactive shell
> (IPython package and IPython.embed() ) is an amazing tool for debugging
> and data structure discovery (with the power of tab-completion, among
> other things), but when most functions are hardly documented, it
> reduces the  discoverability to educated guesswork and actual C++
> code inspection.

Well - there are some real issues here, inasmuch that it can't be known
until run-time what interfaces are supported, and lots of type
information disappears down the toilet around queryInterfaces and
'any's. Unfortunately, this makes the API hardly fit-for-purpose for
simple scripting use, but extending the API to make it fit (eg. by
having a flat set of implementation interfaces - complete with default
parameter types etc.) is conceptually problematic ;-)

> which is hardly useful to know what loadComponentFromURL actually does.

But for the few bits of C++ stuff that we wrap of course it can be
easily documented. Patches most welcome.

> 2. If there is not an intentional reason, would drive by documentation 
> efforts (as I discover them, and certainly to be improved, but better 
> than nothing), be generally appreciated?

Of course ! :-)

All the best,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

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

[Libreoffice] uno discoverability

[Kevin Hunter]

Hullo List,

I'm working on a school project that involves UNO with Python (talking 
to LO from an external invocation of Python).  One of the things that I 
find extremely frustrating is the lack of discoverability from within 
the Python context.  The interactive shell (IPython package and 
IPython.embed() ) is an amazing tool for debugging and data structure 
discovery (with the power of tab-completion, among other things), but 
when most functions are hardly documented, it reduces the 
discoverability to educated guesswork and actual C++ code inspection.


1. Is there an intentional reason for a lack of this sort of builtin 
documentation?


For example, within the Python shell:

>>> import uno
[...boiler plate to setup desktop variable from UNO...]
>>> help(desktop.loadComponentFromURL)
Help on PyUNO_callable object:

class PyUNO_callable(object)
 |  Methods defined here:
 |
 |  __call__(...)
 |  x.__call__(...) <==> x(...)

>>>

which is hardly useful to know what loadComponentFromURL actually does.

2. If there is not an intentional reason, would drive by documentation 
efforts (as I discover them, and certainly to be improved, but better 
than nothing), be generally appreciated?


Thanks,

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