Re: AOO and Ohloh stats

[Andrea Pescetti]

On 03/12/2013 Louis Suárez-Potts wrote:

What I would further like to do is reach out to my journalist
contacts of yore


Sure, that would be appreciated. You needn't have any formal appointment 
from the project in order to approach journalists and provide them with 
up-do-date, accurate information.



elucidate that AOO is not OOo and that we are an
expanding community of contributors and users.


But at the same time, even with the new structure, Apache OpenOffice is 
obviously the continuation of the OpenOffice.org project in terms of 
product and user resources.


Regards,
  Andrea.

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

Re: AOO and Ohloh stats

[Jürgen Schmidt]

On 12/3/13 3:56 PM, Louis Suárez-Potts wrote:
> 
> On 03-Dec-2013, at 09:14, Rob Weir  wrote:
> 
>> On Mon, Dec 2, 2013 at 3:36 PM, Louis Suárez-Potts
>>  wrote:
>>> On 2 December 2013 13:24, Rob Weir  wrote:
 Of course, this is not to blame Ohloh.  The fault is not in their
 service.  The fault lies with those who take such numbers and do false
 comparisons.  This is intellectually dishonest and I think we should
 point this out wherever we see it.

 Regards,

 -Rob
>>>
>>> Rob, would you object if I quoted your post in toto on my blog,
>>> ooo-speak.blogspot.com?
>>
>> No objection.
>>
>> I'm also thinking of fortifying this page, where we link to the Ohloh stats:
>>
>> http://www.openoffice.org/stats/
>>
>> We should probably be more specific with the caveats there.
> 
> Yes. Though of course no amount of caveats nor any quantity of clarifications 
> will remove the need of constantly reminding people.
> 
> What I would further like to do is reach out to my journalist contacts of 
> yore and a) point them to your excellent blogs and others', too; elucidate 
> that AOO is not OOo and that we are an expanding community of contributors 
> and users.
> 

we are OpenOffice, please don't confuse more people. We simply moved
over to Apache but we are OpenOffice. We adapt the name to include our
new home in the name but we talk about OpenOffice, on disk we are
OpenOffice and the community is a major part of the OpenOffice community.

It is not a Y direction where 2 groups move in a different direction.
One group left OpenOffice and started LO and move away in a different
direction. But we continue the path of OpenOffice with a slower speed
for some time. That's all.

Juergen

> I would of course not represent myself as any kind of community manager (let 
> alone leader) here; Andrea's the chosen one, thankfully! :-) And you, Rob, do 
> a terrific job of community engagement. 
> 
> Cheers,
> louis
>>
>> -Rob
>>
>>> cheers,
>>> Louis
>>>
>>> -
>>> 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
> 


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

Re: Improvements of OUString

[Herbert Duerr]

Andrew Douglas Pitonyak wrote:
> On 12/03/2013 11:27 AM, Herbert Duerr wrote:
>> If you have an ASCII string then you can directly print it in an UTF-8
>> locale. No conversion needed. Also the inverse is true: if that string
>> was encoded as UTF-8 then you can print it directly in an ASCII
>> compatible locale. No conversion needed for the output. The result
>> would be exactly the same.
>> [...]
> I would have said that the ASCII values from 0 to 127 are the same for
> UTF-8, but, ASCII values greater than 127 are a problem.

As ASCII only defines codepoints from 0 to 127 any codepoint greater or
equal to 128 would be a problem. It is undefined and "illegal".

There are many other byte encodings that are compatible with ASCII
because they share ASCII's codepoints 0 to 127. UTF-8 is one of them.

But the example Andre gave was for the specific RTL_TEXTENCODING_ASCII
encoding, which means pure ASCII: That encoding target limits a
conversion to ASCII's real 0..127 core and maps any codepoints greater
than 127 to a replacement character, which defaults to a question mark.

> I recently had a problem with that when a documented contained ASCII 160, a
> non-breaking space.

"no-break space" is defined as codepoint 160==0x00A0 in some encodings
such as iso-8859-*, CP1252, etc. [1], but it is not available in pure
ASCII. Using RTL_TEXTENCODING_ASCII mapping on a string containing it
would have eliminated it too.

[1] http://en.wikipedia.org/wiki/Non-breaking_space#Encodings

> I became aware of it when I was asked "hey, why does
> this file look different after it was converted to UTF-8?"

The real problem apparently was that the original file was not ASCII.

Herbert

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

Re: Improvements of OUString

[Andrew Douglas Pitonyak]

On 12/03/2013 11:27 AM, Herbert Duerr wrote:



We should drop our support for ASCII?


UTF-8 contains ASCII. This was one of its most important design goals
and IMHO is a key factor that made this encoding such a big success.
[...]


Hm, UTF-8 is not identical to ASCII.  What if I want to write an
OUString to stdout?  Does a regular printf support UTF-8 or would I need
a conversion from UTF-8 to ASCII for that?


If you have an ASCII string then you can directly print it in an UTF-8 
locale. No conversion needed. Also the inverse is true: if that string 
was encoded as UTF-8 then you can print it directly in an ASCII 
compatible locale. No conversion needed for the output. The result 
would be exactly the same.


printf() and friends support the encoding defined by the LC_CTYPE 
environment variable. Nowadays this is very very often UTF-8, which is 
backward compatible with ASCII.


Some encodings are not ASCII compatible though, e.g. EBCDIC or DBCS 
(double-byte character sets). If you printed ASCII text in such 
environments without converting them first then you'd get gibberish. 
So if you want to make sure that what you want is what you get then 
you should always convert to the local encoding as determined by 
osl_getThreadTextEncoding().


But ASCII and UTF-8 encodings are quite dominant nowadays, especially 
on developer machines. While we could fix all debug-printing for 
non-ASCII compatible environments I suggest not to invest too much 
energy into such a task. The number of developers we'd win by 
supporting e.g. EBCDIC based development environments vs. the 
developer investment we'd have to spend to achieve this support would 
most probably be negative.


I would have said that the ASCII values from 0 to 127 are the same for 
UTF-8, but, ASCII values greater than 127 are a problem. I recently had 
a problem with that when a documented contained ASCII 160, a 
non-breaking space. I became aware of it when I was asked "hey, why does 
this file look different after it was converted to UTF-8?"


--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php


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

Re: Improvements of OUString

[Andrew Douglas Pitonyak]

On 12/03/2013 08:32 AM, Herbert Duerr wrote:

On 03.12.2013 13:02, Andre Fischer wrote:

Additionally to this almost correct statement one could mention that
isEmpty() is preferred over getLength()>0 and why.


Yes, it is preferred for checking the emptiness because it directly 
expresses what it checks.


In general it is a good idea to check for emptiness instead of 
counting the elements and then comparing against zero. Its the old 
"interface vs. implementation detail" question. The result will be the 
same from a mathematical standpoint but the effort to get this result 
may be different. From an algorithmic complexity standpoint an 
emptiness check is always equal or better. Maybe a mathematician can 
provide some insights from the set theory on this question?


By the way: the String class of Java>=6 got its isEmpty() method for 
the same reasons.


As Herbert said, this directly expresses what it checks. I would add 
"and it reads better".


There are other reasons, however; for example, depending on the 
implementation, it may be significantly faster than comparing against 
the length. For one implementation it may not matter, but, if you change 
the implementation in the future, it may.


