Quantcast

Building pytave on windows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Building pytave on windows

Abhinav Tripathi-2
Hi,
Mike has successfully removed all the boost dependencies from pytave and we are trying to build it on windows (again)...
.
Reading through our earlier conver
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Abhinav Tripathi-2
Extremely sorry for the incomplete mail.. I'll complete it here.

On Tue, May 9, 2017 at 3:24 PM, Abhinav Tripathi <[hidden email]> wrote:
Hi,
Mike has successfully removed all the boost dependencies from pytave and we are trying to build it on windows (again)...
.
Reading through our earlier conver

Reading through earlier conversations on the mailing list, I have reached upto a point.. And now I am getting the following error:
----------------------------------------------------------------------------------------------------------
bash-3.1$ make
make  all-am
make[1]: Entering directory `/d/repos/pytave'
/bin/sh ./libtool  --tag=CXX   --mode=compile g++ -std=gnu++11 -DHAVE_CONFIG_H -I.  -IC:\Octave\Octave-4.2.0\include\octave-4.2.0 -IC:\Octave\Octave-4.2.0\include\octave-4.2.0/octave -Ic:\Python36\include -IC:/Python36/include -IC:/Octave/Octave-4.2.0/include/octave-4.2.0 -IC:/Octave/Octave-4.2.0/include/octave-4.2.0/octave -IC:/Python36/Lib/site-packages/numpy/core/include -W -Wall -g -O2 -MT liboctpython_la-oct-py-error.lo -MD -MP -MF .deps/liboctpython_la-oct-py-error.Tpo -c -o liboctpython_la-oct-py-error.lo `test -f 'oct-py-error.cc' || echo './'`oct-py-error.cc
libtool: compile:  g++ -std=gnu++11 -DHAVE_CONFIG_H -I. -IC:OctaveOctave-4.2.0includeoctave-4.2.0 -IC:OctaveOctave-4.2.0includeoctave-4.2.0/octave -Ic:Python36include -IC:/Python36/include -IC:/Octave/Octave-4.2.0/include/octave-4.2.0 -IC:/Octave/Octave-4.2.0/include/octave-4.2.0/octave -IC:/Python36/Lib/site-packages/numpy/core/include -W -Wall -g -O2 -MT liboctpython_la-oct-py-error.lo -MD -MP -MF .deps/liboctpython_la-oct-py-error.Tpo -c oct-py-error.cc  -DDLL_EXPORT -DPIC -o .libs/liboctpython_la-oct-py-error.o
In file included from c:\octave\octave-4.2.0\lib\gcc\x86_64-w64-mingw32\4.9.4\include\c++\complex:44:0,
                 from oct-py-types.h:27,
                 from oct-py-error.cc:33:
c:\octave\octave-4.2.0\lib\gcc\x86_64-w64-mingw32\4.9.4\include\c++\cmath:1123:11: error: '::hypot' has not been declared
   using ::hypot;
           ^
make[1]: *** [liboctpython_la-oct-py-error.lo] Error 1
make[1]: Leaving directory `/d/repos/pytave'
make: *** [all] Error 2
----------------------------------------------------------------------------------------------------------

Earlier, to get through this tatsuro had commented out a few lines in the cmath include file itself. But, if we want to actually do a build then, I think, we should not temper with the inbuilt library files.
Does anyone have any idea on how to get through this error without editing the cmath library? Or what could be the potential cause of this?
.
.
If anyone is interested, I did the following to get this far:
----------------------------------------------------------------------------------------------------------
Install Python3.6 in C:\Python36
Install numpy
Install octave 4.2.0 in C:\Octave
Install msys64 in C:\msys64
Update msys packages. Install devel packages.
Clone pytave in D:\repos\pytave

in msys shell run 'autoreconf --install' to get configure executable for pytave
Running autoreconf in octave's bash shell always errored out, that's why I ran it in msys.

open octave-cli.exe and run 'system bash' and 'cd /d/repos/pytave'

export PATH=$PATH:/c/msys64/usr/bin:/c/Python36:/c/Python36/scripts

