Re: [Mwiki] a massive spam attack. Again

[jan i]

On 7 February 2014 08:48, Andrea Pescetti  wrote:

> On 07/02/2014 jan i wrote:
>
>> May I politely correct you, the idea was NOT to replace the cats. The jira
>> was implemented by the word !
>>
>
> Yes, probably, but it was badly written in my mail that was then copied to
> JIRA. You, and a few others, know that the contents of that JIRA issue
> https://issues.apache.org/jira/browse/INFRA-7173
> result from an afternoon I spent during the holidays trying to put
> together all pending improvement suggestions that had come to us through
> many channels. I didn't take care to put many explanations there.
>
>
>  "Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It
>> doesn't work in several browser configurations, it includes HTTP instead
>> of
>> HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 -> Recommended
>> solution: drop it entirely.  "
>>
>
> That specific suggestion was worded that way because I had read from
> someone (you, maybe?) that with the new improvements there could (just a
> possibility) be the possibility to do without the CAPTCHA. We tried, it
> didn't work and it's no problem to fix it immediately.
>
>
>  That statement is pretty clear, how it can be read as moving to something
>> more effective slips my mind.
>>
>
> I wrote it in a wrong way giving somehow for granted that the MWiki
> upgrade would feature some native anti-spam measures and that those
> measures would suit our purpose. Again, we tried, they didn't, no problem
> to revert quickly.
>
>
>  At this point in time we have several choices:
>> 1) leave the config as it is
>> 2) reinstall cats
>> 3) choose another captcha (in this case we need to decide which one).
>> I am not the one to overrule a community decision (Wiki6), but I will
>> happely implement another community decision.
>>
>
> The current remedy you put in place (no self account creation) will
> obviously work for the time being, thanks for being fast in reacting.
>
> So let's move forward and see what we can implement now: where's the list
> of CAPTCHA solutions on mediawiki.com? Do you have any recommendations
> or, on the contrary, any extensions that Infra is not going to allow?
>

Anything found in
http://www.mediawiki.org/wiki/Extension_Matrix/AllExtensions where
"mediawiki version" allows 1.22 should do.

Especially for CAPTCHA there is one other limitation. The extension must be
self supported, NO calls to third party sites (since this is often used to
collect information).

rgds
jan I.

(By the way, the CAPTCHA issue exploded before I could review all items,
> but thank you for the work on all other pending issues! And let's get this
> one done properly too)
>
>
> Regards,
>   Andrea.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [Mwiki] a massive spam attack. Again

[Andrea Pescetti]

On 07/02/2014 jan i wrote:

May I politely correct you, the idea was NOT to replace the cats. The jira
was implemented by the word !


Yes, probably, but it was badly written in my mail that was then copied 
to JIRA. You, and a few others, know that the contents of that JIRA issue

https://issues.apache.org/jira/browse/INFRA-7173
result from an afternoon I spent during the holidays trying to put 
together all pending improvement suggestions that had come to us through 
many channels. I didn't take care to put many explanations there.



"Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It
doesn't work in several browser configurations, it includes HTTP instead of
HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 -> Recommended
solution: drop it entirely.  "


That specific suggestion was worded that way because I had read from 
someone (you, maybe?) that with the new improvements there could (just a 
possibility) be the possibility to do without the CAPTCHA. We tried, it 
didn't work and it's no problem to fix it immediately.



That statement is pretty clear, how it can be read as moving to something
more effective slips my mind.


I wrote it in a wrong way giving somehow for granted that the MWiki 
upgrade would feature some native anti-spam measures and that those 
measures would suit our purpose. Again, we tried, they didn't, no 
problem to revert quickly.



At this point in time we have several choices:
1) leave the config as it is
2) reinstall cats
3) choose another captcha (in this case we need to decide which one).
I am not the one to overrule a community decision (Wiki6), but I will
happely implement another community decision.


The current remedy you put in place (no self account creation) will 
obviously work for the time being, thanks for being fast in reacting.


So let's move forward and see what we can implement now: where's the 
list of CAPTCHA solutions on mediawiki.com? Do you have any 
recommendations or, on the contrary, any extensions that Infra is not 
going to allow?


(By the way, the CAPTCHA issue exploded before I could review all items, 
but thank you for the work on all other pending issues! And let's get 
this one done properly too)


Regards,
  Andrea.

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

Re: [Mwiki] a massive spam attack. Again

[Helen russian]

2014-02-07 6:22 GMT+06:00 jan i :
>
>
> The configuration is changed so that only sysops can create new accounts.
>

A lot of thank you, Jan! You are our savior.

For last 48 hours 3 wiki admins have deleted more than 1300 spam pages
and blocked more than 800 spammer accounts.


-- 
WBR,
Helen

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

Re: [Mwiki] a massive spam attack. Again

[Dave Fisher]

Hi -

The JIRA is quoted but links or the JIRA ID would be helpful along with a link 
to the ML thread where the decision was made.

It is hard to review this incident without these helpful pointers.

Thanks,
Dave

On Feb 6, 2014, at 4:22 PM, jan i wrote:

> On 7 February 2014 00:45, Rob Weir  wrote:
> 
>> On Thu, Feb 6, 2014 at 6:21 PM, jan i  wrote:
>>> On 6 February 2014 23:42, Andrea Pescetti  wrote:
>>> 
 jan i wrote:
 
> I warned about exactly that, but  I was asked (see JIRAs) to remove the
> cats (captcha). If you read the JIRA (which was watched be several in
> here)
> you will see my warning.
> 
 
 The idea was to replace the CAPTCHA with something better, otherwise we
 can (should) keep the current CAPTCHA and discuss a better solution in
>> the
 meantime.
 
 The cats cause incompatibilities and other issues, but if they are much
 more effective than the replacement let's go back to the cats as soon as
 possible and in the "see what's best to replace them (but something MORE
 effective, not LESS effective!).
 