Uniformity is another possible reason (assuming other classes also 
implement isEmpty()). If you become used to using the expressive form 
(ie, using isEmpty() rather than comparing size), then you can leave 
optimizing the call to the class implementer rather than worrying about 
the correct way to do it. I have seen empty strings checked by comparing 
the length to zero, and even using a string compare against an empty string.


--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php


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

Re: EXTERNAL: Re: Building comphelper

[Kay Schenk]

On Tue, Dec 3, 2013 at 3:09 PM, Steele, Raymond wrote:

> Here is what we ended the day with after making the changes to the
> includes.
>
> Compiling: sal/rtl/source/unload.cxx
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199:
> Error:Could not find a match for
> boost::tuples::get boost::tuples::TT>(constboost::tuples::tuple boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type,
> boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type,
> boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type>) needed
> inboost::unordered::detail::construct_from_tuple(configmgr::Partial::Node*,
> constboost::tuples::tuple boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type,
> boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type,
> boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type>&).
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line
> 350:Where: While
> instantiating"boost::unordered::detail::construct_from_tuple(configmgr::Partial::Node*,
> constboost::tuples::tuple boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type,
> boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type,
> boost::tuples::null_type,boost::tuples::null_type,
> boost::tuples::null_type>&)".
> "/usr/local/include/boost/unordered/detail/emplace_args.hpp", line
> 350:Where: Instantiated from
> boost::unordered::unordered_map boost::hash,_STL::equal_to,
> _STL::allocator<_STL::pair rtl::OUString,configmgr::Partial::Node>>>::operator[](const rtl::OUString&).
> "/opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx ", line 217: Where:
> Instantiated from non-template code.
>

I'm following this progress as well, since I, too, am having many problems
with boost disconnects in this same area. I did NOT include any additional
libraires as you did, so I'm still stuck in sal. :/



