Mon 27 Jun 2016 04:49:21 AM UTC, comment #12:
@Tatsuro: The bug about popen2 requiring a delay is #48149.
|
Sun 26 Jun 2016 10:45:54 PM UTC, comment #11:
Avinoam
The patch mentioned in comment #8 enables build.
Thanks!
Seeing the patch popen2 for windows seemed to be renamed as win_popen2 and there wad an issue and Rik stated that the issue woule be filed as a new bug report.
What is number of the bug of that bug?
|
Sat 25 Jun 2016 07:32:39 AM UTC, comment #10:
What about the patch mentioned in comment #8?
|
Sat 25 Jun 2016 05:33:37 AM UTC, comment #9:
Patch on comment # 7 is also required for windows native build for default branch. Is there any reason that the patch on comment #7 is attached to the source tree?
|
Mon 06 Jun 2016 03:54:41 PM UTC, comment #8:
I pushed a slightly different patch here (http://hg.savannah.gnu.org/hgweb/octave/rev/590c39b94618) which avoids the issue by renaming so there are not duplicate functions in the same namespace.
I tested it and MXE Octave builds, the popen2 call however fails for me unless I put in a slight 50 millisecond delay after calling the function. I will file a new bug report about that.
|
Sun 05 Jun 2016 10:29:21 PM UTC, comment #7:
patch attached that works for me
(file #37400)
|
Tue 24 May 2016 04:52:57 PM UTC, comment #6:
@Mike: That was my thought as well. I think the 'auto' keyword will work again once we have unambiguous/non-duplicative naming of the functions.
|
Tue 24 May 2016 04:38:08 PM UTC, comment #5:
It looks like what happened here is simple naming conflict with the new namespace approach jwe is working on.
The old names were octave_popen2 (an internal-use only function defined on non-Cygwin Windows systems) and octave_syscalls::popen2, the public exposed API function for calling popen2 in Octave (either from libinterp or from external code).
The new names are both octave::sys::popen2, so we just need a new name for one of them to avoid the name conflict. I think the one in lo-sysdep should be renamed since it is only there for the other to use internally on Windows systems.
|
Tue 24 May 2016 04:29:55 PM UTC, comment #4:
I'm adding jwe to the CC list so he can possibly explain John's observation about duplication of popen2 in lo-sysdep and oct-syscalls.
If I understand the naming scheme, sysdep may stand for "System Dependent", while syscalls stands for "System Calls" that are presumably available just about everywhere.
From a naming perspective, things have gotten more muddled since we started using gnulib which removes the system dependency for lots of functions.
In this case, it appears that popen2 (which is always in the octave::sys namespace despite being defined and implemented over multiple .h and .cc files) should be consolidated so that the function appears either in oct-syscalls.[h|cc] or in lo-sysdep.[h|cc].
|
Tue 24 May 2016 04:50:47 AM UTC, comment #3:
This patch works for me, and Octave passes all test.
Thanks!
|
Sun 22 May 2016 12:04:32 PM UTC, comment #2:
I got it to compile for me now (see attached), but havent tried running it yet.
1. defined a type for the popen2 function to fix the initial compile error.
2. #ifdef'd the original popen2 function in oct-syscalls.cc so that it isnt available in windows to fix the next issue that occurs.
Shouldnt the existing unix popen2 call be moved to lo-sysdep.cpp rather than have to ifdef both liboctave/system/lo-sysdep.cc and
liboctave/system/oct-syscalls.cc ?
(file #37226)
|
Sat 21 May 2016 05:16:54 PM UTC, comment #1:
Updating summary and marking as confirmed by the existing mailing list discussion
http://lists.gnu.org/archive/html/octave-maintainers/2016-05/msg00285.html
|
Sat 21 May 2016 11:31:09 AM UTC, original submission:
Using changeset http://hg.savannah.gnu.org/hgweb/octave/rev/31b4b614ed55,
the popen2 problem wasn't solve yet:
|