On 04/05/2012 02:23 PM, Stephan Bergmann wrote:
On 04/03/2012 02:27 PM, Stephan Bergmann wrote:
I have a vague idea of placing yet another cppuhelper bootstrap
mechanism next to the existing ones, which will internally use
completely different (read: cheap) mechanisms to set up a component
Hi there,
I lost your mail with the rather nice re-write you're working on there,
but I attach a simple hack I've been working on instead.
The basic idea is to push the iteration over directories down into the
stoc/ code instead of having it in the cppuhelper code. That lets us
On Thu, 2012-04-05 at 00:56 +0200, Enrico Weigelt wrote:
Just hacked up a little poc script wheich generates a static
data structure from the *.rdb xml files.
Of course, far away from usable, but should at least
demonstrate the idea.
Output looks reasonable, of course php is not an
[putting libreoffice@ back on cc]
On 04/04/2012 11:05 PM, Tomas Hlavaty wrote:
Hi Stephan,
First of all, remember that we have two different scenarios where we
want to replace the old binary rdb format with something else, once
for type information and once for service information.
I see.
Not in the case of services rdbs. The information stored there is a
mapping between (a) service and singleton names (as documented in
UNOIDL), (b) the implementation names of entities implementing those
singletons and services, and (c) the software artefacts that contain
those
On 04/03/2012 11:13 PM, Tomas Hlavaty wrote:
Some time ago we discussed something along the lines of modernizing rdb
related code.
I wrote an IDL parser and the java generator unoidl2java is getting
almost complete. I have a few small patches lined up but I'd like to
get the java generator as
On 04/04/2012 01:44 PM, Enrico Weigelt wrote:
Can anybody please point me to the code which is loading
the .rdb files ?
stoc/source/simpleregistry/, but see my vague idea in another part of
this tread for work that is currently under way in this area.
Stephan
On 04/04/2012 01:44 PM, Enrico Weigelt wrote:
Can anybody please point me to the code which is loading
the .rdb files ?
stoc/source/simpleregistry/, but see my vague idea in another part
of this tread for work that is currently under way in this area.
thx, brought me some bits nearer to
snip /
Just hacked up a little poc script wheich generates a static
data structure from the *.rdb xml files.
Of course, far away from usable, but should at least
demonstrate the idea.
cu
parse_registry
Description: application/php
___
LibreOffice
Or, for files that are static in a distributed LO (i.e. not modified
at installation. even less at run-time), process them into source
code that set up the structures as much as possible at compile-time
already?
Even better!
There seems to be a lot currently dynamic data, that could be
On 04/02/2012 11:06 PM, Michael Meeks wrote:
Digging through the string logs, trying to make sense of the extremely
intense thrash around this SINGLETON/ stuff, I was curious to get rather
deep stacks, cf. appended trace.
AFAICS the purpose of this code is mostly to turn a
Hi,
Yes, this is indeed a bit of a tragedy. The relevant UNO types and
services bootstrapping code is very old, and concepts are tightly
knit together there, and whenever you want to change something you risk
backwards incompatibility.
Backwards compatibility to whom ? Binaries ? Source ?
Hi Enrico,
On Tue, 2012-04-03 at 05:15 +0200, Enrico Weigelt wrote:
What would be ultimately nice would be to rid ourselves of this
XRegistry 'stuff' and have a simple XML file, read into some simple
structures, and added to a couple of hashes for the common lookup
patterns we want.
Hi Enrico,
On Tue, 2012-04-03 at 11:04 +0200, Enrico Weigelt wrote:
Yes, this is indeed a bit of a tragedy. The relevant UNO types and
services bootstrapping code is very old, and concepts are tightly
knit together there, and whenever you want to change something you risk
backwards
Hi Stephan,
On Tue, 2012-04-03 at 10:41 +0200, Stephan Bergmann wrote:
Yes, this is indeed a bit of a tragedy. The relevant UNO types and
services bootstrapping code is very old, and concepts are tightly knit
Thanks for your lovely detailed write-up, I'm just editing it into the
On 04/03/2012 01:57 PM, Michael Meeks wrote:
On Tue, 2012-04-03 at 10:41 +0200, Stephan Bergmann wrote:
That way, you have a chance of surviving the process. But you also
pile up guilt.
Lol :-) well, we managed to keep it going, despite the guilt pile
somehow :-) I guess in this case
Hi Stephan,
thanks for the very informative long post!
Some time ago we discussed something along the lines of modernizing rdb
related code.
I wrote an IDL parser and the java generator unoidl2java is getting
almost complete. I have a few small patches lined up but I'd like to
get the java
Hi there,
Digging through the string logs, trying to make sense of the extremely
intense thrash around this SINGLETON/ stuff, I was curious to get rather
deep stacks, cf. appended trace.
AFAICS the purpose of this code is mostly to turn a pretty simple,
pretty flat XML structure,
On Mon, 2012-04-02 at 22:06 +0100, Michael Meeks wrote:
I'm also curious if the performance issue here (this code features
reasonably high on a startup profile IIRC) might be related to the
multiple '.rdb' file code (?).
Following that line of attack, with every string
What would be ultimately nice would be to rid ourselves of this
XRegistry 'stuff' and have a simple XML file, read into some simple
structures, and added to a couple of hashes for the common lookup
patterns we want. Is there any chance of doing that separately, so we
can sever the
What would be ultimately nice would be to rid ourselves of this
XRegistry 'stuff' and have a simple XML file, read into some simple
structures, and added to a couple of hashes for the common lookup
patterns we want.
Or, for files that are static in a distributed LO (i.e. not modified
21 matches
Mail list logo