>
> -Original Message-
> From: Steele, Raymond
> Sent: Tuesday, December 03, 2013 2:41 PM
> To: 'Herbert Duerr'; 'dev@openoffice.apache.org'
> Cc: Meffe, David K
> Subject: RE: EXTERNAL: Re: Building comphelper
>
> Just to give you an update.
>
> We were able compile  debugbase.cxx  by including
> /opt/solarisstudios12.3/prod/include/CC/stlport4, but  the next module
> wanted  ../include/CC/Cstd.  Then it went back and forth. There seems to be
> a disconnect between which C/C++ implementation it wants and I do not think
> they are compatible with each other.  As of now, we've loaded the Apache
> C++ stdcxx4 implementation so that we can retry using just the one
> implementation. However,  we've noticed that stdcxx4 does not provide
> hash_map and hash_set, among others,  so we included
> ../main/stlport/system1/ files. Hopefully, this will work for us. If you
> have any comments ideas, please let us know.
>
> Raymond
>
> -Original Message-
> From: Steele, Raymond
> Sent: Tuesday, December 03, 2013 9:22 AM
> To: 'Herbert Duerr'; dev@openoffice.apache.org
> Cc: Meffe, David K
> Subject: RE: EXTERNAL: Re: Building comphelper
>
> Herbert,
>
> Thanks for the information. Sorry about the PDF. Unfortunately, we are
> unable to do a simple copy and paste because of the way are system is
> setup. The only other option that I have is to type the output, but that
> would have taken much longer.  We just implemented the patch, but are still
> receiving the same output. We are investigating now.
>
> Thanks,
>
> Raymond
>
> -Original Message-
> From: Herbert Duerr [mailto:h...@apache.org]
> Sent: Tuesday, December 03, 2013 3:36 AM
> To: dev@openoffice.apache.org
> Cc: Meffe, David K; Steele, Raymond
> Subject: Re: EXTERNAL: Re: Building comphelper
>
> Hi Raymond,
>
> On 02.12.2013 23:34, Steele, Raymond wrote:
> > Let me know if you did not get the attachment.
>
> Attachments usually get stripped on the mailing list, but I got it because
> was on CC. As the PDF only contained scanned text a simple
> copy+paste of that text would have been better.
>
> > We are having trouble interpreting the boost preprocessor macros. We are
> receiving the following output when compiling sal/osl/all.  I've attached
> the output as a pdf.
>
> Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a
> hand-crafted map::value_type and const correctness. Please try this patch
> to make the construct more digestible:
>
> --- main/sal/osl/all/debugbase.cxx
> +++ main/sal/osl/all/debugbase.cxx
> @@ -129,10 +129,9 @@ void SAL_CALL
> osl_detail_ObjectRegistry_registerObject(
>   {
>   if (rData.m_bStoreAddresses) {
>   osl::MutexGuard const guard(
> osl_detail_ObjectRegistry_getMutex() );
> -std::pair const
> insertion(
> -rData.m_addresses.insert(pObj) );
> -DEBUGBASE_ENSURE( insertion.second, "### insertion failed!?" );
> -static_cast(insertion);
> +const bool bOK = rData.m_addresses.insert(pObj).second;

Re: Good progress on confusing advertisements on download page

[Roberto Galoppini]

2013/12/3 Roberto Galoppini :
> 2013/12/3 FR web forum :
>>>A question for us is:  How do we want to report misleading ads in the
>>>future?   Do we need any process on our side?  Do we want to track the
>>>reports in Bugzilla?  Or do we want to just report these as
>>>individuals, possibly leading to redundant reports?  Maybe record
>>>these in BZ (where adding image attachments and de-duping is easy) and
>>>then report to SF with a link to the BZ issue?
>> Good question
>> I try to download AOO in french and SF.net display this kind of ad.
>> http://oooforum.free.fr/images/sf_ad.png
>> A link to a fake version named "OpenOffice 2013"
>> This jump to a para-site: h**p://opf.derniereversion.info
>
> Thanks for heads up on this, I'll take care of that.

It has been reviewed and we asked to remove that, it might take a
business day or two (worst case).

Roberto

>
> Roberto
>
>
>>
>> -
>> 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: [IAccessible2] Nice comment on our blog

[Marcus (OOo)]

Am 12/04/2013 12:27 AM, schrieb Rob Weir:

"Just to say a big thank you for the great work. We, as blind people,
are until now quite tied to MSOffice for a real productivity suite,
and with the ribon menus it becomes a nightmare. not to mention the
license prices ! Hope OOO 4.1 will be able to expose the accessibility
features even if running from a pen drive. imagine the potential
then... My only contribution can be a bit of money. I'm going to see
how to donnate."


A good timing is sometimes priceless. :-)

Marcus


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

[IAccessible2] Nice comment on our blog

[Rob Weir]

"Just to say a big thank you for the great work. We, as blind people,
are until now quite tied to MSOffice for a real productivity suite,
and with the ribon menus it becomes a nightmare. not to mention the
license prices ! Hope OOO 4.1 will be able to expose the accessibility
features even if running from a pen drive. imagine the potential
then... My only contribution can be a bit of money. I'm going to see
how to donnate."

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

RE: EXTERNAL: Re: Building comphelper

[Steele, Raymond]

Here is what we ended the day with after making the changes to the includes. 

Compiling: sal/rtl/source/unload.cxx
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 199: 
Error:Could not find a match for 
boost::tuples::get(constboost::tuples::tuple) 
needed 
inboost::unordered::detail::construct_from_tuple(configmgr::Partial::Node*,
 constboost::tuples::tuple&).
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where: 
While 
instantiating"boost::unordered::detail::construct_from_tuple(configmgr::Partial::Node*,
 constboost::tuples::tuple&)".
"/usr/local/include/boost/unordered/detail/emplace_args.hpp", line 350:Where: 
Instantiated from 
boost::unordered::unordered_map,_STL::equal_to, 
_STL::allocator<_STL::pair>>::operator[](const rtl::OUString&).
"/opt/aoo-4.0.0/main/ sal/rtl/source/unload.cxx ", line 217: Where: 
Instantiated from non-template code.

-Original Message-
From: Steele, Raymond 
Sent: Tuesday, December 03, 2013 2:41 PM
To: 'Herbert Duerr'; 'dev@openoffice.apache.org'
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper

Just to give you an update. 

We were able compile  debugbase.cxx  by including 
/opt/solarisstudios12.3/prod/include/CC/stlport4, but  the next module wanted  
../include/CC/Cstd.  Then it went back and forth. There seems to be a 
disconnect between which C/C++ implementation it wants and I do not think they 
are compatible with each other.  As of now, we've loaded the Apache C++ stdcxx4 
implementation so that we can retry using just the one implementation. However, 
 we've noticed that stdcxx4 does not provide hash_map and hash_set, among 
others,  so we included ../main/stlport/system1/ files. Hopefully, this will 
work for us. If you have any comments ideas, please let us know.

Raymond

-Original Message-
From: Steele, Raymond 
Sent: Tuesday, December 03, 2013 9:22 AM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper

Herbert, 

Thanks for the information. Sorry about the PDF. Unfortunately, we are unable 
to do a simple copy and paste because of the way are system is setup. The only 
other option that I have is to type the output, but that would have taken much 
longer.  We just implemented the patch, but are still receiving the same 
output. We are investigating now. 

Thanks,

Raymond

-Original Message-
From: Herbert Duerr [mailto:h...@apache.org]
Sent: Tuesday, December 03, 2013 3:36 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper

Hi Raymond,

On 02.12.2013 23:34, Steele, Raymond wrote:
> Let me know if you did not get the attachment.

Attachments usually get stripped on the mailing list, but I got it because was 
on CC. As the PDF only contained scanned text a simple 
copy+paste of that text would have been better.

> We are having trouble interpreting the boost preprocessor macros. We are 
> receiving the following output when compiling sal/osl/all.  I've attached the 
> output as a pdf.

Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a hand-crafted 
map::value_type and const correctness. Please try this patch to make the 
construct more digestible:

--- main/sal/osl/all/debugbase.cxx
+++ main/sal/osl/all/debugbase.cxx
@@ -129,10 +129,9 @@ void SAL_CALL osl_detail_ObjectRegistry_registerObject(
  {
  if (rData.m_bStoreAddresses) {
  osl::MutexGuard const guard(
osl_detail_ObjectRegistry_getMutex() );
-std::pair const 
insertion(
-rData.m_addresses.insert(pObj) );
-DEBUGBASE_ENSURE( insertion.second, "### insertion failed!?" );
-static_cast(insertion);
+const bool bOK = rData.m_addresses.insert(pObj).second;
+DEBUGBASE_ENSURE( !bOK, "### insertion failed!?" );
+(void)bOK; // unused for non-debug
  }
  else {
  osl_incrementInterlockedCount(&rData.m_nCount);


Please report whether this helps, I'll commit the change then.

Herbert


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

RE: EXTERNAL: Re: Building comphelper

[Steele, Raymond]

Just to give you an update. 

We were able compile  debugbase.cxx  by including 
/opt/solarisstudios12.3/prod/include/CC/stlport4, but  the next module wanted  
../include/CC/Cstd.  Then it went back and forth. There seems to be a 
disconnect between which C/C++ implementation it wants and I do not think they 
are compatible with each other.  As of now, we've loaded the Apache C++ stdcxx4 
implementation so that we can retry using just the one implementation. However, 
 we've noticed that stdcxx4 does not provide hash_map and hash_set, among 
others,  so we included ../main/stlport/system1/ files. Hopefully, this will 
work for us. If you have any comments ideas, please let us know.

Raymond

-Original Message-
From: Steele, Raymond 
Sent: Tuesday, December 03, 2013 9:22 AM
To: 'Herbert Duerr'; dev@openoffice.apache.org
Cc: Meffe, David K
Subject: RE: EXTERNAL: Re: Building comphelper

Herbert, 

Thanks for the information. Sorry about the PDF. Unfortunately, we are unable 
to do a simple copy and paste because of the way are system is setup. The only 
other option that I have is to type the output, but that would have taken much 
longer.  We just implemented the patch, but are still receiving the same 
output. We are investigating now. 

Thanks,

Raymond

-Original Message-
From: Herbert Duerr [mailto:h...@apache.org]
Sent: Tuesday, December 03, 2013 3:36 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper

Hi Raymond,

On 02.12.2013 23:34, Steele, Raymond wrote:
> Let me know if you did not get the attachment.

Attachments usually get stripped on the mailing list, but I got it because was 
on CC. As the PDF only contained scanned text a simple 
copy+paste of that text would have been better.

> We are having trouble interpreting the boost preprocessor macros. We are 
> receiving the following output when compiling sal/osl/all.  I've attached the 
> output as a pdf.

Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a hand-crafted 
map::value_type and const correctness. Please try this patch to make the 
construct more digestible:

--- main/sal/osl/all/debugbase.cxx
+++ main/sal/osl/all/debugbase.cxx
@@ -129,10 +129,9 @@ void SAL_CALL osl_detail_ObjectRegistry_registerObject(
  {
  if (rData.m_bStoreAddresses) {
  osl::MutexGuard const guard(
osl_detail_ObjectRegistry_getMutex() );
-std::pair const 
insertion(
-rData.m_addresses.insert(pObj) );
-DEBUGBASE_ENSURE( insertion.second, "### insertion failed!?" );
-static_cast(insertion);
+const bool bOK = rData.m_addresses.insert(pObj).second;
+DEBUGBASE_ENSURE( !bOK, "### insertion failed!?" );
+(void)bOK; // unused for non-debug
  }
  else {
  osl_incrementInterlockedCount(&rData.m_nCount);


Please report whether this helps, I'll commit the change then.

Herbert


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

Re: 80 million downloads

[David Gerard]

On 3 December 2013 21:12, jan i  wrote:

> I have (for ubuntu) tried to read through the policies which was a
> nightmare.


The first thing would be to get into Debian. I recall the steps there
were set out (basically, have an install set that doesn't conflict in
any way with LO - however fair or unfair that might be, it's what you
need to do). MATE managed it in the face of GNOME 3, so AOO should be
able to.


- d.

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

Re: 80 million downloads

[jan i]

On 3 December 2013 21:30, Andrea Pescetti  wrote:

> On 01/12/2013 Rob Weir wrote:
>
>> On Sun, Dec 1, 2013 at 9:53 AM, Andrea Pescetti wrote:
>>
>>> It is natural that private or public entities considering a migration
>>> will
>>> have their established consultants and ask them. But we should have
>>> enough
>>> "official" information available to anybody who is considering a
>>> migration.
>>>
>> So the fact that migrations are occurring without contacting the
>> project is a positive sign that the publicly available information, on
>> the website and wiki, is sufficient, yes?
>>
>
> Interesting interpretation! Well, maybe it's true, but then I wonder why I
> still see the occasional blog post or technology news assuming that
> OpenOffice is dead.
>
> But you may be right: indeed, if one makes the small effort to open the
> official home page (search engines lead you to obsolete pages at times for
> specific queries, but the homepage is OK) it's very clear to see that
> OpenOffice is quite active.
>
> So I wonder if the reason could be that these bloggers/experts do not even
> search for information. In that case, I don't think we can do much more.
>
>  Small open source conferences can be
>> fun, I'm sure.  But are we really introducing OpenOffice to new
>> people?  Or are we "preaching to the choir"?   Is this really the way
>> to reach the 70% of computer users who have never heard of OpenOffice?
>>
>
> I'm more interested in decision makers, at any level. For sure attending
> local events won't spread awareness, but we have other channels for that.
> But a small migration to OpenOffice is often done following word of mouth,
> and influencers are often Linux users who have seen OpenOffice disappear. I
> would like them to be properly informed.
>
> Getting OpenOffice back into distributions would be good to that aim.
> Unfortunately, policy is rather complex and is the main obstacle (meaning
> that a lot of work is needed and that our resources are currently focused
> elsewhere).
>

Since I am one of those thinking (and not only thinking) about renewing our
build system, it would be interesting to see these policies.

I have (for ubuntu) tried to read through the policies which was a
nightmare.

If somebody can point at something specific, like a bullet-list or how-to
for the distros we want be in, I would be happy to at least read through
it, and see how it could be fitted.

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: 80 million downloads

[Andrea Pescetti]

On 01/12/2013 Rob Weir wrote:

On Sun, Dec 1, 2013 at 9:53 AM, Andrea Pescetti wrote:

It is natural that private or public entities considering a migration will
have their established consultants and ask them. But we should have enough
"official" information available to anybody who is considering a migration.

So the fact that migrations are occurring without contacting the
project is a positive sign that the publicly available information, on
the website and wiki, is sufficient, yes?


Interesting interpretation! Well, maybe it's true, but then I wonder why 
I still see the occasional blog post or technology news assuming that 
OpenOffice is dead.


But you may be right: indeed, if one makes the small effort to open the 
official home page (search engines lead you to obsolete pages at times 
for specific queries, but the homepage is OK) it's very clear to see 
that OpenOffice is quite active.


So I wonder if the reason could be that these bloggers/experts do not 
even search for information. In that case, I don't think we can do much 
more.



Small open source conferences can be
fun, I'm sure.  But are we really introducing OpenOffice to new
people?  Or are we "preaching to the choir"?   Is this really the way
to reach the 70% of computer users who have never heard of OpenOffice?


I'm more interested in decision makers, at any level. For sure attending 
local events won't spread awareness, but we have other channels for 
that. But a small migration to OpenOffice is often done following word 
of mouth, and influencers are often Linux users who have seen OpenOffice 
disappear. I would like them to be properly informed.


Getting OpenOffice back into distributions would be good to that aim. 
Unfortunately, policy is rather complex and is the main obstacle 
(meaning that a lot of work is needed and that our resources are 
currently focused elsewhere).


Regards,
  Andrea.

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

RE: soltools need(s) to be rebuilt

[Απόστολος Συρόπουλος]

> 
> I suggest to look into main/sal/osl/unx/util.c. The check for a 
> __SUNPRO_C define in line 316 looks suspicious. Is this define still 
> active in newer compilers for your platform? If not please change the 
> check so that this part of the code becomes active.
> 
> You also said you switched compilers. Please make sure that there are no 
> object files around that were build for the other compiler.
> 

Hello Herbert,

This suggestion helped me to solve this problem. Thank you! Now the next 
problem is
that I am gettiing an error similar to the one reported in the URL that follows:

https://lists.gnu.org/archive/html/bug-binutils/2011-09/msg00054.html

The problem of course is that I have to build with the GNU linker instead of
the Solaris linker. I have temporally set that the system linker is the
Solaris linker and this solved this problem. Of course I have idea where
the libraries of the nss module are used and how this will affect the
building process. Also, I have no idea why one should use the GNU linker
on Solaris when the GCC people advise not to use it with GCC. 

A.S.
--
Apostols Syropoulos
Xanthi, Greece

  

Thank You for correcting Spelling Error on Openoffice.org

[David Goldfield]

Thanks so much for such a prompt response and for the excellent Web site.


David Goldfield
Computer Technology Instructor
919 Walnut Street
4th Floor
Philadelphia, PA  19107

215-627-0600 ext 3277
FAX:  215-922-0692

dgold...@asb.org
www.asb.org

Give a Donation
http://asb.org/index.php?option=com_jdonation

Serving Philadelphia's and the nation's blind and visually impaired population 
since 1874.

Reporting a problem with the OpenOffice website

[Pederson, Gary L]

Just a "nit", but it may make a difference to first time visitors to this 
webpage:

http://www.openoffice.org/porting/mac/

At the top of the page correct "Volunteer Opportunties..." to 
"...Opportunities..."

Thanks for your support


Gary Pederson


"Too many userids, passwords, pin #'s, and lock combinations." - Gary Pederson

Re: Arrow heads with hole

[Armin Le Grand]

Hi Regina,

On 02.12.2013 23:45, Regina Henschel wrote:

Hi Andrea,

Andrea Pescetti schrieb:

On 26/11/2013 Regina Henschel wrote:

I have expanded the standard.soe with some arrow heads with hole. The
file is attached to 
https://issues.apache.org/ooo/show_bug.cgi?id=123758.

If you like them, we can consider to use this palette as default.


I added a screenshot to the issue for clearer comparison. The new styles
are nice and it would be good to have them in 4.1.

In some cases, in the preview, I see the main line of the arrow going
(seemingly) too far within the arrow head, see
http://imagebin.org/280257 for an example. Is this wanted?


No, that is not wanted. I will explain the problem in more detail:


First: nice arrowheads! I am currently on something else, but I have 
already a grep on the task which you wrote.


Background:
- The arrows traditionally only used polygons (topologically: no 
poly-polygons which allows holes). This is alrteady changed and implemented.
- The arrow heads and line overlapping traditionally use a 0.0 or 0.8 
factor of overlap, according to 0% or 80% overlap. These values are 
handles relative to the arrow head sizes already, but are treated as a 
boolean (one or the other). In the core these values are prepared to be 
0-100%, freely choosable. In the UI you can switch between 0% and 80% in 
the lines dialog in it's first page (line ends-> 'centered' for right 
and left arrow). Missing is to have a value input instead of that simple 
switch and to get that 0-100% value over the API and to ODF. This is 
where normally Regina knows if this is possible ;-)
Thus: Old. historical limitations, some more way to go to get over 
these. When one day it will be possible to choose that value freely 
(prepared in core and primitives) you will be able to trim these to 
connect to your arrow head as you want it to be.
If there would be a way to do this automatically could also be 
considered; the old overlapping paint was probably only implemented 
since no one wanted to do it better from the beginning (time constrains? 
other?).


Regina, this sounds as if we could use a feature task for his...



If you stop the line at the very place where the arrow head starts, 
you get a visible gap between the "square 45°" and the line itself for 
fat lines (and same for circle or any peak shape). Therefore an 
overlap was introduced. For the filled arrow heads, it does not matter 
whether the line is drawn a little bit longer.


For the arrow heads with hole you have to find a compromise between 
showing a gap at the outer part and showing a little bit line in the 
hole.


Currently the amount by which the line is drawn longer does not depend 
on the kind of arrow head, but on the length of the arrow head. It is 
in file polygonprimitive2d.cxx in method 
PolygonStrokeArrowPrimitive2D::create2DDecomposition around line#547 
the statement "fStart *= 0.8;"
In LO I have changed that to "fStartOverlap = getStart().getWidth() / 
15.0;", so that it depends on the width of the arrow head, which also 
determines the 'stroke' width in the non-filled arrow heads. It is a 
compromise too. (It is not really a 'stroke', but the area between two 
combined paths.)


We could copy that in AOO. But perhaps someone has a better idea?

Kind regards
Regina



-
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: Good progress on confusing advertisements on download page

[Roberto Galoppini]

2013/12/3 FR web forum :
>>A question for us is:  How do we want to report misleading ads in the
>>future?   Do we need any process on our side?  Do we want to track the
>>reports in Bugzilla?  Or do we want to just report these as
>>individuals, possibly leading to redundant reports?  Maybe record
>>these in BZ (where adding image attachments and de-duping is easy) and
>>then report to SF with a link to the BZ issue?
> Good question
> I try to download AOO in french and SF.net display this kind of ad.
> http://oooforum.free.fr/images/sf_ad.png
> A link to a fake version named "OpenOffice 2013"
> This jump to a para-site: h**p://opf.derniereversion.info

Thanks for heads up on this, I'll take care of that.

Roberto


>
> -
> 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: Improvements of OUString

[Herbert Duerr]

On 03.12.2013 15:37, Andre Fischer wrote:

On 03.12.2013 14:32, Herbert Duerr wrote:

On 03.12.2013 13:02, Andre Fischer wrote:

On 03.12.2013 10:35, Herbert Duerr wrote:

On 03.12.2013 09:13, Andre Fischer wrote:
[...]
"The method isEmpty() returns true if the string is empty. If the
length of the string is one or two or three or any number bigger than
zero then isEmpty() returns false."


Additionally to this almost correct statement one could mention that
isEmpty() is preferred over getLength()>0 and why.


Yes, it is preferred for checking the emptiness because it directly
expresses what it checks.

In general it is a good idea to check for emptiness instead of
counting the elements and then comparing against zero. Its the old
"interface vs. implementation detail" question. The result will be the
same from a mathematical standpoint but the effort to get this result
may be different. From an algorithmic complexity standpoint an
emptiness check is always equal or better. Maybe a mathematician can
provide some insights from the set theory on this question?

By the way: the String class of Java>=6 got its isEmpty() method for
the same reasons.


Can you add some of this to the documentation of isEmpty()? (maybe don't
mention set theory)


Great idea. As the isEmpty() method from Java's String matches our new 
method maybe we should leverage their extensive reference [1] on this 
topic too. On the other hand that documentation was probably written for 
more experienced developers than the ones you'd like to attract.


[1] 
http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty%28%29



We should drop our support for ASCII?


UTF-8 contains ASCII. This was one of its most important design goals
and IMHO is a key factor that made this encoding such a big success.
[...]


Hm, UTF-8 is not identical to ASCII.  What if I want to write an
OUString to stdout?  Does a regular printf support UTF-8 or would I need
a conversion from UTF-8 to ASCII for that?


If you have an ASCII string then you can directly print it in an UTF-8 
locale. No conversion needed. Also the inverse is true: if that string 
was encoded as UTF-8 then you can print it directly in an ASCII 
compatible locale. No conversion needed for the output. The result would 
be exactly the same.


printf() and friends support the encoding defined by the LC_CTYPE 
environment variable. Nowadays this is very very often UTF-8, which is 
backward compatible with ASCII.


Some encodings are not ASCII compatible though, e.g. EBCDIC or DBCS 
(double-byte character sets). If you printed ASCII text in such 
environments without converting them first then you'd get gibberish. So 
if you want to make sure that what you want is what you get then you 
should always convert to the local encoding as determined by 
osl_getThreadTextEncoding().


But ASCII and UTF-8 encodings are quite dominant nowadays, especially on 
developer machines. While we could fix all debug-printing for non-ASCII 
compatible environments I suggest not to invest too much energy into 
such a task. The number of developers we'd win by supporting e.g. EBCDIC 
based development environments vs. the developer investment we'd have to 
spend to achieve this support would most probably be negative.



[...]
 ::rtl::OUStringToOString(sOUStringVariable,
RTL_TEXTENCODING_ASCII_US).getStr()


This awful construct could be made much simpler if our strings were
always unicode (UTF-8/UTF-16/UTF-32).


I thought that OUString is UTF-16 and that that where the cause, not the
solution of the conversion problems.


The complexity of the awful construct comes from the use of the
general purpose machinery for an N:1 conversion (with N being the
number of supported byte encodings). A 1:1 conversion (UTF-8 <->
UTF-16) is much simpler.


I think you are mixing up two concepts here.   One is the ability to
convert an OUString to/from all text encodings defined
sal/in/rtl/textenc.h.  The other is a possible replacement of the
OUString implementation of UTF-16 with UTF-8.


IMHO O*Strings should only support unicode, be it UTF-8 or UTF-16. 
Mapping between these two variants would be a 1:1 thing.


These OStrings are the strings used all over the office. Only in the few 
corners of the code that have to deal with non-unicode strings the more 
than 94 encodings should be supported: for converting from/to our then 
unicode-only O*Strings.


Herbert


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

RE: EXTERNAL: Re: Building comphelper

[Steele, Raymond]

Herbert, 

Thanks for the information. Sorry about the PDF. Unfortunately, we are unable 
to do a simple copy and paste because of the way are system is setup. The only 
other option that I have is to type the output, but that would have taken much 
longer.  We just implemented the patch, but are still receiving the same 
output. We are investigating now. 

Thanks,

Raymond

-Original Message-
From: Herbert Duerr [mailto:h...@apache.org] 
Sent: Tuesday, December 03, 2013 3:36 AM
To: dev@openoffice.apache.org
Cc: Meffe, David K; Steele, Raymond
Subject: Re: EXTERNAL: Re: Building comphelper

Hi Raymond,

On 02.12.2013 23:34, Steele, Raymond wrote:
> Let me know if you did not get the attachment.

Attachments usually get stripped on the mailing list, but I got it because was 
on CC. As the PDF only contained scanned text a simple 
copy+paste of that text would have been better.

> We are having trouble interpreting the boost preprocessor macros. We are 
> receiving the following output when compiling sal/osl/all.  I've attached the 
> output as a pdf.

Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a 
hand-crafted map::value_type and const correctness. Please try
this patch to make the construct more digestible:

--- main/sal/osl/all/debugbase.cxx
+++ main/sal/osl/all/debugbase.cxx
@@ -129,10 +129,9 @@ void SAL_CALL osl_detail_ObjectRegistry_registerObject(
  {
  if (rData.m_bStoreAddresses) {
  osl::MutexGuard const guard( 
osl_detail_ObjectRegistry_getMutex() );
-std::pair const 
insertion(
-rData.m_addresses.insert(pObj) );
-DEBUGBASE_ENSURE( insertion.second, "### insertion failed!?" );
-static_cast(insertion);
+const bool bOK = rData.m_addresses.insert(pObj).second;
+DEBUGBASE_ENSURE( !bOK, "### insertion failed!?" );
+(void)bOK; // unused for non-debug
  }
  else {
  osl_incrementInterlockedCount(&rData.m_nCount);


Please report whether this helps, I'll commit the change then.

Herbert


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

Re: Good progress on confusing advertisements on download page

[FR web forum]

>A question for us is:  How do we want to report misleading ads in the
>future?   Do we need any process on our side?  Do we want to track the
>reports in Bugzilla?  Or do we want to just report these as
>individuals, possibly leading to redundant reports?  Maybe record
>these in BZ (where adding image attachments and de-duping is easy) and
>then report to SF with a link to the BZ issue?
Good question
I try to download AOO in french and SF.net display this kind of ad.
http://oooforum.free.fr/images/sf_ad.png
A link to a fake version named "OpenOffice 2013"
This jump to a para-site: h**p://opf.derniereversion.info

-
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

[Rob Weir]

On Tue, Dec 3, 2013 at 10:31 AM, David Goldfield  wrote:
> I wanted to report a spelling error in the new "volunteer 
> opportunities" link on the main page.  There is a spelling error with the 
> word "opportunities."
>

Fixed.  Thanks for letting us know.

Regards.

-Rob

>
>
>
> David Goldfield
> Computer Technology Instructor
> 919 Walnut Street
> 4th Floor
> Philadelphia, PA  19107
>
> 215-627-0600 ext 3277
> FAX:  215-922-0692
>
> dgold...@asb.org
> www.asb.org
>
> Give a Donation
> http://asb.org/index.php?option=com_jdonation
>
> Serving Philadelphia's and the nation's blind and visually impaired 
> population since 1874.
>
>
>
>
>

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

Reporting a problem with the OpenOffice website

[David Goldfield]

I wanted to report a spelling error in the new "volunteer 
opportunities" link on the main page.  There is a spelling error with the word 
"opportunities."




David Goldfield
Computer Technology Instructor
919 Walnut Street
4th Floor
Philadelphia, PA  19107

215-627-0600 ext 3277
FAX:  215-922-0692

dgold...@asb.org
www.asb.org

Give a Donation
http://asb.org/index.php?option=com_jdonation

Serving Philadelphia's and the nation's blind and visually impaired population 
since 1874.

Re: AOO and Ohloh stats

[Louis Suárez-Potts]

On 03-Dec-2013, at 09:14, Rob Weir  wrote:

> On Mon, Dec 2, 2013 at 3:36 PM, Louis Suárez-Potts
>  wrote:
>> On 2 December 2013 13:24, Rob Weir  wrote:
>>> Of course, this is not to blame Ohloh.  The fault is not in their
>>> service.  The fault lies with those who take such numbers and do false
>>> comparisons.  This is intellectually dishonest and I think we should
>>> point this out wherever we see it.
>>> 
>>> Regards,
>>> 
>>> -Rob
>> 
>> Rob, would you object if I quoted your post in toto on my blog,
>> ooo-speak.blogspot.com?
> 
> No objection.
> 
> I'm also thinking of fortifying this page, where we link to the Ohloh stats:
> 
> http://www.openoffice.org/stats/
> 
> We should probably be more specific with the caveats there.

Yes. Though of course no amount of caveats nor any quantity of clarifications 
will remove the need of constantly reminding people.

What I would further like to do is reach out to my journalist contacts of yore 
and a) point them to your excellent blogs and others', too; elucidate that AOO 
is not OOo and that we are an expanding community of contributors and users.

I would of course not represent myself as any kind of community manager (let 
alone leader) here; Andrea's the chosen one, thankfully! :-) And you, Rob, do a 
terrific job of community engagement. 

Cheers,
louis
> 
> -Rob
> 
>> cheers,
>> Louis
>> 
>> -
>> 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: Improvements of OUString

[Andre Fischer]

On 03.12.2013 14:32, Herbert Duerr wrote:

On 03.12.2013 13:02, Andre Fischer wrote:

On 03.12.2013 10:35, Herbert Duerr wrote:

On 03.12.2013 09:13, Andre Fischer wrote:
[...]
"The method isEmpty() returns true if the string is empty. If the
length of the string is one or two or three or any number bigger than
zero then isEmpty() returns false."


Additionally to this almost correct statement one could mention that
isEmpty() is preferred over getLength()>0 and why.


Yes, it is preferred for checking the emptiness because it directly 
expresses what it checks.


In general it is a good idea to check for emptiness instead of 
counting the elements and then comparing against zero. Its the old 
"interface vs. implementation detail" question. The result will be the 
same from a mathematical standpoint but the effort to get this result 
may be different. From an algorithmic complexity standpoint an 
emptiness check is always equal or better. Maybe a mathematician can 
provide some insights from the set theory on this question?


By the way: the String class of Java>=6 got its isEmpty() method for 
the same reasons.


Can you add some of this to the documentation of isEmpty()? (maybe don't 
mention set theory)





Can you tell me what happens when an OUString is created for "\0". Is
that handled as end-of-string or as just one additional character?


What happens during the string construction is unchanged. So if you 
were using the

OString( "\0")
it did and does create a zero-length OUString. If you were using the 
constructor with length argument

OString( "\0", 1)
then the length was and is 1, because 1 was provided as length argument.

Only a string without any elements is empty. A string with one or more 
elements is considered non-empty even if all its elements are zero. So 
if you used a test like aString.getLength()==0 before you can use 
aString.isEmpty() directly.



[...]
Also we shouldn't bother our main string classes with non-unicode
support. Having external tooling for converting from/to other
encodings is still needed though.


We should drop our support for ASCII?


UTF-8 contains ASCII. This was one of its most important design goals 
and IMHO is a key factor that made this encoding such a big success.


Speaking of UTF-8 vs. ASCII I suggest to change the O*String methods 
such as createFromAscii() to createFromUtf8().


Hm, UTF-8 is not identical to ASCII.  What if I want to write an 
OUString to stdout?  Does a regular printf support UTF-8 or would I need 
a conversion from UTF-8 to ASCII for that?  If so, it would be 
convenient to have that directly at OUString, not in some external library.





[...]
 ::rtl::OUStringToOString(sOUStringVariable,
RTL_TEXTENCODING_ASCII_US).getStr()


This awful construct could be made much simpler if our strings were
always unicode (UTF-8/UTF-16/UTF-32).


I thought that OUString is UTF-16 and that that where the cause, not the
solution of the conversion problems.


The complexity of the awful construct comes from the use of the 
general purpose machinery for an N:1 conversion (with N being the 
number of supported byte encodings). A 1:1 conversion (UTF-8 <-> 
UTF-16) is much simpler.


I think you are mixing up two concepts here.   One is the ability to 
convert an OUString to/from all text encodings defined 
sal/in/rtl/textenc.h.  The other is a possible replacement of the 
OUString implementation of UTF-16 with UTF-8.  As long as we don't drop 
the ability to convert between text encodings we will have a 1:N (N 
being 94 if I counted correctly) relationship which then can be used to 
realize a N:N relationship for arbitrary conversion between encodings (I 
am not sure that that really works).  If we change the implementation of 
OUString we will have a 1:1 relationship, regardless of which new 
encoding/format we use.




As I wrote I'd even like to go full UTF-8 inside AOO. Most of the back 
and forth transcodings between UTF-8 and UTF-16 inside AOO are just 
wasteful.


I agree

-Andre



Herbert


-
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: AOO and Ohloh stats

[Rob Weir]

On Mon, Dec 2, 2013 at 3:36 PM, Louis Suárez-Potts
 wrote:
> On 2 December 2013 13:24, Rob Weir  wrote:
>> Of course, this is not to blame Ohloh.  The fault is not in their
>> service.  The fault lies with those who take such numbers and do false
>> comparisons.  This is intellectually dishonest and I think we should
>> point this out wherever we see it.
>>
>> Regards,
>>
>> -Rob
>
> Rob, would you object if I quoted your post in toto on my blog,
> ooo-speak.blogspot.com?

No objection.

I'm also thinking of fortifying this page, where we link to the Ohloh stats:

http://www.openoffice.org/stats/

We should probably be more specific with the caveats there.

-Rob

> cheers,
> Louis
>
> -
> 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

Good progress on confusing advertisements on download page

[Rob Weir]

Please take a look at this new blog post from SourceForge:

http://sourceforge.net/blog/sourceforge-blockthis-initiative-update/

It looks like they are taking the ad issue seriously.  They have
culled 20%+ of the ads and instituted a process for communities to
report new misleading ads.   I think this will lead to a better
experience for our users.  Thanks to SourceForge (and Roberto) for
listening to their users and responding to feedback!

A question for us is:  How do we want to report misleading ads in the
future?   Do we need any process on our side?  Do we want to track the
reports in Bugzilla?  Or do we want to just report these as
individuals, possibly leading to redundant reports?  Maybe record
these in BZ (where adding image attachments and de-duping is easy) and
then report to SF with a link to the BZ issue?

Regards,

-Rob

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

Re: Improvements of OUString

[Herbert Duerr]

On 03.12.2013 13:02, Andre Fischer wrote:

On 03.12.2013 10:35, Herbert Duerr wrote:

On 03.12.2013 09:13, Andre Fischer wrote:
[...]
"The method isEmpty() returns true if the string is empty. If the
length of the string is one or two or three or any number bigger than
zero then isEmpty() returns false."


Additionally to this almost correct statement one could mention that
isEmpty() is preferred over getLength()>0 and why.


Yes, it is preferred for checking the emptiness because it directly 
expresses what it checks.


In general it is a good idea to check for emptiness instead of counting 
the elements and then comparing against zero. Its the old "interface vs. 
implementation detail" question. The result will be the same from a 
mathematical standpoint but the effort to get this result may be 
different. From an algorithmic complexity standpoint an emptiness check 
is always equal or better. Maybe a mathematician can provide some 
insights from the set theory on this question?


By the way: the String class of Java>=6 got its isEmpty() method for the 
same reasons.



Can you tell me what happens when an OUString is created for "\0". Is
that handled as end-of-string or as just one additional character?


What happens during the string construction is unchanged. So if you were 
using the

OString( "\0")
it did and does create a zero-length OUString. If you were using the 
constructor with length argument

OString( "\0", 1)
then the length was and is 1, because 1 was provided as length argument.

Only a string without any elements is empty. A string with one or more 
elements is considered non-empty even if all its elements are zero. So 
if you used a test like aString.getLength()==0 before you can use 
aString.isEmpty() directly.



[...]
Also we shouldn't bother our main string classes with non-unicode
support. Having external tooling for converting from/to other
encodings is still needed though.


We should drop our support for ASCII?


UTF-8 contains ASCII. This was one of its most important design goals 
and IMHO is a key factor that made this encoding such a big success.


Speaking of UTF-8 vs. ASCII I suggest to change the O*String methods 
such as createFromAscii() to createFromUtf8().



[...]
 ::rtl::OUStringToOString(sOUStringVariable,
RTL_TEXTENCODING_ASCII_US).getStr()


This awful construct could be made much simpler if our strings were
always unicode (UTF-8/UTF-16/UTF-32).


I thought that OUString is UTF-16 and that that where the cause, not the
solution of the conversion problems.


The complexity of the awful construct comes from the use of the general 
purpose machinery for an N:1 conversion (with N being the number of 
supported byte encodings). A 1:1 conversion (UTF-8 <-> UTF-16) is much 
simpler.


As I wrote I'd even like to go full UTF-8 inside AOO. Most of the back 
and forth transcodings between UTF-8 and UTF-16 inside AOO are just 
wasteful.


Herbert


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

Re: Improvements of OUString

[Andre Fischer]

On 03.12.2013 10:35, Herbert Duerr wrote:

On 03.12.2013 09:13, Andre Fischer wrote:

A developer who apparently wants to remain anonymous has added the
function isEmpty() to the rtl::OUString class.  See
main/sal/inc/rtl/ustring.hxx for not much more information.


Sorry for being too short. The full semantic for isEmpty() is:

"The method isEmpty() returns true if the string is empty. If the 
length of the string is one or two or three or any number bigger than 
zero then isEmpty() returns false."


Additionally to this almost correct statement one could mention that 
isEmpty() is preferred over getLength()>0 and why.


Can you tell me what happens when an OUString is created for "\0". Is 
that handled as end-of-string or as just one additional character?




I added isEmpty() to make it possible to cleanly express the check for 
an empty string. In our codebase there were quite a few constructs 
such as

if( aString) {}
which were intended to mean
if( aString.isEmpty()) {}
What's funny is that the old construct compiled but it did the wrong 
thing: The string was implicitly converted to a pointer to its 
elements and that pointer was then compared against NULL. For our 
OUString that pointer was always non-NULL though.


Please see issue 123068 for further problems caused by the implicit 
conversion of the OUString to a pointer to its elements. This 
dangerous conversion is now disabled. By making the method private all 
such problems will be found and prevented by the compiler. When we're 
confident that all has been found the operator can be removed completely.



This in itself may not yet be very exciting but I hope that it is the
first of several improvements to one of our most frequently used
classes.  Sadly, we missed the opportunity to make some more substantial
but incompatible changes for the 4.0 release. However, some changes that
make OUString more accessible to new (and old) developers might include:

- Make construction from string literal more straightforward. At the
moment you have to write
 ::rtl::OUString("text", sizeof("text"), RTL_TEXTENCODING_ASCII_US)
   or slightly shorter and safer
 ::rtl::OUString::createFromAscii("text")


Allocating heap space, transcoding a literal string to this memory and 
deallocating it later when the string is deleted are quite wasteful 
operations. Especially when considering that the literal string is 
already there. It would be great if constructs such

OUString( L"hello")
used the pointer to the UTF-16 literal directly instead of copying its 
contents around. The same applies for the OString(). The 'L' prefix is 
a Windows convention but C++11 has even more possibilities with its 
support for unicode string literals.


Also we shouldn't bother our main string classes with non-unicode 
support. Having external tooling for converting from/to other 
encodings is still needed though.


We should drop our support for ASCII?



Looking over our string processing I'm confident that we could get 
along great with UTF-8 strings. Only when interfacing with other APIs 
an eventual conversion to UTF-16 would be needed.


And if we were using UTF-8 byte strings we could base them directly on 
the standard std::string.



- Conversion back to char* is not much better
 ::rtl::OUStringToOString(sOUStringVariable,
RTL_TEXTENCODING_ASCII_US).getStr()


This awful construct could be made much simpler if our strings were 
always unicode (UTF-8/UTF-16/UTF-32).


I thought that OUString is UTF-16 and that that where the cause, not the 
solution of the conversion problems.


-Andre




Do you have more ideas?


Using ideas from languages such as Python/Perl/Java for convenient and 
powerful string processing to replace the awkward string handling that 
is too often seen in our code base. E.g. having regexp enabled match() 
or search() methods would be a great start.


Herbert


-
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: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

A small correction for my patch suggestion:

On 03.12.2013 11:36, Herbert Duerr wrote:

[...]
+DEBUGBASE_ENSURE( !bOK, "### insertion failed!?" );


The condition there was inverted. It should have been
DEBUGBASE_ENSURE( bOK, "### insertion failed!?" );

Herbert


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

Re: EXTERNAL: Re: Building comphelper

[Herbert Duerr]

Hi Raymond,

On 02.12.2013 23:34, Steele, Raymond wrote:

Let me know if you did not get the attachment.


Attachments usually get stripped on the mailing list, but I got it 
because was on CC. As the PDF only contained scanned text a simple 
copy+paste of that text would have been better.



We are having trouble interpreting the boost preprocessor macros. We are 
receiving the following output when compiling sal/osl/all.  I've attached the 
output as a pdf.


Line 133 of main/sal/osl/all/debugbase.cxx had a problem with a 
hand-crafted map::value_type and const correctness. Please try

this patch to make the construct more digestible:

--- main/sal/osl/all/debugbase.cxx
+++ main/sal/osl/all/debugbase.cxx
@@ -129,10 +129,9 @@ void SAL_CALL osl_detail_ObjectRegistry_registerObject(
 {
 if (rData.m_bStoreAddresses) {
 osl::MutexGuard const guard( 
osl_detail_ObjectRegistry_getMutex() );
-std::pair const 
insertion(

-rData.m_addresses.insert(pObj) );
-DEBUGBASE_ENSURE( insertion.second, "### insertion failed!?" );
-static_cast(insertion);
+const bool bOK = rData.m_addresses.insert(pObj).second;
+DEBUGBASE_ENSURE( !bOK, "### insertion failed!?" );
+(void)bOK; // unused for non-debug
 }
 else {
 osl_incrementInterlockedCount(&rData.m_nCount);


Please report whether this helps, I'll commit the change then.

Herbert


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

Re: Improvements of OUString

[Herbert Duerr]

On 03.12.2013 09:13, Andre Fischer wrote:

A developer who apparently wants to remain anonymous has added the
function isEmpty() to the rtl::OUString class.  See
main/sal/inc/rtl/ustring.hxx for not much more information.


Sorry for being too short. The full semantic for isEmpty() is:

"The method isEmpty() returns true if the string is empty. If the length 
of the string is one or two or three or any number bigger than zero then 
isEmpty() returns false."


I added isEmpty() to make it possible to cleanly express the check for 
an empty string. In our codebase there were quite a few constructs such as

if( aString) {}
which were intended to mean
if( aString.isEmpty()) {}
What's funny is that the old construct compiled but it did the wrong 
thing: The string was implicitly converted to a pointer to its elements 
and that pointer was then compared against NULL. For our OUString that 
pointer was always non-NULL though.


Please see issue 123068 for further problems caused by the implicit 
conversion of the OUString to a pointer to its elements. This dangerous 
conversion is now disabled. By making the method private all such 
problems will be found and prevented by the compiler. When we're 
confident that all has been found the operator can be removed completely.



This in itself may not yet be very exciting but I hope that it is the
first of several improvements to one of our most frequently used
classes.  Sadly, we missed the opportunity to make some more substantial
but incompatible changes for the 4.0 release. However, some changes that
make OUString more accessible to new (and old) developers might include:

- Make construction from string literal more straightforward.  At the
moment you have to write
 ::rtl::OUString("text", sizeof("text"), RTL_TEXTENCODING_ASCII_US)
   or slightly shorter and safer
 ::rtl::OUString::createFromAscii("text")


Allocating heap space, transcoding a literal string to this memory and 
deallocating it later when the string is deleted are quite wasteful 
operations. Especially when considering that the literal string is 
already there. It would be great if constructs such

OUString( L"hello")
used the pointer to the UTF-16 literal directly instead of copying its 
contents around. The same applies for the OString(). The 'L' prefix is a 
Windows convention but C++11 has even more possibilities with its 
support for unicode string literals.


Also we shouldn't bother our main string classes with non-unicode 
support. Having external tooling for converting from/to other encodings 
is still needed though.


Looking over our string processing I'm confident that we could get along 
great with UTF-8 strings. Only when interfacing with other APIs an 
eventual conversion to UTF-16 would be needed.


And if we were using UTF-8 byte strings we could base them directly on 
the standard std::string.



- Conversion back to char* is not much better
 ::rtl::OUStringToOString(sOUStringVariable,
RTL_TEXTENCODING_ASCII_US).getStr()


This awful construct could be made much simpler if our strings were 
always unicode (UTF-8/UTF-16/UTF-32).



Do you have more ideas?


Using ideas from languages such as Python/Perl/Java for convenient and 
powerful string processing to replace the awkward string handling that 
is too often seen in our code base. E.g. having regexp enabled match() 
or search() methods would be a great start.


Herbert


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

Re: buildbot failure in ASF Buildbot on openoffice-linux64-nightly

[Oliver-Rainer Wittmann]

Hi,

sorry for the build breaker.

I will fix it in the next minutes.

Best regards, Oliver.

On 03.12.2013 08:33, build...@apache.org wrote:

Hi! , The openoffice-linux64-nightly builder has just completed a run

STATUS: Failure

  Build revision 1547275 on branch openoffice/trunk

  Snapshot results at: http://ci.apache.org/projects/openoffice/

  Build using the ASF buildslave: tethys_ubuntu

  Build results at: 
http://ci.apache.org/builders/openoffice-linux64-nightly/builds/815

  Build reason was: The Nightly scheduler named 'openoffice-linux64-nightly' 
triggered this build


  Yours Sincerely - The ASF Buildbot (http://ci.apache.org/)
--

  Join the bui...@apache.org mailing list for help with Buildbot






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

[Accessibility] Call for fixing IA2 bugs

[Steve Yin]

Hi all,

Stuart created a meta bug for tracking all IA2 issues. Now we have over ten
unresolved bugs. And I am working on 121761. After that I will focus on
123620, 123622, 123629.

But we still have no enough resources for fixing all issues in a short
time. So it is quite good if you have enthusiasm to work on these issues.
And If you have any problem, please let me know. Thanks.

-- 
Best Regards,

Steve Yin

Improvements of OUString

[Andre Fischer]

A developer who apparently wants to remain anonymous has added the 
function isEmpty() to the rtl::OUString class.  See 
main/sal/inc/rtl/ustring.hxx for not much more information.


This in itself may not yet be very exciting but I hope that it is the 
first of several improvements to one of our most frequently used 
classes.  Sadly, we missed the opportunity to make some more substantial 
but incompatible changes for the 4.0 release. However, some changes that 
make OUString more accessible to new (and old) developers might include:


- Make construction from string literal more straightforward.  At the 
moment you have to write

::rtl::OUString("text", sizeof("text"), RTL_TEXTENCODING_ASCII_US)
  or slightly shorter and safer
::rtl::OUString::createFromAscii("text")

- Conversion back to char* is not much better
::rtl::OUStringToOString(sOUStringVariable, 
RTL_TEXTENCODING_ASCII_US).getStr()
  and I have no idea what happens if the text encoding differs from the 
one used to construct sOUStringVariable.


Do you have more ideas?

Regards,
Andre

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