Re: URGENT: Need to build new version based on 4.1.4

2017-11-18 Thread Patricia Shanahan
I see you have checked in some Mac building changes. Would it be better 
to keep the two fixes separate, or encourage testing both of them together?


On 11/18/2017 1:20 PM, Jim Jagielski wrote:

We do have the AOO415 branch! :)


On Nov 18, 2017, at 2:11 PM, Patricia Shanahan  wrote:

There is a bug in my LinkManager changes. Specifically, I made the totally 
newbie mistake of accessing memory based on a pointer without allowing for it 
being null, and it turns out it can be null :-(

The primary report for this is https://bz.apache.org/ooo/show_bug.cgi?id=127581, 
"Writer crashes after copying all content".

I would have expected the failure to be some form of access violation. However, 
recent e-mails have convinced me that some paths include catch blocks that 
conceal all exceptions, so it may be the root cause of other problems.

I have checked a fix into the trunk, revision 1814994. However, trunk has other 
changes.

The simplest way to check whether other bug reports are due to this is to build 
a version that is identical to 4.1.4 except for the one fix. Anything that 
works with that but not with 4.1.4 is a duplicate. Of course, the more 
duplicates we have the worse the problem and the more urgent a fix.

I am going ahead and doing the fix in my 4.1.5 working copy, but activating 
4.1.5 is a broader decision.


-
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: URGENT: Need to build new version based on 4.1.4

2017-11-18 Thread Jim Jagielski
We do have the AOO415 branch! :)