export CPPFLAGS='-IC:/Python36/include -IC:/Octave/Octave-4.2.0/include/octave-4.2.0 -IC:/Octave/Octave-4.2.0/include/octave-4.2.0/octave -IC:/Python36/Lib/site-packages/numpy/core/include'

export LDFLAGS='-Wl,--enable-auto-import -Wl,-export-all-symbols -LC:/Python36/libs -LC:/Octave/Octave-4.2.0/lib -LC:/Octave/Octave-4.2.0/lib/octave/4.2.0'

To get around python extra libs problem, do "export PYTHON_EXTRA_LIBS=-g" as suggested by Mike earlier

Then run './configure LIBS='-LC:/Python36/libs' which ends with:
Pytave is now configured for the following

  Octave header files:  C:\Octave\Octave-4.2.0\include\octave-4.2.0
  Octave libraries:     C:\Octave\Octave-4.2.0\lib\octave\4.2.0
  Python header files:  -Ic:\Python36\include
  Python library:       -Rc:\Python36\Lib\config -Lc:\Python36\Lib\config -lpython36
  Python executable:    /c/Python36//python

Now run 'make' which errs out.
----------------------------------------------------------------------------------------------------------
.
.
Regards,
Abhinav
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Mike Miller-4
On Tue, May 09, 2017 at 15:33:54 +0530, Abhinav Tripathi wrote:
> Reading through earlier conversations on the mailing list, I have reached
> upto a point.. And now I am getting the following error:
[…]
> In file included from
> c:\octave\octave-4.2.0\lib\gcc\x86_64-w64-mingw32\4.9.4\include\c++\complex:44:0,
>                  from oct-py-types.h:27,
>                  from oct-py-error.cc:33:
> c:\octave\octave-4.2.0\lib\gcc\x86_64-w64-mingw32\4.9.4\include\c++\cmath:1123:11:
> error: '::hypot' has not been declared
>    using ::hypot;
>            ^

I think this is a bug in the Python header files, which are probably not
extensively tested against building Python extensions under MinGW, even
less so using a GCC with C++11 support.

Python's pyconfig.h does the following on Windows systems

    #if defined(__GNUC__) && defined(_WIN32)
    …
    #define hypot _hypot
    …
    #endif /* GNUC */

Try adding a `#undef hypot` immediately after every `#include
<Python.h>`. You may have to add this to every .cc file.

If that fixes the error we can add something to work around this.

There are some others looking at fixing this in Python upstream

  https://bugs.python.org/issue11566
  https://github.com/python/cpython/pull/880

> To get around python extra libs problem, do "export PYTHON_EXTRA_LIBS=-g"
> as suggested by Mike earlier

I had forgotten about this issue, can you report it on the tracker?

--
mike

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Abhinav Tripathi-2
On Tue, May 9, 2017 at 8:21 PM, Mike Miller <[hidden email]> wrote:
On Tue, May 09, 2017 at 15:33:54 +0530, Abhinav Tripathi wrote:
> Reading through earlier conversations on the mailing list, I have reached
> upto a point.. And now I am getting the following error:
[…]
> In file included from
> c:\octave\octave-4.2.0\lib\gcc\x86_64-w64-mingw32\4.9.4\include\c++\complex:44:0,
>                  from oct-py-types.h:27,
>                  from oct-py-error.cc:33:
> c:\octave\octave-4.2.0\lib\gcc\x86_64-w64-mingw32\4.9.4\include\c++\cmath:1123:11:
> error: '::hypot' has not been declared
>    using ::hypot;
>            ^

I think this is a bug in the Python header files, which are probably not
extensively tested against building Python extensions under MinGW, even
less so using a GCC with C++11 support.

Python's pyconfig.h does the following on Windows systems

    #if defined(__GNUC__) && defined(_WIN32)
    …
    #define hypot _hypot
    …
    #endif /* GNUC */

Try adding a `#undef hypot` immediately after every `#include
<Python.h>`. You may have to add this to every .cc file.

If that fixes the error we can add something to work around this.

There are some others looking at fixing this in Python upstream

  https://bugs.python.org/issue11566
  https://github.com/python/cpython/pull/880

