RC1 Candidate

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate (windows 64, msvcr100.dll)

tmacchant
----- Original Message -----

> From: John W. Eaton 
> To: Markus Mützel 
> Cc: Octave-Maintainers
> Date: 2019/1/29, Tue 00:15
> Subject: Re: RC1 Candidate
>
> On 1/27/19 9:11 AM, "Markus Mützel" wrote:
>>  Am 26. Januar 2019 um 16:25 Uhr schrieb "Rik":
>>>  The first release candidate for Octave version 5.1 is available at
>>>  ftp://alpha.gnu.org/gnu/octave/.
>>>
>>>  I've tried it on my vanilla Linux system (./configure, make) and
> building
>>>  is just fine.  Running 'make check' passes with no failed
> tests.
>>>
>>>  Please download and experiment on other systems.
>>
>>  Will there be official Windows installers for the release candidate?
>
> Yes, the installer along with 7z and zip files are on alpha.gnu.org now.
>
> I only made versions for Windows 64 with the usual 32-bit Fortran
> integer configuration.
>
> jwe



I also met application error (0xc000007b) octave-5.0.90 for windows 
from  alpha.gnu.org/gnu/octave/.

My path on windows 10

C:\ProgramData\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Programs\gs\gs9.23\bin;C:\Programs\gs\gs9.23\lib;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\WINDOWS\System32\OpenSSH\;C:\Programs\plzip-1.5-rc2.win;;C:\Program Files (x86)\Microsoft VS Code\bin;C:\Users\MATSUOKA LAB\AppData\Local\Microsoft\WindowsApps;;C:\texlive\2018\bin\win32


From cmd I erase the path.
set PATH=


and execute octave.vbs
then
octave-gui.exe claims  no msvcr100.dll.

Only 32 bit version exists on my system.
I installed microsoft visual c++ 2010 service pack 1 redistributable package 
and Problem is solved.

On 64bit octave-4.4.1 for windows runs without 64bit version msvcr100.dll.

What is changed from 5.0.90?

(Note that octave-cli.exe runs without 64bit version msvcr100.dll for octave-5.0.90)

Tatsuro

Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate (windows 64, msvcr100.dll)

mmuetzel
Am 29. Januar 2019 um 04:05 Uhr schrieb "Tatsuro MATSUOKA":

> I also met application error (0xc000007b) octave-5.0.90 for windows 
> from  alpha.gnu.org/gnu/octave/.
>
> My path on windows 10
>
> C:\ProgramData\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Programs\gs\gs9.23\bin;C:\Programs\gs\gs9.23\lib;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\WINDOWS\System32\OpenSSH\;C:\Programs\plzip-1.5-rc2.win;;C:\Program Files (x86)\Microsoft VS Code\bin;C:\Users\MATSUOKA LAB\AppData\Local\Microsoft\WindowsApps;;C:\texlive\2018\bin\win32
>
>
> From cmd I erase the path.
> set PATH=
>
>
> and execute octave.vbs
> then
> octave-gui.exe claims  no msvcr100.dll.
>
> Only 32 bit version exists on my system.
> I installed microsoft visual c++ 2010 service pack 1 redistributable package 
> and Problem is solved.
>
> On 64bit octave-4.4.1 for windows runs without 64bit version msvcr100.dll.
>
> What is changed from 5.0.90?
>
> (Note that octave-cli.exe runs without 64bit version msvcr100.dll for octave-5.0.90)
>
> Tatsuro

Running octave-cli.exe through Dependency Walker shows that the dependency on msvcr100.dll is through qt5core.dll --> icuin63.dll.
Can we bundle the redistributable package in the nsis installer or somehow else tell that we dependent on MS Visual C++ 2010?

Alternatively, can we compile ICU without the dependency on MS Visual C++?

I also wonder if the reports of people not being able to start newer versions of Octave is related to this.

Markus

Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate

mmuetzel
In reply to this post by mmuetzel
Am 28. Januar 2019 um 22:32 Uhr schrieb "Markus Mützel"
> I will try to test on a system with HiDPI monitor and for a user name containing non-ASCII characters within the next few days.

GUI and figures scale mainly correctly on a HiDPI monitor on Windows 10 for me. Also moving the windows from the main HiDPI monitor to a second monitor with standard DPI and back scales mainly correctly.
What I noticed so far:
The text in the drop down lists with the current directory seems to shrink slightly when I move the GUI from the HiDPI monitor to the normal one.
The results of "demo uitable 1" are correctly displayed on the HiDPI monitor. On the second monitor with standard DPI, the table is rendered too large (see the attached screenshots).

