Re: [openoffice] branch AOO419 updated: Force SDK 10.11 at most Pass NULL, not -1 (!!)

[Arrigo Marchiori]

On Sun, Dec 27, 2020 at 01:46:46PM +0100, Peter Kovacs wrote:

> On 26.12.20 20:45, Jim Jagielski wrote:
> > So there is for sure a bug in AOO41X, but why it only seems to affect macOS 
> > BigSur is
> > unknown. It is this:
> > 
> > > diff --git a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx 
> > > b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> > > index f4d6c56..2ca9b8f 100644
> > > --- a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> > > +++ b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> > > @@ -195,7 +195,7 @@ VtableFactory::VtableFactory(): m_arena(
> > >  rtl_arena_create(
> > >  "bridges::cpp_uno::shared::VtableFactory",
> > >  sizeof (void *), // to satisfy alignment requirements
> > > -0, reinterpret_cast< rtl_arena_type * >(-1), allocExec, 
> > > freeExec, 0))
> > > +0, reinterpret_cast< rtl_arena_type * >(0), allocExec, freeExec, 
> > > 0))
> > > {
> > >  if (m_arena == 0) {
> > >  throw std::bad_alloc();
> > I *think* this solves the issue, and a quick-and-dirty compilation seems to 
> > indicate that, but
> > I will double check.
> > 
> > The question is: Does this warrant a full 4.1.9 release for ALL platforms? 
> > To my mind, it does.

My question is also: How has it possibly worked until today? :-)

> yes we should go for 4.1.9 because there is no other way to fix this
> quickly.

I also agree.

> Any one has any Idea what the rtl_arena_create 
> does?
> It looks to me like some C-Style factory, but I have a hard time
> understanding the code.
> 
> And so far I did not find an explanation for it.

I tried to look into it. I am not an expert of this low-level stuff,
but ``arena'''s seem to be an alternative to calling plain malloc(3)
and free(3).  They support a minimum size ("quantum") and some sort of
caching, that I could not fully understand.

They are somewhat chained among each other (each arena has a
``source''), with the ``public'' base object being gp_default_arena [1]
and two ``private'' objects being gp_arena_arena and gp_machdep_arena
inside /trunk/main/sal/rtl/source/alloc_arena.c

gp_machdep_arena is the ``source'' for the others, and it is
responsible of the actual allocation using function
rtl_machdep_alloc() [2]. Under Unix it cals mmap(2). Under Win32 it
calls VirtualAlloc() and under OS/2 it calls valloc().

Incidentally, the choice of mmap(2) over malloc(3) should be for
performance reasons, see [3]. It's a new thing I learned today ;-)

File main/bridges/source/cpp_uno/shared/vtablefactory.cxx declares its
own allocation function [4] that enables execution from the allocated
buffers (if I understood correctly).

I hope this makes sense.

References:

 1: 
http://opengrok.openoffice.org/xref/trunk/main/sal/rtl/source/alloc_arena.h?r=514f4c20#126
 
 2: 
http://opengrok.openoffice.org/xref/trunk/main/sal/rtl/source/alloc_arena.c?r=509a48ff#1182

 3: https://stackoverflow.com/questions/1739296/malloc-vs-mmap-in-c

 4: 
http://opengrok.openoffice.org/xref/trunk/main/bridges/source/cpp_uno/shared/vtablefactory.cxx?r=858958ab#77

-- 
Arrigo

http://rigo.altervista.org

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

Re: [openoffice] branch AOO419 updated: Force SDK 10.11 at most Pass NULL, not -1 (!!)

[Peter Kovacs]

On 26.12.20 20:45, Jim Jagielski wrote:

So there is for sure a bug in AOO41X, but why it only seems to affect macOS 
BigSur is
unknown. It is this:


diff --git a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx 
b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
index f4d6c56..2ca9b8f 100644
--- a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
+++ b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
@@ -195,7 +195,7 @@ VtableFactory::VtableFactory(): m_arena(
 rtl_arena_create(
 "bridges::cpp_uno::shared::VtableFactory",
 sizeof (void *), // to satisfy alignment requirements
-0, reinterpret_cast< rtl_arena_type * >(-1), allocExec, freeExec, 0))
+0, reinterpret_cast< rtl_arena_type * >(0), allocExec, freeExec, 0))
{
 if (m_arena == 0) {
 throw std::bad_alloc();

I *think* this solves the issue, and a quick-and-dirty compilation seems to 
indicate that, but
I will double check.

The question is: Does this warrant a full 4.1.9 release for ALL platforms? To 
my mind, it does.


yes we should go for 4.1.9 because there is no other way to fix this 
quickly.


Any one has any Idea what the rtl_arena_create 
does? 
It looks to me like some C-Style factory, but I have a hard time 
understanding the code.


And so far I did not find an explanation for it.




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


--
This is the Way! http://www.apache.org/theapacheway/index.html

Re: [openoffice] branch AOO419 updated: Force SDK 10.11 at most Pass NULL, not -1 (!!)

[Matthias Seidel]

Hi Jim,

Am 26.12.20 um 21:59 schrieb Jim Jagielski:
> I have uploaded a test build of en-US AOO419-dev for macOS. I have confirmed 
> on my macOS11/BigSur VM that this version opens docx files w/ no problems, 
> edits and saves them, etc...
>
> Please test:
>
> http://home.apache.org/~jim/AOO-builds/

I did a quick test with your build and can confirm that it opens docx
files without problems.
This was on macOS 11.2 beta

No other file formats were tested.

Regards,

   Matthias

>
> Cheers!
>
>> On Dec 26, 2020, at 3:54 PM, Rory O'Farrell  wrote:
>>
>> On Sat, 26 Dec 2020 21:43:06 +0100
>> Matthias Seidel > > wrote:
>>
>>> Hi Jim,
>>>
>>> Am 26.12.20 um 20:45 schrieb Jim Jagielski:
 So there is for sure a bug in AOO41X, but why it only seems to affect 
 macOS BigSur is
 unknown. It is this:

> diff --git a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx 
> b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> index f4d6c56..2ca9b8f 100644
> --- a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> +++ b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> @@ -195,7 +195,7 @@ VtableFactory::VtableFactory(): m_arena(
>rtl_arena_create(
>"bridges::cpp_uno::shared::VtableFactory",
>sizeof (void *), // to satisfy alignment requirements
> -0, reinterpret_cast< rtl_arena_type * >(-1), allocExec, 
> freeExec, 0))
> +0, reinterpret_cast< rtl_arena_type * >(0), allocExec, freeExec, 
> 0))
> {
>if (m_arena == 0) {
>throw std::bad_alloc();
 I *think* this solves the issue, and a quick-and-dirty compilation seems 
 to indicate that, but
 I will double check.

 The question is: Does this warrant a full 4.1.9 release for ALL platforms? 
 To my mind, it does.
>>> I will start a test build on Windows right now...
>>>
>>> We have a small Linux issue as well [1] and we can still put some minor
>>> cherry-picks into this build.
>>>
>>> +1 for a 4.1.9
>>>
>>> Regards,
>>>
>>>Matthias
>>>
>>> [1] https://bz.apache.org/ooo/show_bug.cgi?id=128413
>> I think all platforms should maintain the same version numbering.  
>>
>> There are occasional but frequent reports on Forum of problems with tables 
>> in Writer causing crashes when they are extended to cover multiple pages; my 
>> usual advice is to limit tables to one page, and repeat the structure if 
>> needed on subsequent pages.  This seems to work; I cannot comment from 
>> personal experience as my routine work does not involve Writer tables.  If 
>> this proposed fix involves tables it may have cross-talk into the Windows 
>> and other platforms.
>>
>> -- 
>> Rory O'Farrell mailto:ofarr...@iol.ie>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@openoffice.apache.org 
>> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [openoffice] branch AOO419 updated: Force SDK 10.11 at most Pass NULL, not -1 (!!)

[Matthias Seidel]

Hi Jim,

Am 26.12.20 um 21:59 schrieb Jim Jagielski:
> I have uploaded a test build of en-US AOO419-dev for macOS. I have confirmed 
> on my macOS11/BigSur VM that this version opens docx files w/ no problems, 
> edits and saves them, etc...
>
> Please test:
>
> http://home.apache.org/~jim/AOO-builds/

I will test it...

However, when we already have a new branch, we should bump up the
version numbers asap.

Matthias

>
> Cheers!
>
>> On Dec 26, 2020, at 3:54 PM, Rory O'Farrell  wrote:
>>
>> On Sat, 26 Dec 2020 21:43:06 +0100
>> Matthias Seidel > > wrote:
>>
>>> Hi Jim,
>>>
>>> Am 26.12.20 um 20:45 schrieb Jim Jagielski:
 So there is for sure a bug in AOO41X, but why it only seems to affect 
 macOS BigSur is
 unknown. It is this:

> diff --git a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx 
> b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> index f4d6c56..2ca9b8f 100644
> --- a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> +++ b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> @@ -195,7 +195,7 @@ VtableFactory::VtableFactory(): m_arena(
>rtl_arena_create(
>"bridges::cpp_uno::shared::VtableFactory",
>sizeof (void *), // to satisfy alignment requirements
> -0, reinterpret_cast< rtl_arena_type * >(-1), allocExec, 
> freeExec, 0))
> +0, reinterpret_cast< rtl_arena_type * >(0), allocExec, freeExec, 
> 0))
> {
>if (m_arena == 0) {
>throw std::bad_alloc();
 I *think* this solves the issue, and a quick-and-dirty compilation seems 
 to indicate that, but
 I will double check.

 The question is: Does this warrant a full 4.1.9 release for ALL platforms? 
 To my mind, it does.
>>> I will start a test build on Windows right now...
>>>
>>> We have a small Linux issue as well [1] and we can still put some minor
>>> cherry-picks into this build.
>>>
>>> +1 for a 4.1.9
>>>
>>> Regards,
>>>
>>>Matthias
>>>
>>> [1] https://bz.apache.org/ooo/show_bug.cgi?id=128413
>> I think all platforms should maintain the same version numbering.  
>>
>> There are occasional but frequent reports on Forum of problems with tables 
>> in Writer causing crashes when they are extended to cover multiple pages; my 
>> usual advice is to limit tables to one page, and repeat the structure if 
>> needed on subsequent pages.  This seems to work; I cannot comment from 
>> personal experience as my routine work does not involve Writer tables.  If 
>> this proposed fix involves tables it may have cross-talk into the Windows 
>> and other platforms.
>>
>> -- 
>> Rory O'Farrell mailto:ofarr...@iol.ie>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@openoffice.apache.org 
>> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [openoffice] branch AOO419 updated: Force SDK 10.11 at most Pass NULL, not -1 (!!)

[Jim Jagielski]

BUGZ seems to be a build issue, not a code one, but it still needs to be fixed 
and noted, likely with some autoconf checks that fakeroot exists.

> On Dec 26, 2020, at 3:43 PM, Matthias Seidel  
> wrote:
> 
> Hi Jim,
> 
> Am 26.12.20 um 20:45 schrieb Jim Jagielski:
>> So there is for sure a bug in AOO41X, but why it only seems to affect macOS 
>> BigSur is
>> unknown. It is this:
>> 
>>> diff --git a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx 
>>> b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
>>> index f4d6c56..2ca9b8f 100644
>>> --- a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
>>> +++ b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
>>> @@ -195,7 +195,7 @@ VtableFactory::VtableFactory(): m_arena(
>>>rtl_arena_create(
>>>"bridges::cpp_uno::shared::VtableFactory",
>>>sizeof (void *), // to satisfy alignment requirements
>>> -0, reinterpret_cast< rtl_arena_type * >(-1), allocExec, freeExec, 
>>> 0))
>>> +0, reinterpret_cast< rtl_arena_type * >(0), allocExec, freeExec, 
>>> 0))
>>> {
>>>if (m_arena == 0) {
>>>throw std::bad_alloc();
>> I *think* this solves the issue, and a quick-and-dirty compilation seems to 
>> indicate that, but
>> I will double check.
>> 
>> The question is: Does this warrant a full 4.1.9 release for ALL platforms? 
>> To my mind, it does.
> 
> I will start a test build on Windows right now...
> 
> We have a small Linux issue as well [1] and we can still put some minor
> cherry-picks into this build.
> 
> +1 for a 4.1.9
> 
> Regards,
> 
>Matthias
> 
> [1] https://bz.apache.org/ooo/show_bug.cgi?id=128413
> 
>> 
>> 
>> -
>> 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: [openoffice] branch AOO419 updated: Force SDK 10.11 at most Pass NULL, not -1 (!!)

[Jim Jagielski]

I have uploaded a test build of en-US AOO419-dev for macOS. I have confirmed on 
my macOS11/BigSur VM that this version opens docx files w/ no problems, edits 
and saves them, etc...

Please test:

http://home.apache.org/~jim/AOO-builds/

Cheers!

> On Dec 26, 2020, at 3:54 PM, Rory O'Farrell  wrote:
> 
> On Sat, 26 Dec 2020 21:43:06 +0100
> Matthias Seidel  > wrote:
> 
>> Hi Jim,
>> 
>> Am 26.12.20 um 20:45 schrieb Jim Jagielski:
>>> So there is for sure a bug in AOO41X, but why it only seems to affect macOS 
>>> BigSur is
>>> unknown. It is this:
>>> 
 diff --git a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx 
 b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
 index f4d6c56..2ca9b8f 100644
 --- a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
 +++ b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
 @@ -195,7 +195,7 @@ VtableFactory::VtableFactory(): m_arena(
rtl_arena_create(
"bridges::cpp_uno::shared::VtableFactory",
sizeof (void *), // to satisfy alignment requirements
 -0, reinterpret_cast< rtl_arena_type * >(-1), allocExec, freeExec, 
 0))
 +0, reinterpret_cast< rtl_arena_type * >(0), allocExec, freeExec, 
 0))
 {
if (m_arena == 0) {
throw std::bad_alloc();
>>> I *think* this solves the issue, and a quick-and-dirty compilation seems to 
>>> indicate that, but
>>> I will double check.
>>> 
>>> The question is: Does this warrant a full 4.1.9 release for ALL platforms? 
>>> To my mind, it does.
>> 
>> I will start a test build on Windows right now...
>> 
>> We have a small Linux issue as well [1] and we can still put some minor
>> cherry-picks into this build.
>> 
>> +1 for a 4.1.9
>> 
>> Regards,
>> 
>>Matthias
>> 
>> [1] https://bz.apache.org/ooo/show_bug.cgi?id=128413
> 
> I think all platforms should maintain the same version numbering.  
> 
> There are occasional but frequent reports on Forum of problems with tables in 
> Writer causing crashes when they are extended to cover multiple pages; my 
> usual advice is to limit tables to one page, and repeat the structure if 
> needed on subsequent pages.  This seems to work; I cannot comment from 
> personal experience as my routine work does not involve Writer tables.  If 
> this proposed fix involves tables it may have cross-talk into the Windows and 
> other platforms.
> 
> -- 
> Rory O'Farrell mailto:ofarr...@iol.ie>>
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org 
> 
> For additional commands, e-mail: dev-h...@openoffice.apache.org 
> 

Re: [openoffice] branch AOO419 updated: Force SDK 10.11 at most Pass NULL, not -1 (!!)

[Rory O'Farrell]

On Sat, 26 Dec 2020 21:43:06 +0100
Matthias Seidel  wrote:

> Hi Jim,
> 
> Am 26.12.20 um 20:45 schrieb Jim Jagielski:
> > So there is for sure a bug in AOO41X, but why it only seems to affect macOS 
> > BigSur is
> > unknown. It is this:
> >
> >> diff --git a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx 
> >> b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> >> index f4d6c56..2ca9b8f 100644
> >> --- a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> >> +++ b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> >> @@ -195,7 +195,7 @@ VtableFactory::VtableFactory(): m_arena(
> >> rtl_arena_create(
> >> "bridges::cpp_uno::shared::VtableFactory",
> >> sizeof (void *), // to satisfy alignment requirements
> >> -0, reinterpret_cast< rtl_arena_type * >(-1), allocExec, freeExec, 
> >> 0))
> >> +0, reinterpret_cast< rtl_arena_type * >(0), allocExec, freeExec, 
> >> 0))
> >> {
> >> if (m_arena == 0) {
> >> throw std::bad_alloc();
> > I *think* this solves the issue, and a quick-and-dirty compilation seems to 
> > indicate that, but
> > I will double check.
> >
> > The question is: Does this warrant a full 4.1.9 release for ALL platforms? 
> > To my mind, it does.
> 
> I will start a test build on Windows right now...
> 
> We have a small Linux issue as well [1] and we can still put some minor
> cherry-picks into this build.
> 
> +1 for a 4.1.9
> 
> Regards,
> 
>    Matthias
> 
> [1] https://bz.apache.org/ooo/show_bug.cgi?id=128413

I think all platforms should maintain the same version numbering.  

There are occasional but frequent reports on Forum of problems with tables in 
Writer causing crashes when they are extended to cover multiple pages; my usual 
advice is to limit tables to one page, and repeat the structure if needed on 
subsequent pages.  This seems to work; I cannot comment from personal 
experience as my routine work does not involve Writer tables.  If this proposed 
fix involves tables it may have cross-talk into the Windows and other platforms.

-- 
Rory O'Farrell 

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

Re: [openoffice] branch AOO419 updated: Force SDK 10.11 at most Pass NULL, not -1 (!!)

[Marcus]

Am 26.12.20 um 21:43 schrieb Matthias Seidel:

Am 26.12.20 um 20:45 schrieb Jim Jagielski:

So there is for sure a bug in AOO41X, but why it only seems to affect macOS 
BigSur is
unknown. It is this:


diff --git a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx 
b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
index f4d6c56..2ca9b8f 100644
--- a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
+++ b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
@@ -195,7 +195,7 @@ VtableFactory::VtableFactory(): m_arena(
 rtl_arena_create(
 "bridges::cpp_uno::shared::VtableFactory",
 sizeof (void *), // to satisfy alignment requirements
-0, reinterpret_cast< rtl_arena_type * >(-1), allocExec, freeExec, 0))
+0, reinterpret_cast< rtl_arena_type * >(0), allocExec, freeExec, 0))
{
 if (m_arena == 0) {
 throw std::bad_alloc();

I *think* this solves the issue, and a quick-and-dirty compilation seems to 
indicate that, but
I will double check.

The question is: Does this warrant a full 4.1.9 release for ALL platforms? To 
my mind, it does.


when we put in some minor bug fixes for all plattforms, then yes.
But this time they must be *really* small.


I will start a test build on Windows right now...

We have a small Linux issue as well [1] and we can still put some minor
cherry-picks into this build.

+1 for a 4.1.9

[1] https://bz.apache.org/ooo/show_bug.cgi?id=128413


Yes +1

Marcus


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

Re: [openoffice] branch AOO419 updated: Force SDK 10.11 at most Pass NULL, not -1 (!!)

[Matthias Seidel]

Hi Jim,

Am 26.12.20 um 20:45 schrieb Jim Jagielski:
> So there is for sure a bug in AOO41X, but why it only seems to affect macOS 
> BigSur is
> unknown. It is this:
>
>> diff --git a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx 
>> b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
>> index f4d6c56..2ca9b8f 100644
>> --- a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
>> +++ b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
>> @@ -195,7 +195,7 @@ VtableFactory::VtableFactory(): m_arena(
>> rtl_arena_create(
>> "bridges::cpp_uno::shared::VtableFactory",
>> sizeof (void *), // to satisfy alignment requirements
>> -0, reinterpret_cast< rtl_arena_type * >(-1), allocExec, freeExec, 
>> 0))
>> +0, reinterpret_cast< rtl_arena_type * >(0), allocExec, freeExec, 0))
>> {
>> if (m_arena == 0) {
>> throw std::bad_alloc();
> I *think* this solves the issue, and a quick-and-dirty compilation seems to 
> indicate that, but
> I will double check.
>
> The question is: Does this warrant a full 4.1.9 release for ALL platforms? To 
> my mind, it does.

I will start a test build on Windows right now...

We have a small Linux issue as well [1] and we can still put some minor
cherry-picks into this build.

+1 for a 4.1.9

Regards,

   Matthias

[1] https://bz.apache.org/ooo/show_bug.cgi?id=128413

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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [openoffice] branch AOO419 updated: Force SDK 10.11 at most Pass NULL, not -1 (!!)

[Jim Jagielski]

So there is for sure a bug in AOO41X, but why it only seems to affect macOS 
BigSur is
unknown. It is this:

> diff --git a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx 
> b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> index f4d6c56..2ca9b8f 100644
> --- a/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> +++ b/main/bridges/source/cpp_uno/shared/vtablefactory.cxx
> @@ -195,7 +195,7 @@ VtableFactory::VtableFactory(): m_arena(
> rtl_arena_create(
> "bridges::cpp_uno::shared::VtableFactory",
> sizeof (void *), // to satisfy alignment requirements
> -0, reinterpret_cast< rtl_arena_type * >(-1), allocExec, freeExec, 0))
> +0, reinterpret_cast< rtl_arena_type * >(0), allocExec, freeExec, 0))
> {
> if (m_arena == 0) {
> throw std::bad_alloc();

I *think* this solves the issue, and a quick-and-dirty compilation seems to 
indicate that, but
I will double check.

The question is: Does this warrant a full 4.1.9 release for ALL platforms? To 
my mind, it does.


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

Re: Putting Windows First ( was RE: null)

[Patricia Shanahan]

On 8/31/2016 10:25 AM, Dennis E. Hamilton wrote:




-Original Message- From: Patricia Shanahan
[mailto:p...@acm.org] Sent: Wednesday, July 13, 2016 12:57 To:
dev@openoffice.apache.org Subject: Re: Putting Windows First ( was
RE: null)


[ ... ] [orcmid]

I would like to suggest a way of squeezing out from between the
rock and hard place, and getting more developers:

Separate out the Windows build process. Pick one of the common
IDE's, and create a project file that sets all environment
variables for Windows. Get as close as possible to the step-by-step
build instructions for Windows being:

Check out the source from SVN.

Open the project file in $IDE$.

[orcmid]

I don't think it is necessary to have an IDE commitment.

Everything needed to do a build on Windows can be done with
command-line tools that are part of the Windows SDK.  Other externals
needed for builds can be obtained in Windows versions.  It is how
Visual Studio works -- it spawns command-line operations.


To me, direct use of command line tools feels like an awkward half-way
step between the punch cards I used when I started programming, and the
IDE's I use for most of my programming now.

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

Re: Putting Windows First ( was RE: null)

[Pedro Giffuni]

Hi Patricia;

I, for one, appreciate the idea: 80% of the users are Windows people and 
the project should be focusing on improving the experience on that platform.


OTOH, most of the active developers work on UNIX variant (and I suspect 
FreeBSD is the majority lately). I conceptually understand the Windows 
port is critical and would like to see it improve but I don't have the 
time or expertise to work on a platform different than the one I am 
using now.


May I say this shouldn't stop you: just create a branch and fork a more 
windows-friendly
port, we can cross-merge features between both branches. Also the 
capstone2013

branch, while badly outdated, may give new hints for a Windows build system.

Pedro.

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

Re: Putting Windows First ( was RE: null)

[Patricia Shanahan]

On 8/31/2016 10:25 AM, Dennis E. Hamilton wrote:




-Original Message-
From: Patricia Shanahan [mailto:p...@acm.org]
Sent: Wednesday, July 13, 2016 12:57
To: dev@openoffice.apache.org
Subject: Re: Putting Windows First ( was RE: null)


[ ... ]
[orcmid]

I would like to suggest a way of squeezing out from between the rock and
hard place, and getting more developers:

Separate out the Windows build process. Pick one of the common IDE's,
and create a project file that sets all environment variables for
Windows. Get as close as possible to the step-by-step build instructions
for Windows being:

Check out the source from SVN.

Open the project file in $IDE$.

[orcmid]

I don't think it is necessary to have an IDE commitment.

Everything needed to do a build on Windows can be done with command-line tools 
that are part of the Windows SDK.  Other externals needed for builds can be 
obtained in Windows versions.  It is how Visual Studio works -- it spawns 
command-line operations.

So long as the SVN Working copy has the correct ignore settings, once could 
then create projects if desired, and there might be a way to download a .zip of 
project files that could be expanded into a build slot in the Working copy.  
Although, since most of what is needed is in text and XML files, there is a way 
to do this at a lower level that doesn't require binaries in the source tree.

That should get rid of the CygWin dependency for Windows builds and let the 
available tools work at their best.

I think the bigger challenge is to be able to do incremental builds or even 
build libraries shared within AOO separately as a way to get problems of 
massive clean builds that take hours and don't help localize errors much.  
That's probably the way to build up the Windows build case anyhow.

Note: If one is careful about the filepath rewriting business in CygWin, one 
can execute Windows command-line tools pretty easily, using .bat files as 
bridges -- .bat files execute properly in CygWin and MSys where I have tried 
it, and they will work correctly when used directly via cmd.exe.  That is also 
how one gets environment variables set properly, etc.  (One needs to get around 
a couple of glitches where CygWin and its cousins treat the environment as case 
sensitive but the Windows SDK tools do not.)

And then there's [unit] testing to consider.


There are already unit tests that run in Eclipse.


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

GPL vs Apple Store (was Re: null)

[Pedro Giffuni]

Hi Damjan;
...

GPL apps are apparently not allowed in the Apple App Store (
http://www.zdnet.com/article/no-gpl-apps-for-apples-app-store/), and if the
source code is under the GPL, it doesn't stop being so in binary form, so
I'd love to know how they get away with it.

Damjan


The GPL vs Apple thing is pure propaganda: as long as the copyright 
owners don't complain Apple will not pull down the application.


In the VLC case one of the copyright owners complained so the community
ended up relicensing the code[1] and now the application is back.

The Battle of Wesnoth is another case where the game is GPLv2 and 
available (for money) on iOS. There is some internal agreement the

resulting money helps someone in the community and the sourcecode
is available.

NeoOffice does ship in the Apple store and the source code is rather
hard to get by (they use a private CVS, I think). They (ab)use the fact
that the copyright owners don't really care about making money from OOo
anymore.

They use code from LibreOffice but TDF doesn't have much control over 
the complete codebase. I think the ASF could stop it from being

distributed but we are not in the business of enforcing the GPL.

This said, the NeoOffice app store version seems to have way
too many limitations, and this is something that tends to happen with
all such "app stores" that expect some sort of sandboxing.

Just my $0.02,

Pedro.

[1] http://www.videolan.org/press/lgpl-libvlc.html


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

Re: Putting Windows First ( was RE: null)

[Patricia Shanahan]

On 7/17/2016 9:38 AM, Damjan Jovanovic wrote:

Windows lacks many of the external libraries present on *nix (jpeg, zlib,
curl, etc.),  meaning we have to build them internally. They build using
GNU autotools, which need a *nix shell like Cygwin. In other words, it
isn't even only AOO that needs Cygwin, it's our dependencies as well.


I'll have to think about that aspect. It may be the case that we need
two stages to the build process, one that every Windows developer can
do, and another that is done by specialists with *nix shell experience.

Most work on AOO is not going to require changes to those libraries, so
a C++ programmer could do useful work using prepared copies of them
rather than building them from scratch.


Also we need a portable build system, which any Visual Studio based
solution isn't.


Why do we need a portable build system?

Whether the build system is portable or not makes no difference at all
to end users. It is not part of the AOO functionality. It is merely a
tool that may save costs by avoiding duplication of effort compared to
having separate build systems for different target environments.

In this case I suspect that the total cost of the portable build system
is far higher than the total cost of having separate build systems for
Windows and for the *nix derived operating systems. That total cost
includes every Windows C++ programmer who is a user of AOO, and has been
scared off contributing to AOO by the arcane and fragile build process.



Damjan

On Wed, Jul 13, 2016 at 11:52 PM, Kay Schenk  wrote:




On 07/13/2016 12:56 PM, Patricia Shanahan wrote:

On 7/13/2016 10:38 AM, Dennis E. Hamilton wrote:




-Original Message- From: Damjan Jovanovic
[mailto:dam...@apache.org]

..

By the way, AOO code and build process are very *nix-centric,
leading to Windows being such a pain to develop for, that we would
gain more by dropping Windows support, than by dropping all other
platforms ;-).

[orcmid]

Yes.  I already made the point that, from the perspective of
developers, development of Windows is very contorted and development
for Linux is a pleasure.  It was done that way for the convenience of
Linux-oriented developers.  It creates an awful on-ramp for
cultivation of new developers.

The question: How does ceasing support for Windows serve the 87% of
our current user base?  The technical act is within the power of the
PMC to determine, and release managers could force the outcome. In my
estimation, the consequences would be quite terrible.

We may be "stuck between a rock and a hard place."


Damjan


I would like to suggest a way of squeezing out from between the rock
and hard place, and getting more developers:

Separate out the Windows build process. Pick one of the common IDE's,
and create a project file that sets all environment variables for
Windows. Get as close as possible to the step-by-step build
instructions for Windows being:

Check out the source from SVN.

Open the project file in $IDE$.

Build it.

In particular, use of a UNIX-derived shell must not be required for
Windows builds.

In this vision, the core work would be done on Windows, using an IDE.
There would still be a need for a small number of Linux etc. people to
handle building for their environments, and to keep the Windows-based
developers from building in unwarranted assumptions.


Patricia --

I think this approach was actually started as a Capstone Project in
2013. You might want to have a look at the information in:

http://svn.apache.org/viewvc/openoffice/branches/capstone2013/


--

MzK

"Time spent with cats is never wasted."
   -- Sigmund Freud


-
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: Putting Windows First ( was RE: null)

[Damjan Jovanovic]

Windows lacks many of the external libraries present on *nix (jpeg, zlib,
curl, etc.),  meaning we have to build them internally. They build using
GNU autotools, which need a *nix shell like Cygwin. In other words, it
isn't even only AOO that needs Cygwin, it's our dependencies as well.

Also we need a portable build system, which any Visual Studio based
solution isn't.

Damjan

On Wed, Jul 13, 2016 at 11:52 PM, Kay Schenk  wrote:

>
>
> On 07/13/2016 12:56 PM, Patricia Shanahan wrote:
> > On 7/13/2016 10:38 AM, Dennis E. Hamilton wrote:
> >>
> >>
> >>> -Original Message- From: Damjan Jovanovic
> >>> [mailto:dam...@apache.org]
> > ..
> >>> By the way, AOO code and build process are very *nix-centric,
> >>> leading to Windows being such a pain to develop for, that we would
> >>> gain more by dropping Windows support, than by dropping all other
> >>> platforms ;-).
> >> [orcmid]
> >>
> >> Yes.  I already made the point that, from the perspective of
> >> developers, development of Windows is very contorted and development
> >> for Linux is a pleasure.  It was done that way for the convenience of
> >> Linux-oriented developers.  It creates an awful on-ramp for
> >> cultivation of new developers.
> >>
> >> The question: How does ceasing support for Windows serve the 87% of
> >> our current user base?  The technical act is within the power of the
> >> PMC to determine, and release managers could force the outcome. In my
> >> estimation, the consequences would be quite terrible.
> >>
> >> We may be "stuck between a rock and a hard place."
> >>>
> >>> Damjan
> >
> > I would like to suggest a way of squeezing out from between the rock
> > and hard place, and getting more developers:
> >
> > Separate out the Windows build process. Pick one of the common IDE's,
> > and create a project file that sets all environment variables for
> > Windows. Get as close as possible to the step-by-step build
> > instructions for Windows being:
> >
> > Check out the source from SVN.
> >
> > Open the project file in $IDE$.
> >
> > Build it.
> >
> > In particular, use of a UNIX-derived shell must not be required for
> > Windows builds.
> >
> > In this vision, the core work would be done on Windows, using an IDE.
> > There would still be a need for a small number of Linux etc. people to
> > handle building for their environments, and to keep the Windows-based
> > developers from building in unwarranted assumptions.
>
> Patricia --
>
> I think this approach was actually started as a Capstone Project in
> 2013. You might want to have a look at the information in:
>
> http://svn.apache.org/viewvc/openoffice/branches/capstone2013/
>
>
> --
> 
> MzK
>
> "Time spent with cats is never wasted."
>-- Sigmund Freud
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Putting Windows First ( was RE: null)

[Kay Schenk]

On 07/13/2016 12:56 PM, Patricia Shanahan wrote:
> On 7/13/2016 10:38 AM, Dennis E. Hamilton wrote:
>>
>>
>>> -Original Message- From: Damjan Jovanovic
>>> [mailto:dam...@apache.org]
> ..
>>> By the way, AOO code and build process are very *nix-centric,
>>> leading to Windows being such a pain to develop for, that we would
>>> gain more by dropping Windows support, than by dropping all other
>>> platforms ;-).
>> [orcmid]
>>
>> Yes.  I already made the point that, from the perspective of
>> developers, development of Windows is very contorted and development
>> for Linux is a pleasure.  It was done that way for the convenience of
>> Linux-oriented developers.  It creates an awful on-ramp for
>> cultivation of new developers.
>>
>> The question: How does ceasing support for Windows serve the 87% of
>> our current user base?  The technical act is within the power of the
>> PMC to determine, and release managers could force the outcome. In my
>> estimation, the consequences would be quite terrible.
>>
>> We may be "stuck between a rock and a hard place."
>>>
>>> Damjan
>
> I would like to suggest a way of squeezing out from between the rock
> and hard place, and getting more developers:
>
> Separate out the Windows build process. Pick one of the common IDE's,
> and create a project file that sets all environment variables for
> Windows. Get as close as possible to the step-by-step build
> instructions for Windows being:
>
> Check out the source from SVN.
>
> Open the project file in $IDE$.
>
> Build it.
>
> In particular, use of a UNIX-derived shell must not be required for
> Windows builds.
>
> In this vision, the core work would be done on Windows, using an IDE.
> There would still be a need for a small number of Linux etc. people to
> handle building for their environments, and to keep the Windows-based
> developers from building in unwarranted assumptions.

Patricia --

I think this approach was actually started as a Capstone Project in
2013. You might want to have a look at the information in:

http://svn.apache.org/viewvc/openoffice/branches/capstone2013/


-- 

MzK

"Time spent with cats is never wasted."
   -- Sigmund Freud


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

Re: Putting Windows First ( was RE: null)

[Patricia Shanahan]

On 7/13/2016 10:38 AM, Dennis E. Hamilton wrote:




-Original Message- From: Damjan Jovanovic
[mailto:dam...@apache.org]

..

By the way, AOO code and build process are very *nix-centric,
leading to Windows being such a pain to develop for, that we would
gain more by dropping Windows support, than by dropping all other
platforms ;-).

[orcmid]

Yes.  I already made the point that, from the perspective of
developers, development of Windows is very contorted and development
for Linux is a pleasure.  It was done that way for the convenience of
Linux-oriented developers.  It creates an awful on-ramp for
cultivation of new developers.

The question: How does ceasing support for Windows serve the 87% of
our current user base?  The technical act is within the power of the
PMC to determine, and release managers could force the outcome. In my
estimation, the consequences would be quite terrible.

We may be "stuck between a rock and a hard place."


Damjan


I would like to suggest a way of squeezing out from between the rock and 
hard place, and getting more developers:


Separate out the Windows build process. Pick one of the common IDE's, 
and create a project file that sets all environment variables for 
Windows. Get as close as possible to the step-by-step build instructions 
for Windows being:


Check out the source from SVN.

Open the project file in $IDE$.

Build it.

In particular, use of a UNIX-derived shell must not be required for 
Windows builds.


In this vision, the core work would be done on Windows, using an IDE. 
There would still be a need for a small number of Linux etc. people to 
handle building for their environments, and to keep the Windows-based 
developers from building in unwarranted assumptions.


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

RE: Putting Windows First ( was RE: null)

[Dennis E. Hamilton]

> -Original Message-
> From: Damjan Jovanovic [mailto:dam...@apache.org]
> Sent: Wednesday, July 13, 2016 00:31
> To: Apache OO <dev@openoffice.apache.org>; Dennis Hamilton
> <dennis.hamil...@acm.org>
> Subject: Re: Putting Windows First ( was RE: null)
> 
> On Wed, Jul 13, 2016 at 4:17 AM, Dennis E. Hamilton
> <dennis.hamil...@acm.org
> > wrote:
> 
> >
> >
> > > -Original Message-
> > > From: Hammam Alyamani [mailto:ham...@fastmail.com]
> > > Sent: Monday, July 11, 2016 00:36
> > > To: dev@openoffice.apache.org
> > > Subject: Spam (11.853):null
> > >
> > > Hello There
> > >
> > > How is everyone is doing? I hope you are all good.
> > >
> > > I have a suggestion, since there is a dedicated Mac OS version of
> > > OpenOffuce called NeoOffice, and since everyone is just switching to
> > > LibreOffice because it's where everyone is at now, why not you
> dedicate
> > > Apache OpenOffice fo work on windows exclusivley?!
> > [orcmid]
> >
> > I assume you were referring to the fact that LibreOffice has very
> > successful take-up as part of Linux distributions.
> >
> > With regard to where Apache OpenOffice appeals, the following recent
> > report is useful for consideration:
> >
> >For the eight months since release of AOO 4.1.2 through 2016-06-30,
> >there are 29 million downloads, averaging about 850,000 per week
> down
> >to about 600,000 as we enter North American Summer in the last
> week.
> >Platform take-up is relatively constant:
> >
> >87.5% for Windows,
> > 7.8% for Macintosh, and
> > 4.7% for all other distributions
> >
> > So, if one gave priority to the community where AOO has the most
> reach,
> > your suggestion is not out of line.
> >
> > There is a conflict with the allegiance, interests, and skills of the
> AOO
> > developers though.  That essentially turns the above list on its head.
> The
> > way AOO is constructed reflects that emphasis.
> >
> > Suppose (1) There are enough developers having the capacity,
> capability,
> > availability, and will to pair the Apache OpenOffice code base down to
> one
> > devoted to modern Windows operation.  Then (2) that would probably
> have to
> > happen outside of the Apache OpenOffice project.  The same goes for
> making
> > an Apache OpenOffice that is completely a Java application.
> >
> >
> Can't we drop support for any operating system though a vote?
[orcmid] 

Yes, the Apache OpenOffice Project could resolve a couple of 
things, such as

 1. To stop providing binaries for particular platforms

 2. To stop providing binaries and language tools for 
particular localizations

This could be done by [PROPOSAL] on this list with adequate 
time to determine lazy consensus.

I suspect it would be difficult to achieve consensus.  There
could be a subsequent [VOTE] if it appeared that there could be
sufficient agreement in the community.  Even though only PMC
votes would be binding, the nature and extent of -1 votes has
to be given serious consideration.

> 
> Also how would this generalize to a Java version?
[orcmid] 

There can certainly be (2) a fork that morphs the codebase of the fork into a 
Java version.  There would still be the issues of (1) above.  I think that 
would in essence be a new product.  It might better serve multiple platforms 
but it is a significant effort and I don't think it can be a drop-in 
replacement for Apache OpenOffice in any practical time frame, if ever.  So it 
would have to mature separately.  That also separates the risk of barriers to 
successful creation of something like an AOO4Java.  (I have difficulty 
imagining that we could successfully suspend releases for the current binaries 
and move to Java directly and agreement to do that is likely even more 
difficult than dropping support for a popular platform.)

> 
> By the way, AOO code and build process are very *nix-centric, leading to
> Windows being such a pain to develop for, that we would gain more by
> dropping Windows support, than by dropping all other platforms ;-).
[orcmid] 

Yes.  I already made the point that, from the perspective of developers, 
development of Windows is very contorted and development for Linux is a 
pleasure.  It was done that way for the convenience of Linux-oriented 
developers.  It creates an awful on-ramp for cultivation of new developers.

The question: How does ceasing support for Windows serve the 87% of our current 
user base?  The technical act is within the power of the PMC to determine, and 
release managers could force the outcome. In my estimation, the consequences 
would be quite terrible.

We may be "stuck between a rock and a hard place."
> 
> Damjan


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

Re: Putting Windows First ( was RE: null)

[Hammam Alyamani]

Hello Dennis

Thanks a lot for taking time and explaining in your message.

--
  Best Regards
  Hammam Alyamani
  ham...@fastmail.com

On Wed, Jul 13, 2016, at 02:17, Dennis E. Hamilton wrote:
> 
> 
> > -Original Message-
> > From: Hammam Alyamani [mailto:ham...@fastmail.com]
> > Sent: Monday, July 11, 2016 00:36
> > To: dev@openoffice.apache.org
> > Subject: Spam (11.853):null
> > 
> > Hello There
> > 
> > How is everyone is doing? I hope you are all good.
> > 
> > I have a suggestion, since there is a dedicated Mac OS version of
> > OpenOffuce called NeoOffice, and since everyone is just switching to
> > LibreOffice because it's where everyone is at now, why not you dedicate
> > Apache OpenOffice fo work on windows exclusivley?!
> [orcmid] 
> 
> I assume you were referring to the fact that LibreOffice has very
> successful take-up as part of Linux distributions.
> 
> With regard to where Apache OpenOffice appeals, the following recent
> report is useful for consideration:
> 
>For the eight months since release of AOO 4.1.2 through 2016-06-30, 
>there are 29 million downloads, averaging about 850,000 per week down
>to about 600,000 as we enter North American Summer in the last week.  
>Platform take-up is relatively constant:
> 
>87.5% for Windows,
> 7.8% for Macintosh, and
> 4.7% for all other distributions
> 
> So, if one gave priority to the community where AOO has the most reach,
> your suggestion is not out of line.
> 
> There is a conflict with the allegiance, interests, and skills of the AOO
> developers though.  That essentially turns the above list on its head. 
> The way AOO is constructed reflects that emphasis.
> 
> Suppose (1) There are enough developers having the capacity, capability,
> availability, and will to pair the Apache OpenOffice code base down to
> one devoted to modern Windows operation.  Then (2) that would probably
> have to happen outside of the Apache OpenOffice project.  The same goes
> for making an Apache OpenOffice that is completely a Java application.  
> 
> Anyone could do that.  Apache OpenOffice is open source, and either kind
> of fork is permissible.  I suspect the barrier is that (1) cannot be
> satisfied.
> 
>  - Dennis
> > 
> > I don't see people complain about Neo being a Mac only package and
> > making use of Mac capabilities, so why not do the same for Apache
> > OpenOffice?
> > 
> > Just a thought, and looking forward to hear from you soon. Thank you.
> > 
> > --
> >   Best Regards
> >   Hammam Alyamani
> >   ham...@fastmail.com
> > 
> > -
> > 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: Putting Windows First ( was RE: null)

[Damjan Jovanovic]

On Wed, Jul 13, 2016 at 4:17 AM, Dennis E. Hamilton <dennis.hamil...@acm.org
> wrote:

>
>
> > -Original Message-
> > From: Hammam Alyamani [mailto:ham...@fastmail.com]
> > Sent: Monday, July 11, 2016 00:36
> > To: dev@openoffice.apache.org
> > Subject: Spam (11.853):null
> >
> > Hello There
> >
> > How is everyone is doing? I hope you are all good.
> >
> > I have a suggestion, since there is a dedicated Mac OS version of
> > OpenOffuce called NeoOffice, and since everyone is just switching to
> > LibreOffice because it's where everyone is at now, why not you dedicate
> > Apache OpenOffice fo work on windows exclusivley?!
> [orcmid]
>
> I assume you were referring to the fact that LibreOffice has very
> successful take-up as part of Linux distributions.
>
> With regard to where Apache OpenOffice appeals, the following recent
> report is useful for consideration:
>
>For the eight months since release of AOO 4.1.2 through 2016-06-30,
>there are 29 million downloads, averaging about 850,000 per week down
>to about 600,000 as we enter North American Summer in the last week.
>Platform take-up is relatively constant:
>
>87.5% for Windows,
> 7.8% for Macintosh, and
> 4.7% for all other distributions
>
> So, if one gave priority to the community where AOO has the most reach,
> your suggestion is not out of line.
>
> There is a conflict with the allegiance, interests, and skills of the AOO
> developers though.  That essentially turns the above list on its head.  The
> way AOO is constructed reflects that emphasis.
>
> Suppose (1) There are enough developers having the capacity, capability,
> availability, and will to pair the Apache OpenOffice code base down to one
> devoted to modern Windows operation.  Then (2) that would probably have to
> happen outside of the Apache OpenOffice project.  The same goes for making
> an Apache OpenOffice that is completely a Java application.
>
>
Can't we drop support for any operating system though a vote?

Also how would this generalize to a Java version?

By the way, AOO code and build process are very *nix-centric, leading to
Windows being such a pain to develop for, that we would gain more by
dropping Windows support, than by dropping all other platforms ;-).

Damjan

Putting Windows First ( was RE: null)

[Dennis E. Hamilton]

> -Original Message-
> From: Hammam Alyamani [mailto:ham...@fastmail.com]
> Sent: Monday, July 11, 2016 00:36
> To: dev@openoffice.apache.org
> Subject: Spam (11.853):null
> 
> Hello There
> 
> How is everyone is doing? I hope you are all good.
> 
> I have a suggestion, since there is a dedicated Mac OS version of
> OpenOffuce called NeoOffice, and since everyone is just switching to
> LibreOffice because it's where everyone is at now, why not you dedicate
> Apache OpenOffice fo work on windows exclusivley?!
[orcmid] 

I assume you were referring to the fact that LibreOffice has very successful 
take-up as part of Linux distributions.

With regard to where Apache OpenOffice appeals, the following recent report is 
useful for consideration:

   For the eight months since release of AOO 4.1.2 through 2016-06-30, 
   there are 29 million downloads, averaging about 850,000 per week down
   to about 600,000 as we enter North American Summer in the last week.  
   Platform take-up is relatively constant:

   87.5% for Windows,
7.8% for Macintosh, and
4.7% for all other distributions

So, if one gave priority to the community where AOO has the most reach, your 
suggestion is not out of line.

There is a conflict with the allegiance, interests, and skills of the AOO 
developers though.  That essentially turns the above list on its head.  The way 
AOO is constructed reflects that emphasis.

Suppose (1) There are enough developers having the capacity, capability, 
availability, and will to pair the Apache OpenOffice code base down to one 
devoted to modern Windows operation.  Then (2) that would probably have to 
happen outside of the Apache OpenOffice project.  The same goes for making an 
Apache OpenOffice that is completely a Java application.  

Anyone could do that.  Apache OpenOffice is open source, and either kind of 
fork is permissible.  I suspect the barrier is that (1) cannot be satisfied.

 - Dennis
> 
> I don't see people complain about Neo being a Mac only package and
> making use of Mac capabilities, so why not do the same for Apache
> OpenOffice?
> 
> Just a thought, and looking forward to hear from you soon. Thank you.
> 
> --
>   Best Regards
>   Hammam Alyamani
>   ham...@fastmail.com
> 
> -
> 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: null

[FR web forum]

Well, I mean free... of charge
For the rest:
https://wiki.openoffice.org/wiki/Mac_OS_X_Porting_-_contributions_from_NeoOffice


- Mail original -
De: "Mechtilde" <o...@mechtilde.de>
À: dev@openoffice.apache.org
Envoyé: Mardi 12 Juillet 2016 13:03:33
Objet: Re: null

Hello

Am 12.07.2016 um 11:23 schrieb FR web forum:
> NeoOffice is not free.


this is not true

NeoOffice is under GPL v2. But you can't take code from them to put it
into Code licenced under LGPL or Apache Lizence.

Regards

Mechtilde
> 
> - Mail original -
> De: "Hammam Alyamani" <ham...@fastmail.com>
> À: dev@openoffice.apache.org
> Envoyé: Lundi 11 Juillet 2016 09:35:59
> Objet: null
> 
> Hello There 
> 
> How is everyone is doing? I hope you are all good. 
> 
> I have a suggestion, since there is a dedicated Mac OS version of
> OpenOffuce called NeoOffice, and since everyone is just switching to
> LibreOffice because it's where everyone is at now, why not you dedicate
> Apache OpenOffice fo work on windows exclusivley?!
> 
> I don't see people complain about Neo being a Mac only package and
> making use of Mac capabilities, so why not do the same for Apache
> OpenOffice?
> 
> Just a thought, and looking forward to hear from you soon. Thank you.
> 
> --
>   Best Regards
>   Hammam Alyamani
>   ham...@fastmail.com
> 
> -
> 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
> 

-- 
Mechtilde Stehmann
## Apache OpenOffice.org
## Freie Office Suite für Linux, MacOSX, Windows
## Debian
## Loook, calender-exchange-provider, libreoffice-canzeley-client
## PGP encryption welcome
## Key-ID 0x141AAD7F


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

Re: null

[Damjan Jovanovic]

GPL apps are apparently not allowed in the Apple App Store (
http://www.zdnet.com/article/no-gpl-apps-for-apples-app-store/), and if the
source code is under the GPL, it doesn't stop being so in binary form, so
I'd love to know how they get away with it.

Damjan

On Tue, Jul 12, 2016 at 1:03 PM, Mechtilde <o...@mechtilde.de> wrote:

> Hello
>
> Am 12.07.2016 um 11:23 schrieb FR web forum:
> > NeoOffice is not free.
>
>
> this is not true
>
> NeoOffice is under GPL v2. But you can't take code from them to put it
> into Code licenced under LGPL or Apache Lizence.
>
> Regards
>
> Mechtilde
> >
> > - Mail original -
> > De: "Hammam Alyamani" <ham...@fastmail.com>
> > À: dev@openoffice.apache.org
> > Envoyé: Lundi 11 Juillet 2016 09:35:59
> > Objet: null
> >
> > Hello There
> >
> > How is everyone is doing? I hope you are all good.
> >
> > I have a suggestion, since there is a dedicated Mac OS version of
> > OpenOffuce called NeoOffice, and since everyone is just switching to
> > LibreOffice because it's where everyone is at now, why not you dedicate
> > Apache OpenOffice fo work on windows exclusivley?!
> >
> > I don't see people complain about Neo being a Mac only package and
> > making use of Mac capabilities, so why not do the same for Apache
> > OpenOffice?
> >
> > Just a thought, and looking forward to hear from you soon. Thank you.
> >
> > --
> >   Best Regards
> >   Hammam Alyamani
> >   ham...@fastmail.com
> >
> > -
> > 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
> >
>
> --
> Mechtilde Stehmann
> ## Apache OpenOffice.org
> ## Freie Office Suite für Linux, MacOSX, Windows
> ## Debian
> ## Loook, calender-exchange-provider, libreoffice-canzeley-client
> ## PGP encryption welcome
> ## Key-ID 0x141AAD7F
>
>

Re: null

[Mechtilde]

Hello

Am 12.07.2016 um 11:23 schrieb FR web forum:
> NeoOffice is not free.


this is not true

NeoOffice is under GPL v2. But you can't take code from them to put it
into Code licenced under LGPL or Apache Lizence.

Regards

Mechtilde
> 
> - Mail original -
> De: "Hammam Alyamani" <ham...@fastmail.com>
> À: dev@openoffice.apache.org
> Envoyé: Lundi 11 Juillet 2016 09:35:59
> Objet: null
> 
> Hello There 
> 
> How is everyone is doing? I hope you are all good. 
> 
> I have a suggestion, since there is a dedicated Mac OS version of
> OpenOffuce called NeoOffice, and since everyone is just switching to
> LibreOffice because it's where everyone is at now, why not you dedicate
> Apache OpenOffice fo work on windows exclusivley?!
> 
> I don't see people complain about Neo being a Mac only package and
> making use of Mac capabilities, so why not do the same for Apache
> OpenOffice?
> 
> Just a thought, and looking forward to hear from you soon. Thank you.
> 
> --
>   Best Regards
>   Hammam Alyamani
>   ham...@fastmail.com
> 
> -
> 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
> 

-- 
Mechtilde Stehmann
## Apache OpenOffice.org
## Freie Office Suite für Linux, MacOSX, Windows
## Debian
## Loook, calender-exchange-provider, libreoffice-canzeley-client
## PGP encryption welcome
## Key-ID 0x141AAD7F



signature.asc
Description: OpenPGP digital signature

Re: null

[FR web forum]

NeoOffice is not free.

- Mail original -
De: "Hammam Alyamani" <ham...@fastmail.com>
À: dev@openoffice.apache.org
Envoyé: Lundi 11 Juillet 2016 09:35:59
Objet: null

Hello There 

How is everyone is doing? I hope you are all good. 

I have a suggestion, since there is a dedicated Mac OS version of
OpenOffuce called NeoOffice, and since everyone is just switching to
LibreOffice because it's where everyone is at now, why not you dedicate
Apache OpenOffice fo work on windows exclusivley?!

I don't see people complain about Neo being a Mac only package and
making use of Mac capabilities, so why not do the same for Apache
OpenOffice?

Just a thought, and looking forward to hear from you soon. Thank you.

--
  Best Regards
  Hammam Alyamani
  ham...@fastmail.com

-
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

null

[Hammam Alyamani]

Hello There 

How is everyone is doing? I hope you are all good. 

I have a suggestion, since there is a dedicated Mac OS version of
OpenOffuce called NeoOffice, and since everyone is just switching to
LibreOffice because it's where everyone is at now, why not you dedicate
Apache OpenOffice fo work on windows exclusivley?!

I don't see people complain about Neo being a Mac only package and
making use of Mac capabilities, so why not do the same for Apache
OpenOffice?

Just a thought, and looking forward to hear from you soon. Thank you.

--
  Best Regards
  Hammam Alyamani
  ham...@fastmail.com

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

review granted: [Issue 126635] Possible null pointer dereference : [Attachment 85139] patch to main/sw/source/core/doc/poolfmt.cxx

[bugzilla]

j.nitsc...@ok.de has granted  review:
Issue 126635: Possible null pointer dereference
https://bz.apache.org/ooo/show_bug.cgi?id=126635

Attachment 85139: patch to main/sw/source/core/doc/poolfmt.cxx
https://bz.apache.org/ooo/attachment.cgi?id=85139=edit



--- Comment #14 from j.nitsc...@ok.de ---
Comment on attachment 85139
  --> https://bz.apache.org/ooo/attachment.cgi?id=85139
patch to main/sw/source/core/doc/poolfmt.cxx

tested the patch on linux vm. works as intended:
the next style property is set for 'List x Start' and 'List x End' to 'List x'
(this changed)
'List x' and 'List x Cont.' have themselves as next style (stays as before)

'Numbering' formatting work in the same way

btw: next style is applied when you start the next paragraph (enter key)

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

review denied: [Issue 126635] Possible null pointer dereference : [Attachment 85136] patch to main/sw/source/core/doc/poolfmt.cxx

[bugzilla]

j.nitsc...@ok.de has denied  review:
Issue 126635: Possible null pointer dereference
https://bz.apache.org/ooo/show_bug.cgi?id=126635

Attachment 85136: patch to main/sw/source/core/doc/poolfmt.cxx
https://bz.apache.org/ooo/attachment.cgi?id=85136=edit



--- Comment #6 from j.nitsc...@ok.de ---
Comment on attachment 85136
  --> https://bz.apache.org/ooo/attachment.cgi?id=85136
patch to main/sw/source/core/doc/poolfmt.cxx

thank you for the patch
but I wouldn't approve the current patch
1. use spaces instead of tabs
https://wiki.openoffice.org/wiki/Cpp_Coding_Standards/FORMAT
https://wiki.openoffice.org/wiki/Cpp_Coding_Standards/FORMAT/NoTabs
2. the new return path when pColl is NULL breaks functionality
3. as you noted in comment 2, lcl_SetNumBul is a helper of
SwDoc::GetTextCollFromPool and the null check should be there if anywhere

@AppChecker review requests in bugzilla get automatic send to dev-list this has
nothing to do with the issue status
it's done to highlight patches and faster review process

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

review requested: [Issue 126635] Possible null pointer dereference : [Attachment 85139] patch to main/sw/source/core/doc/poolfmt.cxx

[bugzilla]

orcmid <orc...@apache.org> has asked  for review:
Issue 126635: Possible null pointer dereference
https://bz.apache.org/ooo/show_bug.cgi?id=126635

Attachment 85139: patch to main/sw/source/core/doc/poolfmt.cxx
https://bz.apache.org/ooo/attachment.cgi?id=85139=edit



--- Comment #10 from orcmid <orc...@apache.org> ---
Created attachment 85139
  --> https://bz.apache.org/ooo/attachment.cgi?id=85139=edit
patch to main/sw/source/core/doc/poolfmt.cxx

This modification removes an incorrect test that never passes and that if it
did pass would cause a null-pointer crash.

In all uses of this helper procedure, the pColl parameter is always the value
of pNewColl as allocated and set in the method SwDoc::GetTxtCollFromPool

pNewColl can never be NULL at the time lcl_SetNumBul is called simply because a
NULL value would have causes a crash earlier in GetTxtCollFromPool.  So long as
all allocations by *new* throw exceptions and never return NULL pointers, that
is not possible.

ANALYSIS

The first place that could happen is at line 335, if a NULL pointer is obtained
from a table.  Assume that entries to the table are always of pointers returned
from successful *new* operations.  

Then the ultimate place that pNewColl could be NULL and crash before
lcl_SetNumBul is ever called is at line 383 with a NULL returned by the *new*
operation at whichever of line 375 or 380 is performed.

By default, failed *new* operations throw an exception and do not return any
value.

There is no need to check pNewColl in GetTxtCollFromPool so long as the *new*
implementation used throws exceptions when an allocation/instantiation fails.

NOTE

The consequences of lcl_SetNumBul never accomplishing anything previously is a
greater concern for the safety of this patch.  We need to be satisfied that it
suddenly functioning does not have unintended consequences.

I would like broader review than that which led to the previous patch being
unacceptable.

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

review canceled: [Issue 126635] Possible null pointer dereference : [Attachment 85136] patch to main/sw/source/core/doc/poolfmt.cxx

[bugzilla]

orcmid <orc...@apache.org> has canceled orcmid <orc...@apache.org>'s request
for review:
Issue 126635: Possible null pointer dereference
https://bz.apache.org/ooo/show_bug.cgi?id=126635

Attachment 85136: patch to main/sw/source/core/doc/poolfmt.cxx
https://bz.apache.org/ooo/attachment.cgi?id=85136=edit

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

review requested: [Issue 126635] Possible null pointer dereference : [Attachment 85139] patch to main/sw/source/core/doc/poolfmt.cxx

[Pedro Giffuni]

FWIW,

The same issue appears to have been confirmed by Coverity CID 704875.

Regards,

Pedro.


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

review requested: [Issue 126635] Possible null pointer dereference : [Attachment 85136] patch to main/sw/source/core/doc/poolfmt.cxx

[bugzilla]

orcmid <orc...@apache.org> has asked orcmid <orc...@apache.org> for review:
Issue 126635: Possible null pointer dereference
https://bz.apache.org/ooo/show_bug.cgi?id=126635

Attachment 85136: patch to main/sw/source/core/doc/poolfmt.cxx
https://bz.apache.org/ooo/attachment.cgi?id=85136=edit



--- Comment #4 from orcmid <orc...@apache.org> ---
Created attachment 85136
  --> https://bz.apache.org/ooo/attachment.cgi?id=85136=edit
patch to main/sw/source/core/doc/poolfmt.cxx

In the unpatched version, the misplaced check on pColl for NULL caused 
pColl->SetNextTxtFmtColl( ) to never be executed.

In this patch, the final operation is executed when pColl != NULL.

This may cause unexpected behavior if the failure of this operation is
compensated for anywhere else in the code.

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

4.1.2_release_blocker requested: [Issue 120706] CRASH - navigating tables containing NULL timestamps in DataSourceBrowser using mysql JDBC connector causes AOO to crash

[bugzilla]

Keith N. McKenna k...@apache.org has asked  for 4.1.2_release_blocker:
Issue 120706: CRASH - navigating tables containing NULL timestamps in
DataSourceBrowser using mysql JDBC connector causes AOO to crash
https://bz.apache.org/ooo/show_bug.cgi?id=120706



--- Comment #6 from Keith N. McKenna k...@apache.org ---
As this issue causes a crash and there is a fix for it, I would nominate it as
a 4.1.2 release blocker.

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

review canceled: [Issue 125071] When saving as doc, odt file crashes and immediately recovers : [Attachment 83538] check SwFmt::GetItemState()'s ppItem for NULL

[bugzilla]

h...@apache.org h...@apache.org has canceled h...@apache.org 
h...@apache.org's
request for review:
Issue 125071: When saving as doc, odt file crashes and immediately recovers
https://issues.apache.org/ooo/show_bug.cgi?id=125071

Attachment 83538: check SwFmt::GetItemState()'s ppItem for NULL
https://issues.apache.org/ooo/attachment.cgi?id=83538action=edit

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

review requested: [Issue 125071] When saving as doc, odt file crashes and immediately recovers : [Attachment 83542] check SwFmt::GetItemState()'s ppItem for NULL

[bugzilla]

h...@apache.org h...@apache.org has asked  for review:
Issue 125071: When saving as doc, odt file crashes and immediately recovers
https://issues.apache.org/ooo/show_bug.cgi?id=125071

Attachment 83542: check SwFmt::GetItemState()'s ppItem for NULL
https://issues.apache.org/ooo/attachment.cgi?id=83542action=edit

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

review granted: [Issue 125071] When saving as doc, odt file crashes and immediately recovers : [Attachment 83542] check SwFmt::GetItemState()'s ppItem for NULL

[bugzilla]

Oliver-Rainer Wittmann o...@apache.org has granted h...@apache.org
h...@apache.org's request for review:
Issue 125071: When saving as doc, odt file crashes and immediately recovers
https://issues.apache.org/ooo/show_bug.cgi?id=125071

Attachment 83542: check SwFmt::GetItemState()'s ppItem for NULL
https://issues.apache.org/ooo/attachment.cgi?id=83542action=edit


--- Additional Comments from Oliver-Rainer Wittmann o...@apache.org
adjusted patch looks good - bring it into trunk

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

review requested: [Issue 125071] When saving as doc, odt file crashes and immediately recovers : [Attachment 83538] check SwFmt::GetItemState()'s ppItem for NULL

[bugzilla]

h...@apache.org h...@apache.org has asked Oliver-Rainer Wittmann
o...@apache.org for review:
Issue 125071: When saving as doc, odt file crashes and immediately recovers
https://issues.apache.org/ooo/show_bug.cgi?id=125071

Attachment 83538: check SwFmt::GetItemState()'s ppItem for NULL
https://issues.apache.org/ooo/attachment.cgi?id=83538action=edit


--- Additional Comments from h...@apache.org h...@apache.org
The SwFmt::GetItemState() method shoud check its ppItem pointer argument before
assigning something into it, because NULL is the default value according to
main/sw/inc/format.hxx and thus is allowed.

The suggested patch solves the crash for both Keith's sample document and for
the autotests, but debug logging still emits warnings like Unhandled
SfxPoolItem with id X which hint at a deeper problem.

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

4.1.0_release_blocker denied: [Issue 124509] MacOSX 64 crash in the scripting environment due to getenv(PATH) returning a null value

[bugzilla]

j...@apache.org has denied r...@apache.org's request for 4.1.0_release_blocker:
Issue 124509: MacOSX 64 crash in the scripting environment due to
getenv(PATH) returning a null value
https://issues.apache.org/ooo/show_bug.cgi?id=124509


--- Additional Comments from j...@apache.org
no showstopper for AOO 4.1, we will try to fix it asap on trunk

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

4.1.0_release_blocker requested: [Issue 124509] MacOSX 64 crash in the scripting environment due to getenv(PATH) returning a null value

[bugzilla]

r...@apache.org has asked  for 4.1.0_release_blocker:
Issue 124509: MacOSX 64 crash in the scripting environment due to
getenv(PATH) returning a null value
https://issues.apache.org/ooo/show_bug.cgi?id=124509


--- Additional Comments from r...@apache.org
Using the AOO Java scripting framework to load the ooRexx interpreter via JNI,
the ooRexx interpreter causes a crash while initializing as it receives a null
value when issuing a getenv(PATH). It seems that for unknown reasons the
process environment is not set up properly.

[ooRexx needs the process environment being set up correctly, in order to find
its other pieces to load while initializing.]

As this works flawlessly on 32- and 64-bit Linux and on 32-bit Windows, and
also used to work at least on 32-bit MacOSX in the OOo 3.x days, I assume this
to be a regression.

In the case that someone can spot and fix this on MacOSX, I would like to
propose this as a showstopper bug. Any help to fix this, highly appreciated!

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

Re: 4.1.0_release_blocker requested: [Issue 124509] MacOSX 64 crash in the scripting environment due to getenv(PATH) returning a null value

[Rony G. Flatscher (Apache)]

On 25.03.2014 16:10, bugzi...@apache.org wrote:
 r...@apache.org has asked  for 4.1.0_release_blocker:
 Issue 124509: MacOSX 64 crash in the scripting environment due to
 getenv(PATH) returning a null value
 https://issues.apache.org/ooo/show_bug.cgi?id=124509


 --- Additional Comments from r...@apache.org
 Using the AOO Java scripting framework to load the ooRexx interpreter via JNI,
 the ooRexx interpreter causes a crash while initializing as it receives a null
 value when issuing a getenv(PATH). It seems that for unknown reasons the
 process environment is not set up properly.

 [ooRexx needs the process environment being set up correctly, in order to find
 its other pieces to load while initializing.]

 As this works flawlessly on 32- and 64-bit Linux and on 32-bit Windows, and
 also used to work at least on 32-bit MacOSX in the OOo 3.x days, I assume this
 to be a regression.

 In the case that someone can spot and fix this on MacOSX, I would like to
 propose this as a showstopper bug. Any help to fix this, highly appreciated!

 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org
Updated the issue https://issues.apache.org/ooo/show_bug.cgi?id=124509 with a 
list of environment
variables defined when the Java scripting framework executes a script. Maybe 
the names of those
environment symbols (like PYTHONPATH or URE_BOOTSTRAP) may allow to spot the 
code area, where this
gets defined on MacOSX?

---rony


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

review denied: [Bug 124188] CRASH when pasting grouped contents from Draw over a selected image : [Attachment 82591] Avoid NULL pointer access

[bugzilla]

Oliver-Rainer Wittmann o...@apache.org has denied Andre
awf@googlemail.com's request for review:
Bug 124188: CRASH when pasting grouped contents from Draw over a selected image
https://issues.apache.org/ooo/show_bug.cgi?id=124188

Attachment 82591: Avoid NULL pointer access
https://issues.apache.org/ooo/attachment.cgi?id=82591action=edit


--- Additional Comments from Oliver-Rainer Wittmann o...@apache.org
The patch avoids the crash, but the document is afterwards in an inconsistent
state as the anchor attribute for the as-character anchored object inside the
corresponding text node is missing.

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

review requested: [Bug 124188] CRASH when pasting grouped contents from Draw over a selected image : [Attachment 82591] Avoid NULL pointer access

[bugzilla]

Andre awf@googlemail.com has asked Oliver-Rainer Wittmann
o...@apache.org for review:
Bug 124188: CRASH when pasting grouped contents from Draw over a selected image
https://issues.apache.org/ooo/show_bug.cgi?id=124188

Attachment 82591: Avoid NULL pointer access
https://issues.apache.org/ooo/attachment.cgi?id=82591action=edit

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