> On Nov 18, 2017, at 2:11 PM, Patricia Shanahan  wrote:
> 
> There is a bug in my LinkManager changes. Specifically, I made the totally 
> newbie mistake of accessing memory based on a pointer without allowing for it 
> being null, and it turns out it can be null :-(
> 
> The primary report for this is 
> https://bz.apache.org/ooo/show_bug.cgi?id=127581, "Writer crashes after 
> copying all content".
> 
> I would have expected the failure to be some form of access violation. 
> However, recent e-mails have convinced me that some paths include catch 
> blocks that conceal all exceptions, so it may be the root cause of other 
> problems.
> 
> I have checked a fix into the trunk, revision 1814994. However, trunk has 
> other changes.
> 
> The simplest way to check whether other bug reports are due to this is to 
> build a version that is identical to 4.1.4 except for the one fix. Anything 
> that works with that but not with 4.1.4 is a duplicate. Of course, the more 
> duplicates we have the worse the problem and the more urgent a fix.
> 
> I am going ahead and doing the fix in my 4.1.5 working copy, but activating 
> 4.1.5 is a broader decision.
> 
> 
> -
> 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: URGENT: Need to build new version based on 4.1.4

2017-11-18 Thread Patricia Shanahan
I'm attaching the patch in case anyone else wants to build their own 
test version.


On 11/18/2017 11:11 AM, Patricia Shanahan wrote:
There is a bug in my LinkManager changes. Specifically, I made the 
totally newbie mistake of accessing memory based on a pointer without 
allowing for it being null, and it turns out it can be null :-(


The primary report for this is 
https://bz.apache.org/ooo/show_bug.cgi?id=127581, "Writer crashes after 
copying all content".


I would have expected the failure to be some form of access violation. 
However, recent e-mails have convinced me that some paths include catch 
blocks that conceal all exceptions, so it may be the root cause of other 
problems.


I have checked a fix into the trunk, revision 1814994. However, trunk 
has other changes.


The simplest way to check whether other bug reports are due to this is 
to build a version that is identical to 4.1.4 except for the one fix. 
Anything that works with that but not with 4.1.4 is a duplicate. Of 
course, the more duplicates we have the worse the problem and the more 
urgent a fix.


I am going ahead and doing the fix in my 4.1.5 working copy, but 
activating 4.1.5 is a broader decision.



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

Index: main/sfx2/source/appl/linkmgr2.cxx
===
--- main/sfx2/source/appl/linkmgr2.cxx  (revision 1813359)
+++ main/sfx2/source/appl/linkmgr2.cxx  (working copy)
@@ -158,9 +158,13 @@
SvBaseLinkRef* pTmp = new SvBaseLinkRef( pLink );
 pLink->SetLinkManager( this );
aLinkTbl.Insert( pTmp, aLinkTbl.Count() );
-   Window *parent = GetPersist()->GetDialogParent();
if (mAutoAskUpdateAllLinks)
{
+   Window *parent = NULL;
+   SfxObjectShell* persist = GetPersist();
+   if (persist != NULL)
+   parent = GetPersist()->GetDialogParent();
+
SetUserAllowsLinkUpdate(pLink, GetUserAllowsLinkUpdate(parent));
}


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

URGENT: Need to build new version based on 4.1.4

2017-11-18 Thread Patricia Shanahan
There is a bug in my LinkManager changes. Specifically, I made the 
totally newbie mistake of accessing memory based on a pointer without 
allowing for it being null, and it turns out it can be null :-(


The primary report for this is 
https://bz.apache.org/ooo/show_bug.cgi?id=127581, "Writer crashes after 
copying all content".


I would have expected the failure to be some form of access violation. 
However, recent e-mails have convinced me that some paths include catch 
blocks that conceal all exceptions, so it may be the root cause of other 
problems.


I have checked a fix into the trunk, revision 1814994. However, trunk 
has other changes.


The simplest way to check whether other bug reports are due to this is 
to build a version that is identical to 4.1.4 except for the one fix. 
Anything that works with that but not with 4.1.4 is a duplicate. Of 
course, the more duplicates we have the worse the problem and the more 
urgent a fix.


I am going ahead and doing the fix in my 4.1.5 working copy, but 
activating 4.1.5 is a broader decision.



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



Re: FYI: The OO 4.1.4 Mac problem

2017-11-18 Thread Dave Fisher
Great!

Another regression was just reported -

https://bz.apache.org/ooo/show_bug.cgi?id=127600

I wonder if it is fixed too?

Sent from my iPhone

> On Nov 18, 2017, at 10:17 AM, Larry Gusaas  wrote:
> 
> Database and Spreadsheets both work. Regressions are fixed. I haven't done 
> any further testing yet.
> 
> Larry
> 
>> On 2017-11-18, 9:13 AM Jim Jagielski wrote:
>> fingers-crossed...
>> 
>> I have updated the files in devtools related to my successful build of AOO 
>> 4.1.4
>> for macOS that appears to fix both regressions.
>> 
>> Basically:
>> 
>>  o I had to use Xcode7 on Sierra
>>  o I had to compile frameworks w/ -O1 instead of -O2
>> 
>> Uploads to our dev dist repo are happening as we speak.
>> 
>> __
>> 
> 
> -- 
> 
> -
> 
> Larry I. Gusaas
> Moose Jaw, Saskatchewan   Canada
> Website:  http://larry-gusaas.com
> 
> “To me, photography is the simultaneous recognition, in a fraction of a 
> second, of the significance of an event as well as of a precise organization 
> of forms which give that event its proper expression.” Henri Cartier-Bresson
> 
> "An artist is never ahead of his time but most people are far behind theirs." 
> - Edgard Varese
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


Re: FYI: The OO 4.1.4 Mac problem

2017-11-18 Thread Larry Gusaas

Database and Spreadsheets both work. Regressions are fixed. I haven't done any 
further testing yet.

Larry

On 2017-11-18, 9:13 AM Jim Jagielski wrote:

fingers-crossed...

I have updated the files in devtools related to my successful build of AOO 4.1.4
for macOS that appears to fix both regressions.

Basically:

  o I had to use Xcode7 on Sierra
  o I had to compile frameworks w/ -O1 instead of -O2

Uploads to our dev dist repo are happening as we speak.

__



--

-

Larry I. Gusaas
Moose Jaw, Saskatchewan   Canada
Website:  http://larry-gusaas.com

“To me, photography is the simultaneous recognition, in a fraction of a second, of the 
significance of an event as well as of a precise organization of forms which give that event 
its proper expression.” Henri Cartier-Bresson


"An artist is never ahead of his time but most people are far behind theirs." - 
Edgard Varese




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



Re: FYI: The OO 4.1.4 Mac problem

2017-11-18 Thread Jim Jagielski
In the meantime, I need to figure out how to, in main/frameworks,
have the gbuild system automatically change the -O2 to -O1 for
MACOS... It's not CFLAGS or CXXFLAGS. There doesn't look
to be a way to change gb_COMPILEROPTFLAGS and/or CFLAGSOPT
via the gbuild eval->call functionality.

> On Nov 18, 2017, at 10:13 AM, Jim Jagielski  wrote:
> 
> fingers-crossed...
> 
> I have updated the files in devtools related to my successful build of AOO 
> 4.1.4
> for macOS that appears to fix both regressions.
> 
> Basically:
> 
> o I had to use Xcode7 on Sierra
> o I had to compile frameworks w/ -O1 instead of -O2
> 
> Uploads to our dev dist repo are happening as we speak.
> -
> 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: FYI: The OO 4.1.4 Mac problem

2017-11-18 Thread Dave Fisher
Hi Jim -

Good news.

I’m out of pocket until tomorrow evening. Perhaps Larry is available.

Regards,
Dave

Sent from my iPhone

> On Nov 18, 2017, at 7:43 AM, Matthias Seidel  
> wrote:
> 
> Hi Jim,
> 
> That would be great!
> 
> Unfortunately I can't help with testing on macOS...
> 
> Regards, Matthias
> 
> 
>> Am 18.11.2017 um 16:13 schrieb Jim Jagielski:
>> fingers-crossed...
>> 
>> I have updated the files in devtools related to my successful build of AOO 
>> 4.1.4
>> for macOS that appears to fix both regressions.
>> 
>> Basically:
>> 
>> o I had to use Xcode7 on Sierra
>> o I had to compile frameworks w/ -O1 instead of -O2
>> 
>> Uploads to our dev dist repo are happening as we speak.
>> -
>> 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: FYI: The OO 4.1.4 Mac problem

2017-11-18 Thread Matthias Seidel
Hi Jim,

That would be great!

Unfortunately I can't help with testing on macOS...

Regards, Matthias


Am 18.11.2017 um 16:13 schrieb Jim Jagielski:
> fingers-crossed...
>
> I have updated the files in devtools related to my successful build of AOO 
> 4.1.4
> for macOS that appears to fix both regressions.
>
> Basically:
>
>  o I had to use Xcode7 on Sierra
>  o I had to compile frameworks w/ -O1 instead of -O2
>
> Uploads to our dev dist repo are happening as we speak.
> -
> 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: Debugging Base's "Create Table in Design View"

2017-11-18 Thread Damjan Jovanovic
Yesterday, in the email thread entitled "FYI: The OO 4.1.4 Mac problem",
Dave Fisher asked me for help with the problem where the "Create Table in
Design View" does nothing on a Mac release.

Was the problem fixed in the meanwhile? Is there another problem? What
happened? Do you still need my help?

Thank you
Damjan

On Sat, Nov 18, 2017 at 5:47 AM, Patricia Shanahan  wrote:

> Is it possible that this is another manifestation of
> https://bz.apache.org/ooo/show_bug.cgi?id=127581
>
> If so, it will not happen in the trunk.
>
>
> On 11/17/2017 10:47 AM, Damjan Jovanovic wrote:
>
>> tl;dr:
>> Put a breakpoint on dbaui::DatabaseObjectView::doDispatch or
>> /full/path/to/main/dbaccess/source/ui/misc/databaseobjectview.cxx:120
>> just
>> before you click the "Create Table..." button.
>> Step through it in your debugger line by line and document how for you
>> get.
>> Then recursively repeat and step deeper and deeper into the last statement
>> before the exception is thrown, until you narrow down the failure at its
>> source.
>> A debug build of main/dbaccess may also help ("build debug=true" in
>> main/dbaccess).
>> Email us back with your findings.
>>
>> The long version:
>> --
>>
>> Opening the "Create Table in Design View" dialog and attaching GDB and
>> running "thread apply all bt" doesn't show anything useful, so we go
>> through the source instead.
>>
>> The text "Create Table in Design View" must come from somewhere:
>>
>> [main/dbaccess]$ grep "Create Table in Design View" * -R
>> source/ui/app/app.src:Text [ en-US ] = "Create Table in Design
>> View..."
>> ;
>>
>> Looking at that file we see:
>>
>> String RID_STR_NEW_TABLE
>> {
>>  Text [ en-US ] = "Create Table in Design View..." ;
>> };
>>
>> Now look for RID_STR_NEW_TABLE:
>>
>> [main/dbaccess]$ grep RID_STR_NEW_TABLE * -R
>> source/ui/app/app.src:String RID_STR_NEW_TABLE
>> source/ui/app/app.src:String RID_STR_NEW_TABLE_AUTO
>> source/ui/app/dbu_app.hrc:#define RID_STR_NEW_TABLE
>> RID_STR_APP_START + 4
>> source/ui/app/dbu_app.hrc:#define RID_STR_NEW_TABLE_AUTO
>> RID_STR_APP_START + 5
>> source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry(
>> ".uno:DBNewTable", RID_STR_TABLES_HELP_TEXT_DESIGN, RID_STR_NEW_TABLE )
>> );
>> source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry(
>> ".uno:DBNewTableAutoPilot", RID_STR_TABLES_HELP_TEXT_WIZARD,
>> RID_STR_NEW_TABLE_AUTO ) );
>>
>> Only the source/ui/app/AppDetailView.cxx is useful, as it contains actual
>> code. This is what it does:
>>
>>  switch ( _eType )
>>  {
>>  case E_TABLE:
>>  rList.push_back( TaskEntry( ".uno:DBNewTable",
>> RID_STR_TABLES_HELP_TEXT_DESIGN, RID_STR_NEW_TABLE ) );
>>  rList.push_back( TaskEntry( ".uno:DBNewTableAutoPilot",
>> RID_STR_TABLES_HELP_TEXT_WIZARD, RID_STR_NEW_TABLE_AUTO ) );
>>  rList.push_back( TaskEntry( ".uno:DBNewView",
>> RID_STR_VIEWS_HELP_TEXT_DESIGN, RID_STR_NEW_VIEW, true ) );
>>  _rData.nTitleId = RID_STR_TABLES_CONTAINER;
>>  break;
>>
>> which doesn't help much. But it does link it to ".uno:DBNewTable". Where
>> else is that used?
>>
>> [main/dbaccess]$ grep "\.uno:DBNewTable" * -R
>> source/ui/control/toolboxcontroller.cxx:
>> m_aStates.insert(TCommandState::value_type(::rtl::OUString(
>> RTL_CONSTASCII_USTRINGPARAM(".uno:DBNewTable"))  ,sal_True));
>> source/ui/app/AppController.cxx:implDescribeSupportedFeature(
>> ".uno:DBNewTable", ID_NEW_TABLE_DESIGN,   CommandGroup::INSERT
>> );
>> source/ui/app/AppController.cxx:implDescribeSupportedFeature(
>> ".uno:DBNewTableAutoPilot",ID_NEW_TABLE_DESIGN_AUTO_PILOT,
>> source/ui/app/app.src:Command = ".uno:DBNewTable";
>> source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry(
>> ".uno:DBNewTable", RID_STR_TABLES_HELP_TEXT_DESIGN, RID_STR_NEW_TABLE )
>> );
>> source/ui/app/AppDetailView.cxx:rList.push_back( TaskEntry(
>> ".uno:DBNewTableAutoPilot", RID_STR_TABLES_HELP_TEXT_WIZARD,
>> RID_STR_NEW_TABLE_AUTO ) );
>> uiconfig/dbapp/menubar/menubar.xml:> menu:id=".uno:DBNewTable"/>
>>
>> Here we have a number of matches. The menubar.xml is related to the GUI
>> layout, we want the code. The app.src we've already looked at. That only
>> leaves toolboxcontroller.cxx, AppController.cxx and AppDetailView.cxx.
>> AppDetailView.cxx only uses ".uno:DBNewTable" for what we've already seen,
>> to add it to rList. toolboxcontroller.cxx also only uses that string in
>> some initialization code. So through a process of elimination, we're only
>> left with AppController.cxx.
>>
>> It contains only 1 matching line:
>>
>>  implDescribeSupportedFeature( ".uno:DBNewTable",
>> ID_NEW_TABLE_DESIGN,   CommandGroup::INSERT );
>>
>> We continue on with this ID_NEW_TABLE_DESIGN:
>>
>> [main/dbaccess]$ grep ID_NEW_TABLE_DESIGN * -R
>> source/ui/app/AppController.cxx:case ID_NEW_TABLE_DESIGN:
>> 

Re: Release 4.1.4

2017-11-18 Thread Matthias Seidel
Hallo Josef,

Am 24.10.2017 um 19:41 schrieb Josef Latt:
>
>
> Am 24.10.2017 um 18:27 schrieb Matthias Seidel:
>>
>> Das war vielleicht bei 4.1.3 so, aber in 4.1.4 sind alle mir bekannten
>> Probleme mit Ubuntu behoben.
>> Es lag auch nie an Ubuntu (bzw. Gnome), es trat halt nur dort auf. Die
>> Fehler waren in unserem Code.
>
> In der 17.04 hatte ich nichts mehr von Libreoffice auf dem Rechner.
> AOO-Dateien wurden im Nautilus mit dem Standardtext-Icon angezeigt.
> Nach dem Upgrade auf die 17.10 (Gnome) waren die Libreoffice-Icons
> wieder auf dem Rechner. Libreoffice dagegen selbst nicht. Also war
> wiederum händisches Löschen angesagt -> Standardtext-Icons.

Ich vermute weiterhin, dass unser Script für die Desktop-Integration
irgendwie nicht greift. Denn statt der Standard-Icons sollten die von
OpenOffice angezeigt werden (auch ohne löschen der zwangsgebündelten
LO-Icons).

>
> Noch was:  Ich starte AOO immer über das Startcenter, das als Favorit
> abgelegt ist, mit dem Effekt, dass ein zweites Icon unten in der
> Favoritenleiste erscheint. Öffne ich nun z.B. eine Calc-Datei wird
> selbiges durch das entsprechende Icon ersetzt. Das Öffnen weiterer
> Dateien (Writer usw.) wird durch die entsprechende Anzahl roter Punkte
> neben dem Calc-Icon angezeigt. Das Löschen der Calc-Datei ändert das
> Icon nichts, bleibt Calc.
> Das zusätzliche Icon entspricht immer dem Icon der zuerst geöffneten
> Datei, sofern man zuvor nicht alle Dateien geschlossen hat.
>
> Mit dem Eintrag 'StartupWMClass=OpenOffice 4.1.4' (ohne
> Anführungszeichen) in die Startcenter Desktop-Datei gibt es beim
> Öffnen von Dateien kein zusätzliches Icon mehr. Anzahl der geöffneten
> Dateien -> rote Punkte neben dem Startcenter-Icon.

Komme jetzt erst dazu es unter 17.10 zu testen. Guter Tipp, funktioniert
einwandfrei!

Gruß, Matthias

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




smime.p7s
Description: S/MIME Cryptographic Signature


Re: FYI: The OO 4.1.4 Mac problem

2017-11-18 Thread Jim Jagielski
fingers-crossed...

I have updated the files in devtools related to my successful build of AOO 4.1.4
for macOS that appears to fix both regressions.

Basically:

 o I had to use Xcode7 on Sierra
 o I had to compile frameworks w/ -O1 instead of -O2

Uploads to our dev dist repo are happening as we speak.
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Simpler Windows builds, oowintool, and Cygwin64

2017-11-18 Thread Matthias Seidel
Hi John,

Am 16.11.2017 um 11:48 schrieb John D'Orazio:
> On Wed, Nov 15, 2017 at 6:17 PM, Matthias Seidel > wrote:
>> I just updated config.guess and config.sub to the latest version.
>>
>> See: https://www.gnu.org/software/gettext/manual/html_node/
>> config_002eguess.html
>>
>> Regards, Matthias
>>
> Just wondering if after this update the configure script still runs fine?
> About a year or so ago when I was testing a cygwin x64 build process, I
> noticed that after updating config.guess and config.sub in the cygwin
> terminal the configure script starting choking on config.sub. Were you able
> to get past this?

Seems we ran into the same error messages... ;-)
I can confirm that the recently updated config.guess/config.sub do not
break the build and error messages are gone.
However it doesn't build with Cygwin64 because it detects
"x86_64-unknown-cygwin" I will try "--build=i686-pc-cygwin" now.

>
> Unfortunately I don't have my system set up to build ATM, unfortunately my
> "powerful" HP laptop comes with a miserly 128GB SSD as the main drive and
> Visual Studio can't be installed on a secondary drive... I'm having a heck
> of a time finding a bigger compatible SSD but I hope to resolve this soon,
> and set up my build system again...

My laptop was low on disk space too. But I could add an additional SSD
in a PCIe slot... ;-)
I run Ubuntu 16.04.3 with Windows 10 in VirtualBox.

> As these obstacles are removed the Step by step guide can be updated, I had
> opened a section about building with cywgwin x64 and I started jotting
> provisional notes down, I'd say this looks like the time to update them:
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Testing_build_with_Cygwin_64_bit
> .

I will update the Wiki step by step now.

Regards, Matthias



smime.p7s
Description: S/MIME Cryptographic Signature