bugGNU Octave - Bugs: bug #47820, Uncomprehesive behaviors for...

 
 

bug #47820: Uncomprehesive behaviors for functions that are not recognized in configure

Submitter:  Tatsuro MATSUOKA <tmacchant>
Submitted:  Mon 02 May 2016 03:13:26 AM UTC
   
 
Category:  Interpreter Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  Wont Fix Assigned to:  None
Originator Name:  Tatsuro MATSUOKA Open/Closed:  * Closed
Release:  * 4.0.2 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 04 Mar 2019 05:03:35 AM UTC, comment #14: 

OK. List in Wiki is a good idea. As an originator, I do not have more opinions on this matter. Anyway thank for discussion.

Tatsuro MATSUOKA <tmacchant>
Mon 04 Mar 2019 12:05:21 AM UTC, comment #13: 

I don't think there is anything actionable in this bug report. The Octave documentation and the help system are not going to be dynamic and describe specific behavior on the system that the user happens to be running.

If someone wants to compile a list of system-dependent functions that don't work on Windows systems along with their return values and possible workarounds on the wiki, that would be a good first step for a contributor to try to capture this information. If that turns into a useful resource, we could consider adding it to the user manual as an appendix at some point.

Please comment if there is still something to discuss here.

Mike Miller <mtmiller>
Group Member
Tue 03 May 2016 04:34:41 PM UTC, comment #12: 

I think we might consider making it more obvious that these functions will not work on systems such as Windows.

But I agree that we should not make the documentation dynamic and dependent on the system capabilities.

Mike Miller <mtmiller>
Group Member
Tue 03 May 2016 05:04:00 AM UTC, comment #11: 

I aware that pipe is not recognized by configure (judging from config.h) but implemented using gnulib.

Thus it is dangerous to use information config.h information.
At the moment I will check the functions that Mike shown in comment #6 and the results are described in the octave for windows wiki.

I personally prefer help behavior in gnuplot rather than that in octave.

Tatsuro MATSUOKA <tmacchant>
Tue 03 May 2016 03:45:47 AM UTC, comment #10: 

Sorry, but I really don't think such additional complexity is needed.

John W. Eaton <jwe>
Group administrator
Tue 03 May 2016 03:32:08 AM UTC, comment #9: 

JWE, I see your point about not wanting the user to need to have the tools to build the documentation.

However, there are other mechanisms that may allow the response of "help" to be customised, without changing the texi/dvi/ps/pdf (or even df) files.

For example, there could be an extra argument to DEFUN consisting of a (configuration dependent) string to prepend or append to the docstring before displaying help.  A more ambitious option would be to make that extra argument a sed script, so it can do things like completely replacing the help text -- without changing the full pdf or any of the tool-dependent files.

Such an extension is clearly a large undertaking, but I don't think it should be dismissed out of hand.

Other than the need for users to have tools and the possibility of multiple incompatible manuals, are there other reasons not to have the (online) documentation independent of the configuration?

Lachlan Andrew <lachlan>
Tue 03 May 2016 03:01:46 AM UTC, comment #8: 

Please do NOT make the documentation conditional on the configuration options.

When building from a tarball release, we want to avoid building the documentation unless there is an actual change to the source files.  Having the contents of the documentation depend on configuration options will likely break that.

Instead, you can make a note that a function (or group of functions) is (are) may not be available if the underlying OS does not support the functionality.

John W. Eaton <jwe>
Group administrator
Tue 03 May 2016 02:25:24 AM UTC, comment #7: 

Thank you for the search functions and comprehensive explanation.
I understand that the current implementation function itself is reasonable.

I hope something will be done for users who are not familiar to POSIX style programming. As I wrote in the comment #4, unsupported functions do not have their help like gnuplot or notification like "this function is not supported on this system" appears in the help.

Tatsuro MATSUOKA <tmacchant>
Mon 02 May 2016 01:24:30 PM UTC, comment #6: 

I did a quick search for the string "not supported on this system". It basically boils down to the user-callable functions defined in libinterp/corefcn/{getgrent,getpwent,syscalls}.cc. I'm assuming that string is used everywhere for functions that may not exist on the host operating system, it may not be.

These functions return a "msg" output argument instead of maybe raising an error condition, which is possibly what Tatsuro would prefer.

  • dup2
  • endgrent
  • endpwent
  • exec
  • fcntl
  • fork
  • getgrent
  • getgrgid
  • getgrnam
  • getpgrp
  • getpwent
  • getpwnam
  • getpwuid
  • kill
  • pipe
  • setgrent
  • setpwent
  • uname
  • waitpid


Tatsuro, these are all basically wrappers around POSIX functions, and it's expected that users calling them are familiar with the way that these POSIX functions work, including what integer return values are meaningful and what are not.

