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

 
 

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

Submitted by:  Tatsuro MATSUOKA <tmacchant>
Submitted on:  Mon 02 May 2016 03:13:26 AM UTC  
 
Category: InterpreterSeverity: 1 - Wish
Priority: 5 - NormalItem Group: Feature Request
Status: NoneAssigned to: None
Originator Name: Tatsuro MATSUOKAOpen/Closed: Open
Release: 4.0.2Operating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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>
Project Administrator
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>
Project 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>
Project Member
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>
Project 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>
Project Administrator
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>
Project Member
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>
Project Member
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.

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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 02 May 2016 01:24:30 PM UTCmtmillerSeverity3 - Normal=>1 - Wish

    Back to the top


    Powered by Savane 3.1-cleanup1