>>> 
>>> May I politely correct you, the idea was NOT to replace the cats. The
>> jira
>>> was implemented by the word !
>>> 
>>> The exact wording is:
>>> 
>>> "Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It
>>> doesn't work in several browser configurations, it includes HTTP instead
>> of
>>> HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 ->
>> Recommended
>>> solution: drop it entirely.  "
>>> 
>>> That statement is pretty clear, how it can be read as moving to something
>>> more effective slips my mind.
>>> 
>>> later the jira contains:
>>> 
>>> "accessibility suggestion from Tyler (haven't tested MediaWiki
>>> compatibility): there is a website which provides text-based CAPTCHA's in
>>> the form of logic questions, math problems, etc. It provides an XML API.
>>> See http://www.textcaptcha.com/ "
>>> 
>>> Apart from the facts, thats its a suggestion and not a decision (like
>> that
>>> above),  we do not use extensions that are not supported by mediawiki
>>> (meaning downloadable from mediawiki.com and verified for our release).
>> As
>>> a sidenote, that captcha is pretty much the same as the standard which
>> are
>>> active right now. There are quite a lot of captcha´s out there, just
>>> looking at mediawiki.com extensions gives a lot of choises.
>>> 
>>> At this point in time we have several choices:
>>> 1) leave the config as it is
>>> 2) reinstall cats
>>> 3) choose another captcha (in this case we need to decide which one).
>>> 
>>> I am not the one to overrule a community decision (Wiki6), but I will
>>> happely implement another community decision.
>>> 
>> 
>> I hope you can simply restore cats if that can be done without too
>> much trouble.  Then we can discuss further and come to a community
>> decision on what else to do, if anything.  I hope you agree that there
>> is zero benefit to accumulating additional spam while we discuss.
>> 
> 
> Wiki have been upgraded, and respecting the jira I did not move the cat
> extension.
> 
> 
>> Fix the immediate problem, then we can discuss longer term.  This one
>> area that Apache Infra knows how to do well.  They know when it is
>> important to act rather than discuss.  I suggest that this is one of
>> those times.
>> 
> 
> I happen to agree with you, and it has actually not been possible to create
> new accounts for a while now.
> 
> The configuration is changed so that only sysops can create new accounts.
> 
> Now to the other partwe have discussed these issues for quite a long
> time, so it was a fair assumption to accept the jira as the community wish.
> 
> 
>> 
>> Thanks!
>> 
>> -Rob
>> 
>>> rgds
>>> jan I.
>>> 
>>> 
>>> 
>>> 
>>> 
 Regards,
  Andrea.
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org
 
 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
>> 


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

Re: [Mwiki] a massive spam attack. Again

[jan i]

On 7 February 2014 00:45, Rob Weir  wrote:

> On Thu, Feb 6, 2014 at 6:21 PM, jan i  wrote:
> > On 6 February 2014 23:42, Andrea Pescetti  wrote:
> >
> >> jan i wrote:
> >>
> >>> I warned about exactly that, but  I was asked (see JIRAs) to remove the
> >>> cats (captcha). If you read the JIRA (which was watched be several in
> >>> here)
> >>> you will see my warning.
> >>>
> >>
> >> The idea was to replace the CAPTCHA with something better, otherwise we
> >> can (should) keep the current CAPTCHA and discuss a better solution in
> the
> >> meantime.
> >>
> >> The cats cause incompatibilities and other issues, but if they are much
> >> more effective than the replacement let's go back to the cats as soon as
> >> possible and in the "see what's best to replace them (but something MORE
> >> effective, not LESS effective!).
> >>
> >
> > May I politely correct you, the idea was NOT to replace the cats. The
> jira
> > was implemented by the word !
> >
> > The exact wording is:
> >
> > "Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It
> > doesn't work in several browser configurations, it includes HTTP instead
> of
> > HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 ->
> Recommended
> > solution: drop it entirely.  "
> >
> > That statement is pretty clear, how it can be read as moving to something
> > more effective slips my mind.
> >
> > later the jira contains:
> >
> > "accessibility suggestion from Tyler (haven't tested MediaWiki
> > compatibility): there is a website which provides text-based CAPTCHA's in
> > the form of logic questions, math problems, etc. It provides an XML API.
> > See http://www.textcaptcha.com/ "
> >
> > Apart from the facts, thats its a suggestion and not a decision (like
> that
> > above),  we do not use extensions that are not supported by mediawiki
> > (meaning downloadable from mediawiki.com and verified for our release).
> As
> > a sidenote, that captcha is pretty much the same as the standard which
> are
> > active right now. There are quite a lot of captcha´s out there, just
> > looking at mediawiki.com extensions gives a lot of choises.
> >
> > At this point in time we have several choices:
> > 1) leave the config as it is
> > 2) reinstall cats
> > 3) choose another captcha (in this case we need to decide which one).
> >
> > I am not the one to overrule a community decision (Wiki6), but I will
> > happely implement another community decision.
> >
>
> I hope you can simply restore cats if that can be done without too
> much trouble.  Then we can discuss further and come to a community
> decision on what else to do, if anything.  I hope you agree that there
> is zero benefit to accumulating additional spam while we discuss.
>

Wiki have been upgraded, and respecting the jira I did not move the cat
extension.


> Fix the immediate problem, then we can discuss longer term.  This one
> area that Apache Infra knows how to do well.  They know when it is
> important to act rather than discuss.  I suggest that this is one of
> those times.
>

I happen to agree with you, and it has actually not been possible to create
new accounts for a while now.

The configuration is changed so that only sysops can create new accounts.

Now to the other partwe have discussed these issues for quite a long
time, so it was a fair assumption to accept the jira as the community wish.


>
> Thanks!
>
> -Rob
>
> > rgds
> > jan I.
> >
> >
> >
> >
> >
> >> Regards,
> >>   Andrea.
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [Mwiki] a massive spam attack. Again

[Rob Weir]