Undefining hypot didn't fix the problem. But, as suggested on the python's issue page, including cmath before Python.h did the trick.
The build completed successfully!!
.
BUT, when I open octave and cd to pyatve's directory, it says that pycall, pyexec, pyeval all these are undefined!!
Moreover, if instead of cding, if I just do addpath for pytave then I got a lot of warnings due to PKG_ADD.
I do not have proper experience with oct files, but I tried the following, out of which nothing worked:
.
-- I saw that the files are named *.oct.exe while in PKG_ADD the names are only *.oct 
     So, I renamed the files to remove .exe from file names. Now, I added pytave to path in octave and there was no warning but still all the functions are undefined.
-- I edited PKG_ADD to include .exe in the end of .oct but now I get syntax error in the .oct.exe file which can be seen here:
***********************************************************************
>> addpath 'D:/repos/pytave'
parse error near line 1 of file D:/repos/pytave\pycall.oct.exe

  syntax error

>>> MZ�
      ^

error: called from
    subsref at line 49 column 9
***********************************************************************

I am guessing second approach is right but the problem is related to how oct files are created on windows. Again, I have no knowledge of how oct files are created/called so any insight is welcome...
.
Also, I get similar syntax error when I try to rmpath pytave and am not able to remove pytave from path. I think atleast this is a bug in how oct files are handled.
.
.
Just a side note, I saw that octave 4.2.1 is available for windows so I used that this time, just to use the latest version of things.
 
> To get around python extra libs problem, do "export PYTHON_EXTRA_LIBS=-g"
> as suggested by Mike earlier

I had forgotten about this issue, can you report it on the tracker?

--
mike

Done.
.

Regards,
Abhinav 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Mike Miller-4
On Wed, May 10, 2017 at 10:34:11 +0530, Abhinav Tripathi wrote:
> Undefining hypot didn't fix the problem. But, as suggested on the python's
> issue page, including cmath before Python.h did the trick.
> *The build completed successfully*!!

That's a good start.

> BUT, when I open octave and cd to pyatve's directory, it says that pycall,
> pyexec, pyeval all these are undefined!!
> Moreover, if instead of cding, if I just do addpath for pytave then I got a
> lot of warnings due to PKG_ADD.
> I do not have proper experience with oct files, but I tried the following,
> out of which nothing worked:
> .
> -- I saw that the files are named *.oct.exe while in PKG_ADD the names are
> only *.oct
>      So, I renamed the files to remove .exe from file names. Now, I added
> pytave to path in octave and there was no warning but still all the
> functions are undefined.
> -- I edited PKG_ADD to include .exe in the end of .oct but now I get syntax
> error in the .oct.exe file which can be seen here:
> ***********************************************************************
> >> addpath 'D:/repos/pytave'
> >> py.int
> parse error near line 1 of file D:/repos/pytave\pycall.oct.exe
>
>   syntax error
>
> >>> MZ�
>       ^
>
> error: called from
>     subsref at line 49 column 9
> ***********************************************************************
>
> I am guessing second approach is right but the problem is related to how
> oct files are created on windows. Again, I have no knowledge of how oct
> files are created/called so any insight is welcome...

No, I think the "MZ" error is because of the file name. I think that
when Octave looks for a file on its load path to match a function or
script name, if the name ends in exactly ".oct", then it is loaded as a
shared object, otherwise it is expected to be an m-file. Octave is
trying to run the compiled oct files as if they were m-files, and all
Windows executable files start with the bytes "MZ".

I am pretty sure that I set up the makefile to build the oct files
correctly but you might try comparing the mkoctfile command line against
installing a well tested package from Octave Forge, or against building
the hello oct file example from the user manual.

I'm not sure why .exe is appended to the output files, that might be a
side effect of wrapping mkoctfile in libtool. It's possible that libtool
is doing other unexpected things to the command line also.

Can you get a basic oct file to work, in a different directory, or in
the same directory? Is the D: volume removable or network storage? If
you exit Octave and start it again with the oct files already built, any
difference?