The POSIX equivalent is usually to check for a -1 return value, and then decode the value of the errno variable into a standard error message. In Octave this is turned into a second (or Nth) output argument that contains the error message.

Some functions do already raise an Octave error condition, for example popen2, but most return the error message as an output argument and return an invalid value.

I can see the case for consistently raising Octave errors if the function returns an error string, or for keeping things the way they are now and requiring the user to check the return value.

Mike Miller <mtmiller>
Group Member
Mon 02 May 2016 06:52:40 AM UTC, comment #5: 

The most important thing is unsupported functions returns -1 in the almost the case as the first return value.
I hope return value of unsupported function returns non-sense value
as the first arguments.

Tatsuro MATSUOKA <tmacchant>
Mon 02 May 2016 06:40:41 AM UTC, comment #4: 

I re-consider what you say.

My intention is to change of only the "help" behaviors.

Other documentations (pdf, html, info) need not to be changed
to due to the environments differences because it is better to  describe full features of the current octave.
But this is a my personal opinion.

My opinion comes from behaviors of gnuplot.

On the gnuplot, unsupported does not appears in help
but all features are documented in html and pdf.

Perhaps different opinions exist for documentation.

What I want to change the return value of unsupported functions.
But this is not related to your inquiry,
so that I will write as another comment.
 

Tatsuro MATSUOKA <tmacchant>
Mon 02 May 2016 05:51:40 AM UTC, comment #3: 

I'm still unsure which option you mean.  In particular, I'm not sure what you mean by "representation" of a function.

From the last sentence, it sounds like you would like a change in the documentation, saying clearly that this function was disabled during configuration.  Is that right?


Lachlan Andrew <lachlan>
Mon 02 May 2016 05:39:36 AM UTC, comment #2: 


> Is the problem here that the documentation doesn't match the actual functionality, or is it just that you want the missing functionality to be implemented?


No it is not.

This is an issue representation of unsupported functions which comes from environments (intentional nor un-intentional).

Current representation causes misleading like me.
Perhaps other people feel in the same matter.

Therefore I request the improvements way of representation for unsupported functions that were marked as "undefined" during configure.

Tatsuro MATSUOKA <tmacchant>
Mon 02 May 2016 03:57:06 AM UTC, comment #1: 

Is the problem here that the documentation doesn't match the actual functionality, or is it just that you want the missing functionality to be implemented?

If it is the documentation issue, that is related to bug #36524.  At the moment, the documentation can only be a single string.  Having configuration-dependent strings requires the entire string to be repeated (with appropriate modifications) in #ifdef statements.

I would like there to be a system that allows #ifdefs within the string -- for example, allowing the fork documentation to mention that it is not available on the current system, and possibly saying what configuration changes are required to enable it.

Of course, that doesn't get any closer to actually implementing it...

Lachlan Andrew <lachlan>
Mon 02 May 2016 03:13:26 AM UTC, original submission:  

This is discussed in the thread:

http://octave.1599824.n4.nabble.com/fork-for-microsoft-windows-native-but-not-Cygwin-td4676646.html

However, I noticed that the feature are neither specific to fork nor specific to the platform.

The some functions implemented in syscalls.cc and oct-syscalls.cc apparently work but not in reality it failed to recognized in configure process.

Current example fork on windows.


>> fork()
ans = -1



>> help fork
'fork' is a built-in function from the file libinterp/corefcn/syscalls.cc

 -- Built-in Function: [PID, MSG] = fork ()
     Create a copy of the current process.

     Fork can return one of the following values:

     > 0
          You are in the parent process.  The value returned from 'fork'
          is the process id of the child process.  You should probably
          arrange to wait for any child processes to exit.

     0
          You are in the child process.  You can call 'exec' to start
          another process.  If that fails, you should probably call
          'exit'.

     < 0
          The call to 'fork' failed for some reason.  You must take
          evasive action.  A system dependent error message will be
          waiting in MSG.

Additional help for built-in functions and operators is
available in the online version of the manual.  Use the command
'doc <topic>' to search the manual index.

Help and information about Octave is also available on the WWW
at http://www.octave.org and via the help@octave.org
mailing list.
octave.org and via the help@octave.org
mailing list.



>> [a,b]=fork()
a = -1
b = fork: not supported on this system


Of course,

>> fork()  returns -1 indicates for fork() does not work

correctly and suggest to execute fork() as two variables return
function.  

The "help fork" does not refer to "not supported".

This is a feature request rather than a bug report.
But I hope that octave behaviors are kind enough for those who are not octave experts.

Tatsuro MATSUOKA <tmacchant>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by lachlan (Posted a comment)
  • -email is unavailable- added by tmacchant (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-04 mtmiller StatusNone Wont Fix
        Open/ClosedOpen Closed
    2019-03-03 mtmiller Carbon-CopyRemoved 80942 -
    2016-05-02 mtmiller Severity3 - Normal 1 - Wish

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code