On Thu, Feb 6, 2014 at 6:21 PM, jan i  wrote:
> On 6 February 2014 23:42, Andrea Pescetti  wrote:
>
>> jan i wrote:
>>
>>> I warned about exactly that, but  I was asked (see JIRAs) to remove the
>>> cats (captcha). If you read the JIRA (which was watched be several in
>>> here)
>>> you will see my warning.
>>>
>>
>> The idea was to replace the CAPTCHA with something better, otherwise we
>> can (should) keep the current CAPTCHA and discuss a better solution in the
>> meantime.
>>
>> The cats cause incompatibilities and other issues, but if they are much
>> more effective than the replacement let's go back to the cats as soon as
>> possible and in the "see what's best to replace them (but something MORE
>> effective, not LESS effective!).
>>
>
> May I politely correct you, the idea was NOT to replace the cats. The jira
> was implemented by the word !
>
> The exact wording is:
>
> "Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It
> doesn't work in several browser configurations, it includes HTTP instead of
> HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 -> Recommended
> solution: drop it entirely.  "
>
> That statement is pretty clear, how it can be read as moving to something
> more effective slips my mind.
>
> later the jira contains:
>
> "accessibility suggestion from Tyler (haven't tested MediaWiki
> compatibility): there is a website which provides text-based CAPTCHA's in
> the form of logic questions, math problems, etc. It provides an XML API.
> See http://www.textcaptcha.com/ "
>
> Apart from the facts, thats its a suggestion and not a decision (like that
> above),  we do not use extensions that are not supported by mediawiki
> (meaning downloadable from mediawiki.com and verified for our release). As
> a sidenote, that captcha is pretty much the same as the standard which are
> active right now. There are quite a lot of captcha´s out there, just
> looking at mediawiki.com extensions gives a lot of choises.
>
> At this point in time we have several choices:
> 1) leave the config as it is
> 2) reinstall cats
> 3) choose another captcha (in this case we need to decide which one).
>
> I am not the one to overrule a community decision (Wiki6), but I will
> happely implement another community decision.
>

I hope you can simply restore cats if that can be done without too
much trouble.  Then we can discuss further and come to a community
decision on what else to do, if anything.  I hope you agree that there
is zero benefit to accumulating additional spam while we discuss.

Fix the immediate problem, then we can discuss longer term.  This one
area that Apache Infra knows how to do well.  They know when it is
important to act rather than discuss.  I suggest that this is one of
those times.

Thanks!

-Rob

> rgds
> jan I.
>
>
>
>
>
>> Regards,
>>   Andrea.
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>

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

Re: [Mwiki] a massive spam attack. Again

[jan i]

On 6 February 2014 23:42, Andrea Pescetti  wrote:

> jan i wrote:
>
>> I warned about exactly that, but  I was asked (see JIRAs) to remove the
>> cats (captcha). If you read the JIRA (which was watched be several in
>> here)
>> you will see my warning.
>>
>
> The idea was to replace the CAPTCHA with something better, otherwise we
> can (should) keep the current CAPTCHA and discuss a better solution in the
> meantime.
>
> The cats cause incompatibilities and other issues, but if they are much
> more effective than the replacement let's go back to the cats as soon as
> possible and in the "see what's best to replace them (but something MORE
> effective, not LESS effective!).
>

May I politely correct you, the idea was NOT to replace the cats. The jira
was implemented by the word !

The exact wording is:

"Wiki6: Cats/Dogs CAPTCHA for new user registration is quite broken. It
doesn't work in several browser configurations, it includes HTTP instead of
HTTPS https://issues.apache.org/ooo/show_bug.cgi?id=123695 -> Recommended
solution: drop it entirely.  "

That statement is pretty clear, how it can be read as moving to something
more effective slips my mind.

later the jira contains:

"accessibility suggestion from Tyler (haven't tested MediaWiki
compatibility): there is a website which provides text-based CAPTCHA's in
the form of logic questions, math problems, etc. It provides an XML API.
See http://www.textcaptcha.com/ "

Apart from the facts, thats its a suggestion and not a decision (like that
above),  we do not use extensions that are not supported by mediawiki
(meaning downloadable from mediawiki.com and verified for our release). As
a sidenote, that captcha is pretty much the same as the standard which are
active right now. There are quite a lot of captcha´s out there, just
looking at mediawiki.com extensions gives a lot of choises.

At this point in time we have several choices:
1) leave the config as it is
2) reinstall cats
3) choose another captcha (in this case we need to decide which one).

I am not the one to overrule a community decision (Wiki6), but I will
happely implement another community decision.

rgds
jan I.





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

Re: scripts to assist in editing helpcontent2

[Kay Schenk]

On Thu, Jan 30, 2014 at 12:01 PM, Kay Schenk  wrote:

>
>
> On Thu, Jan 30, 2014 at 11:57 AM, FR web forum  wrote:
>
>> We have other issue about help content:
>> https://issues.apache.org/ooo/show_bug.cgi?id=123246
>>
>
> OK. Thanks for this...
>

Well I am barely getting started in the AOO App Help  world. I didn't do
anything about these suggestions, or my little scripts that actually may
not be all that valuable as it turns out.

I will try to spend next week collecting my thoughts and updating what had
been started on cwiki quite a while back.


>
>
>>
>> - Mail original -
>> De: "Andre Fischer" 
>> À: dev@openoffice.apache.org
>> Envoyé: Jeudi 30 Janvier 2014 09:19:55
>> Objet: Re: scripts to assist in editing helpcontent2
>>
>> On 30.01.2014 09:10, Oliver-Rainer Wittmann wrote:
>> > Hi,
>> >
>> > On 30.01.2014 02:34, Kay Schenk wrote:
>> >> I decided to assist with the task of adding help information the four
>> >> functions added to scalc some time ago
>> >>   (see mail thread:
>> >> http://markmail.org/message/ojaxtd6uez4wk3rf)
>> >>
>> >> so I fist tracked down the help files in which to add the
>> >> information. Then
>> >> a major stumbling block -- how to create the needed header ids,
>> bookmark
>> >> ids, paragraph ids for my proposed additions.
>> >>
>> >> I ended up constructing a  script that went through all the help
>> >> files and
>> >> culled out the ids that had already been used producing 3 little files
>> >> corresponding to header ids, bookmark ids and paragraph ids, thinking
>> >> new
>> >> ones could be chosen using these lists. Really crazy results -- not all
>> >> nice numerical id sequences but oh well.
>> >>
>> >> Anyway, where's a good place for this if someone else needs to use
>> >> them? I
>> >> think the wiki takes attachments? Should I just upload there along with
>> >> some instructions for use?
>> >>
>> >
>> > What about http://svn.apache.org/viewvc/openoffice/devtools/ ?
>>
>> If the script would make our build easier then it might also go to
>> main/solenv/bin/
>>
>> -Andre
>>
>> >
>> >
>> > Best regards, Oliver
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> > For additional commands, e-mail: dev-h...@openoffice.apache.org
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
>
>
> --
>
> -
> MzK
>
> "Cats do not have to be shown how to have a good time,
>  for they are unfailing ingenious in that respect."
>-- James Mason
>



-- 
-
MzK

"Cats do not have to be shown how to have a good time,
 for they are unfailing ingenious in that respect."
   -- James Mason

RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault

[Steele, Raymond]

Andre,

When we commented out the section below, we were able to get the application to 
work correctly (although it did not let us save a spreadsheet to disk for some 
reason. Each time we hit okay to save after supplying a unique name, the 
filechooser closes, but instantly reappears again. It did let us save it as 
another format, such as .dif).

However, the application crashes when we replace the lines with:

Reference xThis (this, SAL_NO_ACQUIRE);
WeakReference xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));