--
mike

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Abhinav Tripathi-2
On Wed, May 10, 2017 at 11:10 AM, Mike Miller <[hidden email]> wrote:
On Wed, May 10, 2017 at 10:34:11 +0530, Abhinav Tripathi wrote:
> Undefining hypot didn't fix the problem. But, as suggested on the python's
> issue page, including cmath before Python.h did the trick.
> *The build completed successfully*!!

That's a good start.

> BUT, when I open octave and cd to pyatve's directory, it says that pycall,
> pyexec, pyeval all these are undefined!!
> Moreover, if instead of cding, if I just do addpath for pytave then I got a
> lot of warnings due to PKG_ADD.
> I do not have proper experience with oct files, but I tried the following,
> out of which nothing worked:
> .
> -- I saw that the files are named *.oct.exe while in PKG_ADD the names are
> only *.oct
>      So, I renamed the files to remove .exe from file names. Now, I added
> pytave to path in octave and there was no warning but still all the
> functions are undefined.
> -- I edited PKG_ADD to include .exe in the end of .oct but now I get syntax
> error in the .oct.exe file which can be seen here:
> ***********************************************************************
> >> addpath 'D:/repos/pytave'
> >> py.int
> parse error near line 1 of file D:/repos/pytave\pycall.oct.exe
>
>   syntax error
>
> >>> MZ�
>       ^
>
> error: called from
>     subsref at line 49 column 9
> ***********************************************************************
>
> I am guessing second approach is right but the problem is related to how
> oct files are created on windows. Again, I have no knowledge of how oct
> files are created/called so any insight is welcome...

No, I think the "MZ" error is because of the file name. I think that
when Octave looks for a file on its load path to match a function or
script name, if the name ends in exactly ".oct", then it is loaded as a
shared object, otherwise it is expected to be an m-file. Octave is
trying to run the compiled oct files as if they were m-files, and all
Windows executable files start with the bytes "MZ".

I am pretty sure that I set up the makefile to build the oct files
correctly but you might try comparing the mkoctfile command line against
installing a well tested package from Octave Forge, or against building
the hello oct file example from the user manual.

I'm not sure why .exe is appended to the output files, that might be a
side effect of wrapping mkoctfile in libtool. It's possible that libtool
is doing other unexpected things to the command line also.

Can you get a basic oct file to work, in a different directory, or in
the same directory? Is the D: volume removable or network storage? If
you exit Octave and start it again with the oct files already built, any
difference?

I created the basic helloworld oct file from octave docs. Interestingly, the file name ends with '.oct' but it too starts with exactly same header as pycall.oct.exe and others.. The header being (as seen in a text editor): 
-------------------------------------------------------------------------------------------------------
MZ     ÿÿ  ¸       @                                   €   º ´ Í!¸ LÍ!This program cannot be run in DOS mode.
-------------------------------------------------------------------------------------------------------
But helloworld.oct is properly recognised and run by octave. While if I rename pycall.oct.exe to pycall.oct nothing happens and pycall is still undefined.
Moreover, size of a simple helloworld.oct is around 7MB while that of pycall.oct.exe is around 36KB!!
Probably something wrong with the build then.. I'll look at exact commands that were issued and report back if I find something.
.
Abhinav
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Abhinav Tripathi-2

On Wed, May 10, 2017 at 5:04 PM, Abhinav Tripathi <[hidden email]> wrote:
On Wed, May 10, 2017 at 11:10 AM, Mike Miller <[hidden email]> wrote:
On Wed, May 10, 2017 at 10:34:11 +0530, Abhinav Tripathi wrote:
> Undefining hypot didn't fix the problem. But, as suggested on the python's
> issue page, including cmath before Python.h did the trick.
> *The build completed successfully*!!

That's a good start.