I do not see the warning dialog on startup and don't see any failing tests on this PC:
Summary:

  PASS                            15478
  FAIL                                0
  XFAIL (reported bug)               25
  SKIP (missing feature)             52
  SKIP (run-time condition)          31

Markus

uitable_high_dpi.png (21K) Download Attachment
uitable_standard_dpi.png (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate (windows 64, msvcr100.dll)

nrjank
In reply to this post by mmuetzel

> octave-gui.exe claims  no msvcr100.dll.

I also wonder if the reports of people not being able to start newer versions of Octave is related to this.


missing dll errors are usually explicit.  Tatsuro, I'm assuming you got a 'missing msvcr100.dll' error message? I would assume many of the windows start errors would have been reported with the error message if it was given. Also note he had to clear the path for this to become apparent, so might not be that common an occurrence?
Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate

Ardid, Salva
In reply to this post by Rik-4

El dissabte, 26 de gener de 2019, a les 10:25:45 EST, Rik va escriure:

  The first release candidate for Octave version 5.1 is available at
  ftp://alpha.gnu.org/gnu/octave/.
 
  I've tried it on my vanilla Linux system (./configure, make) and building
  is just fine.  Running 'make check' passes with no failed tests.
 
  Please download and experiment on other systems.
 
  --Rik
 
 
Hi,

I tested Octave 5.0.90 and identified a regression in the copyobj function:

f1 = figure;
plot(0:10)
f2 = figure;
Copyobj(get(f1,'children'),f2);

error: copyobj: =: nonconformant arguments (op1 is 1x1, op2 is 1x0)
error: called from
    copyobj at line 70 column 15

This works fine in Octave 4.x versions and Matlab



Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate (windows 64, msvcr100.dll)

John W. Eaton
Administrator
In reply to this post by mmuetzel
On 1/29/19 5:22 AM, "Markus Mützel" wrote:

> Running octave-cli.exe through Dependency Walker shows that the dependency on msvcr100.dll is through qt5core.dll --> icuin63.dll.
> Can we bundle the redistributable package in the nsis installer or somehow else tell that we dependent on MS Visual C++ 2010?
>
> Alternatively, can we compile ICU without the dependency on MS Visual C++?

We are building icu with GCC so I don't know why it depends on a
particular version of the msvc runtime library.

> I also wonder if the reports of people not being able to start newer versions of Octave is related to this.

Possibly.

Also, I was guessing the change happened when we enabled ICU for the
mxe-octave build, but that happened well before the 4.4.0 release (made
on 2018-04-30):

   http://hg.octave.org/mxe-octave/rev/0deb76a57fae

Since that change, I disabled icu for 32-bit Windows builds because Qt
apparently doesn't use it on those systems.

Looking at these pages, it's not clear to me what the status of icu is
in Qt:

   https://wiki.qt.io/Qt_5_ICU
   https://wiki.qt.io/Locale_Support_in_Qt_5

jwe

Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate

nrjank
In reply to this post by mmuetzel
GNU Octave Version: 5.0.90 (hg id: 82865ccb62c2)
GNU Octave License: GNU General Public License
Operating System: MINGW32_NT-6.2 Windows 6.2  x86_64

Windows 10 v1709, zip archive package:

Summary:
  PASS                            15504
  FAIL                                0
  XFAIL (reported bug)               25
  SKIP (missing feature)             52
  SKIP (run-time condition)           5

and I happily notice I can copy and paste more than one line from the interpreter. haven't tried testing any other windows specific bugs yet.
Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate (windows 64, msvcr100.dll)

mmuetzel
In reply to this post by John W. Eaton
Am 29. Januar 2019 um 15:54 Uhr schrieb "John W. Eaton":
> On 1/29/19 5:22 AM, "Markus Mützel" wrote:
>
> > Running octave-cli.exe through Dependency Walker shows that the dependency on msvcr100.dll is through qt5core.dll --> icuin63.dll.
> > Can we bundle the redistributable package in the nsis installer or somehow else tell that we dependent on MS Visual C++ 2010?
> >
> > Alternatively, can we compile ICU without the dependency on MS Visual C++?
>
> We are building icu with GCC so I don't know why it depends on a
> particular version of the msvc runtime library.

That's probably because we pass "CXXFLAGS='--std=gnu++0x' LIBS=-lmsvcr100" to configure in icu4c.mk.
Can we omit setting these variables?

> > I also wonder if the reports of people not being able to start newer versions of Octave is related to this.
>
> Possibly.
>
> Also, I was guessing the change happened when we enabled ICU for the
> mxe-octave build, but that happened well before the 4.4.0 release (made
> on 2018-04-30):
>
>    http://hg.octave.org/mxe-octave/rev/0deb76a57fae
>

That time frame matches the reports that the affected users are able to run 4.2.1, but 4.4.1 doesn't start for them.

Markus

Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate (windows 64, msvcr100.dll)

John W. Eaton
Administrator
On 1/29/19 10:05 AM, "Markus Mützel" wrote:

>> We are building icu with GCC so I don't know why it depends on a
>> particular version of the msvc runtime library.
>
> That's probably because we pass "CXXFLAGS='--std=gnu++0x' LIBS=-lmsvcr100" to configure in icu4c.mk.

Oh, I didn't know.  John D Might know why that was done.

> Can we omit setting these variables?

I'll try to build without those options.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate (windows 64, msvcr100.dll)

John W. Eaton
Administrator
On 1/29/19 10:17 AM, John W. Eaton wrote:

> On 1/29/19 10:05 AM, "Markus Mützel" wrote:
>
>>> We are building icu with GCC so I don't know why it depends on a
>>> particular version of the msvc runtime library.
>>
>> That's probably because we pass "CXXFLAGS='--std=gnu++0x'
>> LIBS=-lmsvcr100" to configure in icu4c.mk.
>
> Oh, I didn't know.  John D Might know why that was done.
>
>> Can we omit setting these variables?
>
> I'll try to build without those options.

I built without the options and it seems to work.  Change checked in here:

   http://hg.octave.org/mxe-octave/rev/76828d146a8d

jwe

Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate (windows 64, msvcr100.dll)

John Donoghue-3
In reply to this post by tmacchant
>
> Message: 1
> Date: Tue, 29 Jan 2019 10:17:26 -0500
> From: "John W. Eaton" <[hidden email]>
> To: Markus M?tzel <[hidden email]>
> Cc: [hidden email], Octave-Maintainers
> <[hidden email]>
> Subject: Re: RC1 Candidate (windows 64, msvcr100.dll)
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 1/29/19 10:05 AM, "Markus M?tzel" wrote:
>
> >> We are building icu with GCC so I don't know why it depends on a
> >> particular version of the msvc runtime library.
> >
> > That's probably because we pass "CXXFLAGS='--std=gnu++0x' LIBS=-
> lmsvcr100" to configure in icu4c.mk.
>
> Oh, I didn't know.  John D Might know why that was done.
>
> > Can we omit setting these variables?
>
> I'll try to build without those options.
>
> jwe
>
>

I think I borrowed heavily from mxe.cc for the file, so it might have come
from there. I see on their current file, it doesn’t have the libs def but
still has the compiler flag.
 


Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate (windows 64, msvcr100.dll)

mmuetzel
In reply to this post by John W. Eaton
Am 29. Januar 2019 um 18:43 Uhr schrieb "John W. Eaton":

> On 1/29/19 10:17 AM, John W. Eaton wrote:
> > On 1/29/19 10:05 AM, "Markus Mützel" wrote:
> >
> >>> We are building icu with GCC so I don't know why it depends on a
> >>> particular version of the msvc runtime library.
> >>
> >> That's probably because we pass "CXXFLAGS='--std=gnu++0x'
> >> LIBS=-lmsvcr100" to configure in icu4c.mk.
> >
> > Oh, I didn't know.  John D Might know why that was done.
> >
> >> Can we omit setting these variables?
> >
> > I'll try to build without those options.
>
> I built without the options and it seems to work.  Change checked in here:
>
>    http://hg.octave.org/mxe-octave/rev/76828d146a8d

Thanks.
I rebuilt with the current MXE Octave and Dependency Walker can no longer find any dependency on that library.
The test suite also passes.

Markus

Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate

mmuetzel
In reply to this post by mmuetzel
Am 28. Januar 2019 um 22:32 Uhr schrieb "Markus Mützel"
> I will try to test on a system with HiDPI monitor and for a user name containing non-ASCII characters within the next few days.

There was still one bug that prevented running the test suite for a user name with non-ASCII characters on Windows. But that should be fixed with:
http://hg.savannah.gnu.org/hgweb/octave/rev/c942659a57e6

Markus

Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate

tmacchant


I have tested octave-5.0.90 on my windows 10.
Unlike others I met one FAIL

libinterp\corefcn\graphics.cc-tst .............................. PASS   52/53
                                                                   FAIL    1

Summary:

  PASS                            15499
  FAIL                                1
  XFAIL (reported bug)               25
  SKIP (missing feature)             52
  SKIP (run-time condition)           9

>>>>> processing H:\Octave\OCTAVE~1.90-\mingw64\share\octave\5.0.90\etc\tests\libinterp\corefcn\graphics.cc-tst
***** test
 hf = figure ("visible", "off");
 hax = axes ("parent", hf);
 unwind_protect
   hctx1 = uicontextmenu ("parent", hf);
   hctx2 = uicontextmenu ("parent", hf);
   set (hf, "uicontextmenu", hctx2);
   set (hax, "uicontextmenu", hctx2);
   assert (get (hf, "uicontextmenu"), hctx2);
   assert (get (hax, "uicontextmenu"), hctx2);
   assert (get (hf, "children"), [hctx2; hctx1; hax]);
   delete (hctx2);
   assert (get (hf, "uicontextmenu"), []);
   assert (get (hax, "uicontextmenu"), []);
   assert (get (hf, "children"), [hctx1; hax]);
   set (hf, "uicontextmenu", hctx1);
   assert (get (hf, "uicontextmenu"), hctx1);
   set (hf, "uicontextmenu", []);
   assert (get (hf, "uicontextmenu"), []);
   assert (get (hf, "children"), [hctx1; hax]);
 unwind_protect_cleanup
   close (hf);
 end_unwind_protect;
!!!!! test failed
ASSERT errors for:  assert (get (hf, "uicontextmenu"),[])

  Location  |  Observed  |  Expected  |  Reason
     .          O(1x1)       E(0x0)      Dimensions don't match

Tatsuro

Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate

Juan Pablo Carbajal-2
Hi all,

Tested on Ubuntu 18.10, nouveau drivers
Summary:

  PASS                            15518
  FAIL                                0
  XFAIL (reported bug)               23
  SKIP (missing feature)             37
  SKIP (run-time condition)          12

On Wed, Jan 30, 2019 at 12:15 AM Tatsuro MATSUOKA <[hidden email]> wrote:

>
>
>
> I have tested octave-5.0.90 on my windows 10.
> Unlike others I met one FAIL
>
> libinterp\corefcn\graphics.cc-tst .............................. PASS   52/53
>                                                                    FAIL    1
>
> Summary:
>
>   PASS                            15499
>   FAIL                                1
>   XFAIL (reported bug)               25
>   SKIP (missing feature)             52
>   SKIP (run-time condition)           9
>
> >>>>> processing H:\Octave\OCTAVE~1.90-\mingw64\share\octave\5.0.90\etc\tests\libinterp\corefcn\graphics.cc-tst
> ***** test
>  hf = figure ("visible", "off");
>  hax = axes ("parent", hf);
>  unwind_protect
>    hctx1 = uicontextmenu ("parent", hf);
>    hctx2 = uicontextmenu ("parent", hf);
>    set (hf, "uicontextmenu", hctx2);
>    set (hax, "uicontextmenu", hctx2);
>    assert (get (hf, "uicontextmenu"), hctx2);
>    assert (get (hax, "uicontextmenu"), hctx2);
>    assert (get (hf, "children"), [hctx2; hctx1; hax]);
>    delete (hctx2);
>    assert (get (hf, "uicontextmenu"), []);
>    assert (get (hax, "uicontextmenu"), []);
>    assert (get (hf, "children"), [hctx1; hax]);
>    set (hf, "uicontextmenu", hctx1);
>    assert (get (hf, "uicontextmenu"), hctx1);
>    set (hf, "uicontextmenu", []);
>    assert (get (hf, "uicontextmenu"), []);
>    assert (get (hf, "children"), [hctx1; hax]);
>  unwind_protect_cleanup
>    close (hf);
>  end_unwind_protect;
> !!!!! test failed
> ASSERT errors for:  assert (get (hf, "uicontextmenu"),[])
>
>   Location  |  Observed  |  Expected  |  Reason
>      .          O(1x1)       E(0x0)      Dimensions don't match
>
> Tatsuro
>

Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate

nrjank
In reply to this post by tmacchant
 ASSERT errors for:  assert (get (hf, "uicontextmenu"),[])

  Location  |  Observed  |  Expected  |  Reason
     .          O(1x1)       E(0x0)      Dimensions don't match


This appears to be the same problem  that JohnD had a little while ago.  Adding a short pause [ pause(0.1); ] before that test appears to allow the delete(hctx2) to complete. 


I don't know if this is just a test bug, dependent on variable system speed, or if there's really something slowing down the graphics process that could be fixed.


Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate

Anadi Kashyap
In reply to this post by apjanke-floss
On Mon, Jan 28, 2019 at 11:21 AM Andrew Janke <[hidden email]> wrote:


On 1/28/19 12:32 AM, Anadi Kashyap wrote:
>
>
> On Mon, Jan 28, 2019 at 10:56 AM Andrew Janke <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     $ brew tap octave-app/octave-app-bases
>                                                        master
>     ==> Tapping octave-app/octave-app-bases
>     Cloning into
>     '/usr/local/Homebrew/Library/Taps/octave-app/homebrew-octave-app-bases'...
>     remote: Enumerating objects: 180, done.
>     remote: Counting objects: 100% (180/180), done.
>     remote: Compressing objects: 100% (106/106), done.
>     [...]
>
>     Cheers,
>     Andrew
>
> Welp, guess it's just me then.
>
> Wow I checked again and I was typing octave-app-base and not bases :/
> Thanks for the info. Also, had to uninstall suite-sparse to do the brew
> install part. Is it normal?

That is not normal. suite-sparse is one of the dependencies of
octave-octave-app, so it should be fine, and in fact required. Perhaps
you had a customized variant of suite-sparse installed? Or maybe you had
installed the OpenBLAS version of suite-sparse from the dpo/openblas tap
at https://github.com/dpo/homebrew-openblas? Because the dpo/openblas
formulae use the same names as core formulae, that could cause conflicts.

Cheers,
Andrew

Yes indeed, I had installed the openblas version installed because homebrew didn't have sundials27 which was needed to resolve some error I was getting during configure.. I guess that installing from openblas might have caused that.  

Anyways, I got the same results as you did on my macOS Mojave 10.14:

Summary:

  PASS                            15462
  FAIL                                4
  XFAIL (reported bug)               43
  SKIP (missing feature)             48
  SKIP (run-time condition)          29

Reply | Threaded
Open this post in threaded view
|

Re: RC1 Candidate

apjanke-floss


On 2/1/19 5:29 AM, Anadi Kashyap wrote:

> On Mon, Jan 28, 2019 at 11:21 AM Andrew Janke <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>
>     On 1/28/19 12:32 AM, Anadi Kashyap wrote:
>     >
>     >
>     > On Mon, Jan 28, 2019 at 10:56 AM Andrew Janke <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >
>     >     $ brew tap octave-app/octave-app-bases
>     >                                                        master
>     >     ==> Tapping octave-app/octave-app-bases
>     >     Cloning into
>     >   
>      '/usr/local/Homebrew/Library/Taps/octave-app/homebrew-octave-app-bases'...
>     >     remote: Enumerating objects: 180, done.
>     >     remote: Counting objects: 100% (180/180), done.
>     >     remote: Compressing objects: 100% (106/106), done.
>     >     [...]
>     >
>     >     Cheers,
>     >     Andrew
>     >
>     > Welp, guess it's just me then.
>     >
>     > Wow I checked again and I was typing octave-app-base and not bases :/
>     > Thanks for the info. Also, had to uninstall suite-sparse to do the
>     brew
>     > install part. Is it normal?
>
>     That is not normal. suite-sparse is one of the dependencies of
>     octave-octave-app, so it should be fine, and in fact required. Perhaps
>     you had a customized variant of suite-sparse installed? Or maybe you
>     had
>     installed the OpenBLAS version of suite-sparse from the dpo/openblas
>     tap
>     at https://github.com/dpo/homebrew-openblas? Because the dpo/openblas
>     formulae use the same names as core formulae, that could cause
>     conflicts.
>
>     Cheers,
>     Andrew
>
>
> Yes indeed, I had installed the openblas version installed because
> homebrew didn't have sundials27 which was needed to resolve some error I
> was getting during configure.. I guess that installing from openblas
> might have caused that.  
>
> Anyways, I got the same results as you did on my macOS Mojave 10.14:
>
> Summary:
>
>   PASS                            15462
>   FAIL                                4
>   XFAIL (reported bug)               43
>   SKIP (missing feature)             48
>   SKIP (run-time condition)          29
>

That'll do it. For now, I'd recommend avoiding the dpo/openblas tap and
just using the stuff in octave-app/octave-app-bases. octave-app-bases
also provides SUNDIALS 2.7, but its formulae are defined such that they
avoid conflicting with the stuff from core Homebrew.

If you really want to do OpenBLAS based builds, use
octave-app/octave-app-blas. It's my fork of dpo/openblas, but with stuff
renamed and rearranged to also avoid conflicts with core Homebrew.

Cheers,
Andrew

123