I've attached the stack trace of that crash. It crashes right after the 
SidebarController destructor on line 177 (which is empty).  Stepping from the 
destructor brings us into boost's checked_delete.hpp and eventually crashes at 
line 34 "delete x". See attached stack trace. m_RefCount was 3 for us as well.

Thanks for taking the time to look into this, we are grateful.  Would you 
happen to be  located in the U.S.?


From: Andre Fischer [mailto:awf@gmail.com]
Sent: Thursday, February 06, 2014 2:03 AM
To: Steele, Raymond; a...@openoffice.apache.org; Herbert Duerr 
(h...@apache.org); dev@openoffice.apache.org
Cc: Meffe, David K; awf@gmail.com
Subject: Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory 
Fault

On 05.02.2014 20:02, Steele, Raymond wrote:
Andre,

We are not seeing any exception before the actual crash. Maybe I am not looking 
in the right place, but we've been using dbx intercept command to track any. 
Any other suggestions?

Raymond,

there a few thing you can do to find out if this is a local problem (broken in 
the constructor) or something more fundamental that is possibly caused by an 
error that happened much earlier.

- Comment out the last few lines:
  /*
WeakReference xWeakController (this);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
   */
That should tell us whether the crash is caused just by storing the weak 
reference.
The sidebar should still work in general but some updates may be lost.

- Replace the last few lines by this:
Reference xThis (this, SAL_NO_ACQUIRE);
WeakReference xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
That removes one (of two) acquire calls (I don't know yet why there is a second 
acquire,  after all the purpose of the weak reference is just /not/ to increase 
the reference count).