> BUT, when I open octave and cd to pyatve's directory, it says that pycall,
> pyexec, pyeval all these are undefined!!
> Moreover, if instead of cding, if I just do addpath for pytave then I got a
> lot of warnings due to PKG_ADD.
> I do not have proper experience with oct files, but I tried the following,
> out of which nothing worked:
> .
> -- I saw that the files are named *.oct.exe while in PKG_ADD the names are
> only *.oct
>      So, I renamed the files to remove .exe from file names. Now, I added
> pytave to path in octave and there was no warning but still all the
> functions are undefined.
> -- I edited PKG_ADD to include .exe in the end of .oct but now I get syntax
> error in the .oct.exe file which can be seen here:
> ***********************************************************************
> >> addpath 'D:/repos/pytave'
> >> py.int
> parse error near line 1 of file D:/repos/pytave\pycall.oct.exe
>
>   syntax error
>
> >>> MZ�
>       ^
>
> error: called from
>     subsref at line 49 column 9
> ***********************************************************************
>
> I am guessing second approach is right but the problem is related to how
> oct files are created on windows. Again, I have no knowledge of how oct
> files are created/called so any insight is welcome...

No, I think the "MZ" error is because of the file name. I think that
when Octave looks for a file on its load path to match a function or
script name, if the name ends in exactly ".oct", then it is loaded as a
shared object, otherwise it is expected to be an m-file. Octave is
trying to run the compiled oct files as if they were m-files, and all
Windows executable files start with the bytes "MZ".

I am pretty sure that I set up the makefile to build the oct files
correctly but you might try comparing the mkoctfile command line against
installing a well tested package from Octave Forge, or against building
the hello oct file example from the user manual.

I'm not sure why .exe is appended to the output files, that might be a
side effect of wrapping mkoctfile in libtool. It's possible that libtool
is doing other unexpected things to the command line also.

Can you get a basic oct file to work, in a different directory, or in
the same directory? Is the D: volume removable or network storage? If
you exit Octave and start it again with the oct files already built, any
difference?

I created the basic helloworld oct file from octave docs. Interestingly, the file name ends with '.oct' but it too starts with exactly same header as pycall.oct.exe and others.. The header being (as seen in a text editor): 
-------------------------------------------------------------------------------------------------------
MZ     ÿÿ  ¸       @                                   €   º ´ Í!¸ LÍ!This program cannot be run in DOS mode.
-------------------------------------------------------------------------------------------------------
But helloworld.oct is properly recognised and run by octave. While if I rename pycall.oct.exe to pycall.oct nothing happens and pycall is still undefined.
Moreover, size of a simple helloworld.oct is around 7MB while that of pycall.oct.exe is around 36KB!!
Probably something wrong with the build then.. I'll look at exact commands that were issued and report back if I find something.
.
Abhinav