- Check the value of the reference count of 'SidebarController* this' (in 
OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of the 
SidebarController constructor is executed.
  In my case it is 3.

-Andre




  Also, I've attached the stack trace of the first and second 
notifyContextChangeEvent.  They are different.

That is OK.  They should be different.  But the stack trace of the second call 
looks broken.  The top two frames (notifyContextChangeEvent being called from 
Reference constructor) indicate that something is very wrong, like the vtable 
overwritten or not fully created.  One explanation (although I cannot say how 
probable that is) could be that the Solaris compiler has not fully 
created/initialized the vtable in the constructor.



Raymond

From: Steele, Raymond
Sent: Wednesday, February 05, 2014 9:48 AM
To: 'a...@openoffice.apache.org'; Herbert 
Duerr (h...@apache.org); 
dev@openoffice.apache.org
Cc: Meffe, David K; 'awf@gmail.com'
Subject: RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory 
Fault

Hi Andre,

Thanks for the response. We are looking at that now.

In the constructor of SidebarController at line 168 "WeakReference...", on your 
system, does the code step to  Reference.h: Line 359 - XInterface operator, as 
it does during our run?

It appears  that at runtime Reference.hxx: Line 136 - _pInterface->acquire()  
that occurs after "WeakReference.."  does not  execute as it does after 
addContextChangeEventListener a few lines above WeakReference. Do you see a 
similar behavior?  Can you provide the first 5-10 steps your code takes after 
WeakReference (line 168)?

Here are the requested frames

>cppuhelper3MSC.dll!cppu::OWeakObject::acquire()  Line 204C++
 cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire()  Line 236 
+ 0x9 bytesC++
 
sfx.dll!cppu::WeakComponentImplHelper4::acquire()
  Line 70 + 0xc bytesC++
 
sfx.dll!com::sun::star::uno::Reference::Reference(sfx2::sidebar::SidebarController
 * pInterface)  Line 136 + 0x12 bytesC++
 
sfx.dll!sfx2::sidebar::SidebarController::SidebarController(sfx2::sidebar::SidebarDockingWindow
 * pParentWindow, const 
com::sun::star:

Re: [Mwiki] a massive spam attack. Again

[Andrea Pescetti]

jan i wrote:

I warned about exactly that, but  I was asked (see JIRAs) to remove the
cats (captcha). If you read the JIRA (which was watched be several in here)
you will see my warning.


The idea was to replace the CAPTCHA with something better, otherwise we 
can (should) keep the current CAPTCHA and discuss a better solution in 
the meantime.


The cats cause incompatibilities and other issues, but if they are much 
more effective than the replacement let's go back to the cats as soon as 
possible and in the meantime see what's best to replace them (but 
something MORE effective, not LESS effective!).


Regards,
  Andrea.

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

Re: Reporting a problem with the OpenOffice website

[Marcus (OOo)]

Am 02/06/2014 07:25 AM, schrieb Carol Miller:

Your product keeps downloading itself onto my computer. I do not want it!
How do I stop this?


From your description I conclude that you don't have initially 
downloaded OpenOffice from our website 
(http://www.openoffice.org/download/). Obviously you have got it from a 
website that has bad intentions.


From your mail I also conclude that you have a Windows system. So, 
maybe it's the best to deinstall / delete the software completely if 
this is possible. Then download the real OpenOffice from our website 
mentioned above.


Howeer, without further details I cannot tell you any more tipps.

For further help use our User's mailing list [1] or if you prefer visit 
the Forum [2] to share your problem with other users and ask for help.


[1] 
http://openoffice.apache.org/mailing-lists.html#users-mailing-list-public


[2] https://forum.openoffice.org/en/forum/

HTH

Marcus

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

Re: [Mwiki] a massive spam attack. Again

[jan i]

On 6 February 2014 21:06, Rob Weir  wrote:

> On Thu, Feb 6, 2014 at 1:28 PM, jan i  wrote:
> > On 6 February 2014 19:00, helen  wrote:
> >
> >> Hi there,
> >>
> >> I'm Helen, a Wi admin.
> https://wiki.openoffice.org/wiki/User:Helen_russian
> >>
> >> Since 5th Feb. MWiki is under a massive spam attack.
> >> Please take a look: https://wiki.openoffice.org/wiki/Special:Log/delete,
> >> https://wiki.openoffice.org/wiki/Special:Log/block
> >>
> >
> > I warned about exactly that, but  I was asked (see JIRAs) to remove the
> > cats (captcha). If you read the JIRA (which was watched be several in
> here)
> > you will see my warning.
> >
> > The simple captcha we have in place, is browser safe, but not very
> > efficient. I assume the admins as such wanted the change (otherwise I am
> > sure the task would not have been added).
> >
> > Another captcha was suggested, but with the note "not tested on
> mediawiki"
> > (or something similar). We only install extensions supported by mediawiki
> > of course.
> >
>
> A simpler solution:  Why not add back the "cat" captcha, but only show
> it to the spammers?
>
> Regards,
>
> -Rob
>
> (OK.  That is a joke.  But I was once asked by a manager, many years
> ago, to improve a spell checker so it only reported misspellings of
> words that were in the dictionary.)
>

I am happy, someone can make a joke out of a self imposed spam attack.

I am surely too serious in my work, but would much more ike to see a
community agreed solution, before we end having all admins fight spam (just
remember last time).

rgds
jan I.


>
> > If the admins wants a change, then please have a discussion about it on
> the
> > ML, and once agreed upon, file a JIRA.
> >
> > rgds
> > jan I.
> >
> >
> > Please help.
> >>
> >> --
> >> Regards,
> >> Helen
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [Mwiki] a massive spam attack. Again

[Kay Schenk]

On Thu, Feb 6, 2014 at 12:06 PM, Rob Weir  wrote:

> On Thu, Feb 6, 2014 at 1:28 PM, jan i  wrote:
> > On 6 February 2014 19:00, helen  wrote:
> >
> >> Hi there,
> >>
> >> I'm Helen, a Wi admin.
> https://wiki.openoffice.org/wiki/User:Helen_russian
> >>
> >> Since 5th Feb. MWiki is under a massive spam attack.
> >> Please take a look: https://wiki.openoffice.org/wiki/Special:Log/delete,
> >> https://wiki.openoffice.org/wiki/Special:Log/block
> >>
> >
> > I warned about exactly that, but  I was asked (see JIRAs) to remove the
> > cats (captcha). If you read the JIRA (which was watched be several in
> here)
> > you will see my warning.
> >
> > The simple captcha we have in place, is browser safe, but not very
> > efficient. I assume the admins as such wanted the change (otherwise I am
> > sure the task would not have been added).
> >
> > Another captcha was suggested, but with the note "not tested on
> mediawiki"
> > (or something similar). We only install extensions supported by mediawiki
> > of course.
> >
>
> A simpler solution:  Why not add back the "cat" captcha, but only show
> it to the spammers?
>

LOL!


>
> Regards,
>
> -Rob
>
> (OK.  That is a joke.  But I was once asked by a manager, many years
> ago, to improve a spell checker so it only reported misspellings of
> words that were in the dictionary.)
>
>
> > If the admins wants a change, then please have a discussion about it on
> the
> > ML, and once agreed upon, file a JIRA.
> >
> > rgds
> > jan I.
> >
> >
> > Please help.
> >>
> >> --
> >> Regards,
> >> Helen
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
-
MzK

"Cats do not have to be shown how to have a good time,
 for they are unfailing ingenious in that respect."
   -- James Mason

Re: Idea for a new feature

[Alexandro Colorado]

Which idea is it, the source code is publically browsable here:
http://svn.apache.org/viewvc/openoffice/trunk/

More info: https://openoffice.apache.org/source.html



On Thu, Feb 6, 2014 at 1:51 PM, Isabel Prochner
wrote:

> Hello,
>
> I have an idea for a new feature for a word-processing program. I think it
> could be a helpful addition to Writer.
>
> My programmer friend says it could be easy to create, but we'd need access
> to the source code of the program.
>
> Could you please let me know how to implement this idea, and how we could
> become involved with Open Office?
>
> I look forward to hearing from you.
>
> Best regards,
> Isabel Prochner
>



-- 
Alexandro Colorado
Apache OpenOffice Contributor
http://www.openoffice.org
882C 4389 3C27 E8DF 41B9  5C4C 1DB7 9D1C 7F4C 2614

Re: [Mwiki] a massive spam attack. Again

[Rob Weir]

On Thu, Feb 6, 2014 at 1:28 PM, jan i  wrote:
> On 6 February 2014 19:00, helen  wrote:
>
>> Hi there,
>>
>> I'm Helen, a Wi admin. https://wiki.openoffice.org/wiki/User:Helen_russian
>>
>> Since 5th Feb. MWiki is under a massive spam attack.
>> Please take a look: https://wiki.openoffice.org/wiki/Special:Log/delete ,
>> https://wiki.openoffice.org/wiki/Special:Log/block
>>
>
> I warned about exactly that, but  I was asked (see JIRAs) to remove the
> cats (captcha). If you read the JIRA (which was watched be several in here)
> you will see my warning.
>
> The simple captcha we have in place, is browser safe, but not very
> efficient. I assume the admins as such wanted the change (otherwise I am
> sure the task would not have been added).
>
> Another captcha was suggested, but with the note "not tested on mediawiki"
> (or something similar). We only install extensions supported by mediawiki
> of course.
>

A simpler solution:  Why not add back the "cat" captcha, but only show
it to the spammers?

Regards,

-Rob

(OK.  That is a joke.  But I was once asked by a manager, many years
ago, to improve a spell checker so it only reported misspellings of
words that were in the dictionary.)


> If the admins wants a change, then please have a discussion about it on the
> ML, and once agreed upon, file a JIRA.
>
> rgds
> jan I.
>
>
> Please help.
>>
>> --
>> Regards,
>> Helen
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>

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

Idea for a new feature

[Isabel Prochner]

Hello,

I have an idea for a new feature for a word-processing program. I think it
could be a helpful addition to Writer.

My programmer friend says it could be easy to create, but we'd need access
to the source code of the program.

Could you please let me know how to implement this idea, and how we could
become involved with Open Office?

I look forward to hearing from you.

Best regards,
Isabel Prochner

Re: Application Review - OpenOffice

[Jonathon]

On February 6, 2014 5:33:20  Barrett wrote:

>Please review and complete the attached information request about your 
>applications currently in use at London Borough of Southwark.

A)  You sent your request to a mailing list whose subscribers are scattered 
across the globe. A mailing list that is archived on several sites on the 
Internet, including, but not exclusively, some that are part of the World Wide 
Web. The majority of the sites are open to the general public.

B) It is not uncommon for attachments to messages sent to mailing lists to be 
stripped, and removed from the message, between the sender, and the recipient. 
As such, best practices call for a URL to be provided, so the recipents can 
retrieve, and review the attachment.

C) Your request was sent to a list of developers. People who write, or review 
code. People who place little to no concern about distribution of the product. 
People whose concern about licencing starts with "What licence is the source 
code distributed under?" and ends with "Is that source code available?"

jonathon
-- 


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

Successful 1st Build!

[Tenzin Chhosphel]

Hi all,
I had previously introduced myself and subscribed to the dev list with 
another email. But, I'll be using  this e-mail: chhos...@gmail.com from now on 
so I am reintroducing myself shortly. I am Tenzin Chhosphel from New York City. 
I am currently a computer science major at City College - CUNY, a rising 
senior. I have hands-on experience on multiple languages: C, Objective-C, Java, 
etc. but I primarily code in C++. I have successfully built OpenOffice on 
Ubuntu 12.04 and ready for coding, debugging, and woking. So what projects can 
I contribute, where can I get started? 

Thanks, 
Tenzin

Re: [Mwiki] a massive spam attack. Again

[jan i]

On 6 February 2014 19:00, helen  wrote:

> Hi there,
>
> I'm Helen, a Wi admin. https://wiki.openoffice.org/wiki/User:Helen_russian
>
> Since 5th Feb. MWiki is under a massive spam attack.
> Please take a look: https://wiki.openoffice.org/wiki/Special:Log/delete ,
> https://wiki.openoffice.org/wiki/Special:Log/block
>

I warned about exactly that, but  I was asked (see JIRAs) to remove the
cats (captcha). If you read the JIRA (which was watched be several in here)
you will see my warning.

The simple captcha we have in place, is browser safe, but not very
efficient. I assume the admins as such wanted the change (otherwise I am
sure the task would not have been added).

Another captcha was suggested, but with the note "not tested on mediawiki"
(or something similar). We only install extensions supported by mediawiki
of course.

If the admins wants a change, then please have a discussion about it on the
ML, and once agreed upon, file a JIRA.

rgds
jan I.


Please help.
>
> --
> Regards,
> Helen
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

[Mwiki] a massive spam attack. Again

[helen]

Hi there,

I'm Helen, a Wiki admin. https://wiki.openoffice.org/wiki/User:Helen_russian

Since 5th Feb. MWiki is under a massive spam attack.
Please take a look: https://wiki.openoffice.org/wiki/Special:Log/delete 
, https://wiki.openoffice.org/wiki/Special:Log/block


Please help.

--
Regards,
Helen



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

Re: Application Review - OpenOffice

[Donald Whytock]

On Thu, Feb 6, 2014 at 9:27 AM, Rob Weir  wrote:

>
> We did receive your 27-page long questionnaire regarding the
> capabilities and license of the OpenOffice application.   There may be
> some misunderstanding here.


I'm tempted to put that on my cube wall as a quote.

Re: Bugzilla: Keyword "regression"

[Rainer Bielefeld]

Rob Weir schrieb:


I wonder whether a combination of the regression flag and the version
field would give us everything we need to know?



Hi,