Finally, size proved the main factor. I saw that *.oct files created in the '.libs' directory by the build are of higher size. So I did 'mv ./libs/*.oct   ./" and voila! Everything is fully working now!! So, the oct.exe files created in main directory are of no use. Only the *.oct files created in .libs directory are of any use which need to be moved after the build. Probably 1 line in the makefile.
I ran the BIST tests and everything passed.
.
Pytave can now be successfully built and installed in windows! :)
Probably time to move it into core, as it was already planned!
.
Regards,
Abhinav
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Mike Miller-4
On Wed, May 10, 2017 at 17:39:43 +0530, Abhinav Tripathi wrote:
> Finally, size proved the main factor. I saw that *.oct files created in the
> '.libs' directory by the build are of higher size. So I did 'mv
> ./libs/*.oct   ./" and voila! *Everything is fully working now*!! So, the
> oct.exe files created in main directory are of no use. Only the *.oct files
> created in .libs directory are of any use which need to be moved after the
> build. Probably 1 line in the makefile.

That's libtool redirecting the actual objects into the .libs directory.
I see Octave has its own workaround for building oct files with libtool
and copying the resulting file, we can look at something like that.

Adding the .libs directory with addpath should also work, right?

> I ran the BIST tests and everything passed.

Did you run the entire `make check` test suite? Have you tried running
OctSymPy's test suite with `sympref ipc native`?

This was built against the official Python binary from python.org,
right?

--
mike

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Abhinav Tripathi-2


On May 10, 2017 9:41 PM, "Mike Miller" <[hidden email]> wrote:
>
> That's libtool redirecting the actual objects into the .libs directory.
> I see Octave has its own workaround for building oct files with libtool
> and copying the resulting file, we can look at something like that.
>
> Adding the .libs directory with addpath should also work, right?

Yes.

>
> > I ran the BIST tests and everything passed.
>
> Did you run the entire `make check` test suite? Have you tried running
> OctSymPy's test suite with `sympref ipc native`?
>

No. I tried runtests in pytave directory which passes. If I do make check then octave crashes. Also, I found that in octave-cli pytave is properly loaded and i can call py* functions without any problems.
But, if I run octave in gui mode then after doing addpath,  if I call ANY py* function, octave crashes!! There must be something that cli is doing better than gui!?
Does octave do any core dump in any file while crashing that I can check?

> This was built against the official Python binary from python.org,
> right?

Yes.

>
> --
> mike
.
Regards,
Abhinav

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Mike Miller-4
On Thu, May 11, 2017 at 10:33:36 +0530, Abhinav Tripathi wrote:
> No. I tried runtests in pytave directory which passes.

That doesn't find all of the unit tests. You could call runtests on the
@py and @pyobject directories, that should catch all of them. There
should be 296 tests in all.

> If I do make check then octave crashes.

Is this running make from a shell from within Octave, or from an msys
shell outside of Octave? I don't know why this would crash. Does calling
`octave-cli --eval "runtests ."` also crash?

> Also, I found that in octave-cli pytave is properly
> loaded and i can call py* functions without any problems.
> But, if I run octave in gui mode then after doing addpath,  if I call ANY
> py* function, octave crashes!! There must be something that cli is doing
> better than gui!?

Fewer libraries loaded at the same time, single thread of execution,
these are both better when testing something new.

> Does octave do any core dump in any file while crashing that I can check?

I don't remember if the Octave installer comes with gdb, but if it does
you can run octave-cli with gdb and get a stack trace when a segfault or
other fatal signal happens.

--
mike

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Abhinav Tripathi-2

On May 11, 2017 11:07 AM, "Mike Miller" <[hidden email]> wrote:
>
> On Thu, May 11, 2017 at 10:33:36 +0530, Abhinav Tripathi wrote:
> > No. I tried runtests in pytave directory which passes.
>
> That doesn't find all of the unit tests. You could call runtests on the
> @py and @pyobject directories, that should catch all of them. There
> should be 296 tests in all.

Yes, i called it on pytave,  pytave/@py and pytave/@pyobject all the folders. And everything passed or XFailed.

>
> > If I do make check then octave crashes.
>
> Is this running make from a shell from within Octave, or from an msys
> shell outside of Octave? I don't know why this would crash. Does calling
> `octave-cli --eval "runtests ."` also crash?
>

I ran make check from a shell within octave-cli as the same shell is used for building.
Calling octave-cli --eval doesn't crash.
I tried:
octave-cli.exe --eval "addpath 'D:/repos/pytave';  runtests 'D:/repos/pytave'; runtests 'D:/repos/pytave/@py';
runtests 'D:/repos/pytave/@pyobject' "
.
All the tests pass.
Also,  D drive is a partition in my hard drive, it is not removable or networked.
.
> > Also, I found that in octave-cli pytave is properly
> > loaded and i can call py* functions without any problems.
> > But, if I run octave in gui mode then after doing addpath,  if I call ANY
> > py* function, octave crashes!! There must be something that cli is doing
> > better than gui!?
>
> Fewer libraries loaded at the same time, single thread of execution,
> these are both better when testing something new.
>
> > Does octave do any core dump in any file while crashing that I can check?
>
> I don't remember if the Octave installer comes with gdb, but if it does
> you can run octave-cli with gdb and get a stack trace when a segfault or
> other fatal signal happens.
>
> --
> mike

I will try to do some more tests and report if I find the cause of crash for gui and make check.
.
Regards,
Abhinav

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Mike Miller-4
On Thu, May 11, 2017 at 11:33:31 +0530, Abhinav Tripathi wrote:
> Yes, i called it on pytave,  pytave/@py and pytave/@pyobject all the
> folders. And everything passed or XFailed.

Great!

> I ran make check from a shell within octave-cli as the same shell is used
> for building.
> Calling octave-cli --eval doesn't crash.
> I tried:
> octave-cli.exe --eval "addpath 'D:/repos/pytave';  runtests
> 'D:/repos/pytave'; runtests 'D:/repos/pytave/@py';
> runtests 'D:/repos/pytave/@pyobject' "

Ok, can you try `make check OCTAVE=octave-cli`?

I wonder if calling `octave --no-gui-libs --no-window-system` is not
quite the same as calling `octave-cli` on Windows. Maybe it's trying to
run the octave-gui executable anyway.

> I will try to do some more tests and report if I find the cause of crash
> for gui and make check.

Great. Please keep reporting bugs on the issue tracker. I think we've
hit a few already that you could report, including the .libs directory
problem and the GUI crashing when any py function is called.

Have you tried OctSymPy with `sympref ipc native` yet?

--
mike

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Abhinav Tripathi

On May 11, 2017 10:18 PM, "Mike Miller" <[hidden email]> wrote:
>.....
>
> Ok, can you try `make check OCTAVE=octave-cli`?
>

That gave error as octave-cli does not recognize --no-gui-libs!

> I wonder if calling `octave --no-gui-libs --no-window-system` is not
> quite the same as calling `octave-cli` on Windows. Maybe it's trying to
> run the octave-gui executable anyway.
>

Doing "octave-cli --eval" or "octave --no-gui --eval"  or even  "octave --eval" passes!!
But calling "octave --no-gui-libs --no-window-system --eval" or doing it in the gui crashes!!!!
I tried it several times to confirm.

> > I will try to do some more tests and report if I find the cause of crash
> > for gui and make check.
>
> Great. Please keep reporting bugs on the issue tracker. I think we've
> hit a few already that you could report, including the .libs directory
> problem and the GUI crashing when any py function is called.

Should report it on octave bug tracker??

>
> Have you tried OctSymPy with `sympref ipc native` yet?
>

Well,  no. Because I couldn't find the branch to try. The pytave branch on octsympy is wayy old. I was going to open an issue on github repo.
I just tried with the old branch and it errored out... I will try to see the cause of the error.

> --
> mike
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Colin Macdonald-2
On 11/05/17 11:00 PM, Abhinav Tripathi wrote:
> Well,  no. Because I couldn't find the branch to try. The pytave branch
> on octsympy is wayy old. I was going to open an issue on github repo.
> I just tried with the old branch and it errored out... I will try to see
> the cause of the error.

Open an issue if the *master* branch of octsympy isn't working with
current pytave.

Colin

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Abhinav Tripathi-2


On May 12, 2017 1:40 PM, "Colin Macdonald" <[hidden email]> wrote:
>
> On 11/05/17 11:00 PM, Abhinav Tripathi wrote:
>>
>> Well,  no. Because I couldn't find the branch to try. The pytave branch on octsympy is wayy old. I was going to open an issue on github repo.
>> I just tried with the old branch and it errored out... I will try to see the cause of the error.
>
>
> Open an issue if the *master* branch of octsympy isn't working with current pytave.
>
> Colin
>

Oh sorry. I had lost track that pytave ipc is now called 'native'.
I ran the tests using native ipc on cli and everything passed except:
-- 1 Test in python_cmd due to change in text of error returned for multidim char arrays
-- 8 Tests in sympref which fail without pytave too. Probably something related to Windows.
.
Sorry for opening an issue on github for this, I will change the issue to reflect the failing tests in sympref as there already is an issue for the error message change.
.
Regards,
Abhinav

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Mike Miller-4
On Fri, May 12, 2017 at 14:42:07 +0530, Abhinav Tripathi wrote:
> Oh sorry. I had lost track that pytave ipc is now called 'native'.

I did mention that a couple times in this thread :)

> I ran the tests using native ipc on cli and everything passed except:
> -- 1 Test in python_cmd due to change in text of error returned for
> multidim char arrays

Same, https://github.com/cbm755/octsympy/issues/789

> -- 8 Tests in sympref which fail without pytave too. Probably something
> related to Windows.

Must be. Can you verify that sympref is still set to native after these
tests ran? Either by looking at the output or checking sympref after the
test suite completes. I tried to make sure that sympref would restore
the ipc that the user requested after its own tests mess with it,
regardless of pass or fail, but it's possible it gets reset to the
default somehow.

--
mike

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Mike Miller-4
In reply to this post by Abhinav Tripathi
On Fri, May 12, 2017 at 11:30:35 +0530, Abhinav Tripathi wrote:
> Doing "octave-cli --eval" or "octave --no-gui --eval"  or even  "octave
> --eval" passes!!
> But calling "octave --no-gui-libs --no-window-system --eval" or doing it in
> the gui crashes!!!!
> I tried it several times to confirm.

Ok, let's try this. Please edit the makefile and change "--no-gui-libs"
to just "--no-gui". Leave the rest of the options as they are. The
OCTAVE variable should be "octave". Does make check work with that small
change? I think on Windows it should be calling octave.bat, which
interprets the "--no-gui" option, but not "--no-gui-libs".

--
mike

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Mike Miller-4
In reply to this post by Abhinav Tripathi-2
On Fri, May 12, 2017 at 14:42:07 +0530, Abhinav Tripathi wrote:
> -- 8 Tests in sympref which fail without pytave too. Probably something
> related to Windows.

I don't see an open issue for this, is there one? Can you submit one?
Include the output of `test sympref verbose`.

--
mike

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Abhinav Tripathi-2
In reply to this post by Mike Miller-4


On Fri, May 12, 2017 at 8:42 PM, Mike Miller <[hidden email]> wrote:
On Fri, May 12, 2017 at 14:42:07 +0530, Abhinav Tripathi wrote:
> -- 8 Tests in sympref which fail without pytave too. Probably something
> related to Windows.

Must be. Can you verify that sympref is still set to native after these
tests ran? Either by looking at the output or checking sympref after the
test suite completes. I tried to make sure that sympref would restore
the ipc that the user requested after its own tests mess with it,
regardless of pass or fail, but it's possible it gets reset to the
default somehow.

It does get reset to system from whatever was set earlier. But, that's why I did test the other files (that come after sympref alphabetically) one by one using 'test' and they passed all the tests using pytave.

Ok, let's try this. Please edit the makefile and change "--no-gui-libs"
> to just "--no-gui". Leave the rest of the options as they are. The
> OCTAVE variable should be "octave". Does make check work with that small
> change? I think on Windows it should be calling octave.bat, which
> interprets the "--no-gui" option, but not "--no-gui-libs".

Well, on changing --no-gui-libs to --no-gui, make check finishes the tests and it shows 289 passed and some XFailed but then after that I also see the message that octave crashed!!
I donno how make is calling octave but when I am in bin directory of octave, there are only .exe files and calling 'octave --no-gui' works perfectly well there.
Probably closing of window is shown as crash by windows. Because I tried to call octave.bat in octave directory (not bin) using
        octave --no-gui --eval "addpath 'D:/repos/pytave'; runtests 'D:/repos/pytave' "
and everything works fine.
And yes, I saw octave.bat it only recognises 1 option, i.e., --no-gui.

On Fri, May 12, 2017 at 14:42:07 +0530, Abhinav Tripathi wrote:
> > -- 8 Tests in sympref which fail without pytave too. Probably something
> > related to Windows.

> I don't see an open issue for this, is there one? Can you submit one?
> Include the output of `test sympref verbose`.

Yes, sorry I couldnt get time to open that yesterday. I have done it now.
.
Regards,
Abhinav
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building pytave on windows

Mike Miller-4
On Sat, May 13, 2017 at 08:49:56 +0530, Abhinav Tripathi wrote:
> Well, on changing --no-gui-libs to --no-gui, make check finishes the tests
> and it shows 289 passed and some XFailed but then after that I also see the
> message that octave crashed!!

That's ok, that's a known bug in 4.2, it's fixed in the development
version. See https://savannah.gnu.org/bugs/?50707 for details.

I would be happy to change the way the test suite runs if I can get a
workaround for that bug to avoid crashing 4.2. But as it is it works in
the development version where I do all of my work.

--
mike

Loading...