that's the main intentions behind my suggestion. If we know we have had 
a regression (not too long ago, with "Regression keyword) and also have 
found the version where it appeared, we can find the commit what causes 
the problem. With reasons for the commit fresh in their mind developers 
should be able to fix that quickly. With old regressions that's more 
difficult, nobody remembers why the code changes have been done and what 
later commits' functions will break after changes in that area.


So the "regression" keyword can be a flag showing that here is an 
annoying mishap what can be fixed with probably bearable "costs".


CU

Rainer

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

Getting started with development

[Pranet Verma]

Hi,
Could you please tell me how to get started with Open Office development?

I began by following this guide :
https://wiki.openoffice.org/wiki/Development
, but after building the source and installing the program when I reached
the first tutorial ( https://wiki.openoffice.org/wiki/Tutorial_Start ) it
failed(I'm pretty sure i followed all the steps but ctrl+T just doesnt work
like its supposed to) .
The page does seem to be outdated to me (considering some folder name and
syntax of files do not match with the guide, though i may be wrong), I was
wondering if there was a better source to learn from.

I'm reasonably comfortable with c/c++ , and am pretty active in competitive
programming, but developments new for me , so any help is appreciated.
Also, if possible could you direct me to modules using c/c++ specifically?
Im open to learning new languages, but to start with I would prefer working
in a familiar environment.

Thank You

Re: Application Review - OpenOffice

[Rob Weir]

On Thu, Feb 6, 2014 at 8:33 AM, Barrett, Ronnie
 wrote:
>
> To whom it may concern,
>

Hello Ronnie,

We did receive your 27-page long questionnaire regarding the
capabilities and license of the OpenOffice application.   There may be
some misunderstanding here.   We are not a commercial vendor selling
licenses of software, providing formal support agreements, etc.  We
are a volunteer-led, non-profit open source project, making software
available for all to use for free.   We have no staff to fill out
lengthy government forms.  We're generally happy to respond to
technical questions regarding use of the product.  We're all
enthusiastic users of OpenOffice and love to share our knowledge of
the product.  But there is no one here to help you deal with your own
regulations.

What would typically happen in cases like this is that the private
sector partner, in this case Capita, would do the leg work and
research answers to these questions.  Most of them could be found on
our website without too much difficulty.   If a greater effort is
required, there are several consultants who specialize in
OpenOffice-related services, including those we list on our website:

http://www.openoffice.org/bizdev/consultants.html

Regards,

-Rob


> Please review and complete the attached information request about your
> applications currently in use at London Borough of Southwark.
>
> The form should be completed and returned directly to the council inbox
> moder...@southwark.gov.uk, not this inbox – Capita are collating this
> information on behalf of London Borough of Southwark council.
>
> Please however, respond to this email if there are any queries with this
> request for information.
> <>
>
> Many Thanks,
>
> Ronnie Barrett
>
> The email you received and any files transmitted with it are confidential,
> may be covered by legal and/or professional privilege and are intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this in error please notify us immediately. If you are
> not the intended recipient of the email or the person responsible for
> delivering it to them you may not copy it, forward it or otherwise use it
> for any purpose or disclose its contents to any other person. To do so may
> be unlawful. Where opinions are expressed in the email they are not
> necessarily those of Southwark Council and Southwark Council is not
> responsible for any changes made to the message after it has been sent.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org

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

Application Review - OpenOffice

[Barrett, Ronnie]

To whom it may concern,

Please review and complete the attached information request about your
applications currently in use at London Borough of Southwark.

The form should be completed and returned directly to the council inbox
moder...@southwark.gov.uk, not this inbox - Capita are collating this
information on behalf of London Borough of Southwark council.

Please however, respond to this email if there are any queries with this
request for information.
 <>

Many Thanks,

Ronnie Barrett


The email you received and any files transmitted with it are confidential, may 
be covered by legal and/or professional privilege and are intended solely for 
the use of the individual or entity to whom they are addressed.

If you have received this in error please notify us immediately.

If you are not the intended recipient of the email or the person responsible 
for delivering it to them you may not copy it, forward it or otherwise use it 
for any purpose or disclose its contents to any other person. To do so may be 
unlawful.

Where opinions are expressed in the email they are not necessarily those of 
Southwark Council and Southwark Council is not responsible for any changes made 
to the message after it has been sent.


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

Bugzilla: Keyword "regression"

[Rainer Bielefeld]

Hi,

currently the manual on
 seems to suggest to 
use that keyword also for problems what appeared between OOo 1.0.2 and 
OOo 1.0.3. Such use might be correct as a matter of form, but I think 
useless for QA and developers daly work.


"regression" key word indicates a major priority for fixing a bug, 
because appearance of new problems is bad for AOO's reputation. But a 
regression between OOo 1.0.0 and OOo 1.0.1 from 2001 (as an overstated 
example) is nothing what should cause major reputation loss for AOO in 2014.


So I recommend to limit use of Keyword "regression" for all Problems 
what appeared with AOO 3.4-dev or later and to add a corresponding hint 
in Bugzilla Help.


BTW: I recommend to keep those hints in Bugzilla short (not more than 2 
text rows or so) and do link to more elaborated help in the Wiki (for 
example).


Best regards

Rainer

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

Re: About openxml handling code

[Andre Fischer]

On 03.02.2014 18:54, Mayur wrote:

Found something interesting. Writer seems to reject any graphics in OOXML
documents - even VML ones. But there does seem to be code to support it.
Only, if a couple of tiny glitches were fixed, possibly Writer will start
showing VML shapes (at least). That'd work for all the 2007 MS word
documents, as well as for some 2010 documents which would have the vml data
in their mc:Alternativecontent tags. Here're the problems:
   i.  A function getNamespace( )  in
oox/source/shape/ShapeContextHandler.cxx always returned 0. The problem
seems to be a
   rather strange looking definition of the NMSP_MASK constant in
oox/source/token/namespaces.hxx.tail. It says there:
*const sal_int32 TOKEN_MASK* = static_cast* ( (1 <<
16) - 1 );  *
*   const sal_Int32 NMSP_MASK   = static_cast< sal_Int32 >(
SAL_MAX_INT16 & ~TOKEN_MASK );*

  Why SAL_MAX_INT16? That would translate into (for windows)
*  TOKEN_MASK = static_cast(0x);  // 65535*
*and NMSP_MASK = static_cast(0x7FFF & ~TOKEN_MASK). //
which is 0x7FFF & 0x = 0.*
   And
   Where as really, we should be looking for is the namespace value
which is in the higher two bytes. i.e. the following change fixes it.
*const sal_Int32 NMSP_MASK   = static_cast< sal_Int32 >(
SAL_MAX_INT32 & ~TOKEN_MASK );*
That should set NMSP_MASK to the required 0x to obtain the
higher two bytes.


Good analysis.



To my mind, this sort of compactness isn't called for. Maybe, we
could have simply used a compact struct to store namespace and tag.


I always wondered why we keep namespace and token separable once they 
have been read into memory.  While the XML file is scanned it does makes 
sense to use the same token for names in different namespaces.  This 
keeps the number of tokens and thus the complexity of the scanner small 
(well, as small as possible).  But once we have the tag (namespace and 
name) in memory we should not have to extract namespace or name from a 
tag.  After all, if I have a name n in two namespaces a and b then a:n 
and b:n are two different things and we can use enum values a_n and b_n 
with arbitrary values to represent them.  But maybe I am missing something?


-Andre



  ii. In oox/source/vml/vmldrawingfragment.cxx, there's a switch in the
function onCreateContext that says:
 case VMLDRAWING_WORD:
   if ( isRootElement() )  {... }

   Is this so that whenever a vml file is received as a separate
document fragment, only then we create a shape context? Why not for the
inline (v:rect or other) objects? I tried removing the check, and instead
checking simply if nElement is a VML, then vml drawings were suddenly
visible in writer.

Is this a valid fix?



On Wed, Jan 29, 2014 at 1:24 PM, Andre Fischer  wrote:


On 28.01.2014 13:47, Mayur wrote:


Hi,

I am very new to the OpenOffice code, and need some help understanding the
open-xml handling code. Could someone please answer the following
questions?

   i. There seem to be two distinct pieces of code that do open-xml parsing
in different ways. There's one part in "writerfilter" that has some
generated code (xslt based) that provides factories and classes for
creating different object types. And then, for sc and sd, all of the
parsing code is in the "oox" module and seems to be hand-written. Why is
that? Are there plans to move the parsing code to a common module?
(perhaps
oox ...)


Re why: OOXML import has been developed while OpenOffice was maintained by
Sun, later Oracle.  There where at least three development teams involved
(for Writer, Calc, Draw/Impress). Sometimes they did not communicate with
each other as well as they should have.  Having different modules is one of
the results.  But, as far as I know, writerfilter has some calls into oox
for shared functionality.

Re future plans: Some of us are thinking about improving the OOXML
support.  Consolidation of the code base into one module is a long term
goal.




ii. Probably a related question - why are drawing-ml shapes and pictures
not supported in sw, while they are supported in sc and sd? The parsing
code seems to be there. The tag wps:wsp has very little delta with the
p:sp
tag. Is this in works?


Well, see my above comments.
And, parsing OOXML is the easy part, importing the data into the
application model is the hard part.  Calc and Impress use the same model
for representing graphical objects, Writer has its own.

If you are interested in OOXML import/export then maybe we can work
together on improving it?

Regards,
Andre



thanks,
mayur



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





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.or

Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault

[Andre Fischer]

On 05.02.2014 20:02, Steele, Raymond wrote:


Andre,

We are not seeing any exception before the actual crash. Maybe I am 
not looking in the right place, but we've been using dbx intercept 
command to track any. Any other suggestions?




Raymond,

there a few thing you can do to find out if this is a local problem 
(broken in the constructor) or something more fundamental that is 
possibly caused by an error that happened much earlier.


- Comment out the last few lines:
  /*
WeakReference xWeakController (this);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
   */
That should tell us whether the crash is caused just by storing the weak 
reference.

The sidebar should still work in general but some updates may be lost.

- Replace the last few lines by this:
Reference xThis (this, SAL_NO_ACQUIRE);
WeakReference xWeakController (xThis);
maSidebarControllerContainer.insert(
SidebarControllerContainer::value_type(
rxFrame,
xWeakController));
That removes one (of two) acquire calls (I don't know yet why there is a 
second acquire,  after all the purpose of the weak reference is just 
/not/ to increase the reference count).


- Check the value of the reference count of 'SidebarController* this' 
(in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of 
the SidebarController constructor is executed.

  In my case it is 3.

-Andre


  Also, I've attached the stack trace of the first and second 
notifyContextChangeEvent.  They are different.




That is OK.  They should be different.  But the stack trace of the 
second call looks broken.  The top two frames (notifyContextChangeEvent 
being called from Reference constructor) indicate that something is very 
wrong, like the vtable overwritten or not fully created.  One 
explanation (although I cannot say how probable that is) could be that 
the Solaris compiler has not fully created/initialized the vtable in the 
constructor.



Raymond

*From:*Steele, Raymond
*Sent:* Wednesday, February 05, 2014 9:48 AM
*To:* 'a...@openoffice.apache.org'; Herbert Duerr (h...@apache.org); 
dev@openoffice.apache.org

*Cc:* Meffe, David K; 'awf@gmail.com'
*Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 
Runtime Memory Fault


Hi Andre,

Thanks for the response. We are looking at that now.

In the constructor of SidebarController at line 168 
"WeakReference...", on your system, does the code step to 
 Reference.h: Line 359 -- XInterface operator, as it does during our run?


It appears  that at runtime Reference.hxx: Line 136 - 
_pInterface->acquire()  that occurs after "WeakReference.."  does not 
 execute as it does after addContextChangeEventListener a few lines 
above WeakReference. Do you see a similar behavior?  Can you provide 
the first 5-10 steps your code takes after WeakReference (line 168)?




Here are the requested frames

>cppuhelper3MSC.dll!cppu::OWeakObject::acquire()  Line 204 C++
cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire() Line 236 
+ 0x9 bytesC++
sfx.dll!cppu::WeakComponentImplHelper4::acquire() 
Line 70 + 0xc bytesC++
sfx.dll!com::sun::star::uno::Reference::Reference(sfx2::sidebar::SidebarController 
* pInterface)  Line 136 + 0x12 bytesC++
sfx.dll!sfx2::sidebar::SidebarController::SidebarController(sfx2::sidebar::SidebarDockingWindow 
* pParentWindow, const 
com::sun::star::uno::Reference & 
rxFrame)  Line 168 + 0x12 bytesC++



Thanks!

Raymond

*From:*Steele, Raymond
*Sent:* Tuesday, February 04, 2014 3:59 PM
*To:* a...@openoffice.apache.org ; 
Herbert Duerr (h...@apache.org ); 
dev@openoffice.apache.org 

*Cc:* Meffe, David K
*Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 
Runtime Memory Fault


Herbert,

Raymond and I have been using the dbx debugger feature of Solaris 
Studio 12.3 with an equivalent throw/catch feature 
(intercept/whocatches) and have found that the cases where we tried to 
intercept exceptions, they were unhandled. This includes inside the 
SidebarController where we have tracked the problem origination. We 
have stepped through the code multiple times and while we have found 
that the problem originates in the SidebarController, we cannot 
explain how it happens.


Using the debug tool we see that the SidebarController constructor 
doesn't complete because the segmentation fault occurs when the 
notifyContextChangeEvent is called a second time. The first time it is 
called it is located in the addContextChangeEventListener where it 
appears to work as expected, even the acquire function appears to call 
the ContextChangeEventMultiplexer without any errors.


The following lines are what we see as we step-by-step through the 
execution of the SidebarController.cxx constructor when we select the 
Spreadsheet or the Text

Re: Reporting a problem with the OpenOffice website

[Larry Gusaas]

On 2014-02-05, 7:33 PM Gwen Hodder wrote:

Hello I’m have a problem with Apache open office.
this is what comes up below
The last time you opened OpenOffice, it unexpectedly quit while reopening windows. Do you 
want to try to reopen its windows again?


Then I click on cancel or reopen but it stays there and does nothing,
The only way I can close down my computer now is to turn it off at button.
Can you please advise me on how to fix this problem.
I have the latest open office download, but it still hasn’t solved the problem.

My computer is a MAC OSX 10.9.1

I look forward to your replay

Kind regards
Gwen



This is a known issue. If you had read the release notes, you would have seen the solution for 
the problem.

https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0.1+Release+Notes#AOO4.0.1ReleaseNotes-KnownIssues

You need to delete the folder "org.openoffice.script.savedState". It is in the "Saved 
Application State" folder in your User/Library.


See this post on the user forum for detailed instructions: 
https://forum.openoffice.org/en/forum/viewtopic.php?f=17&t=55755#p244931


--

As a courtesy I have sent a copy of this reply to you as well as to the mailing list. 
Do Not reply to me personally but just to the list at 
 - replies to my personal email address will be 
ignored.

Since you are not subscribed to this list you may not see all the replies to 
your query.To subscribe Apache OpenOffice mailing lists go to
http://openoffice.apache.org/mailing-lists.html

For user support you can also use The OpenOffice.org Community Forum
http://user.services.openoffice.org/en/forum/

_

Larry I. Gusaas
Moose Jaw, Saskatchewan Canada
Website: http://larry-gusaas.com
"An artist is never ahead of his time but most people are far behind theirs." - 
Edgard Varese




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