octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #36743] Octave:matlab-incompatible warning war


From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #36743] Octave:matlab-incompatible warning warns about Octave's own files
Date: Fri, 29 Jun 2012 15:43:17 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20100101 Firefox/10.0.5 Iceweasel/10.0.5

Follow-up Comment #2, bug #36743 (project octave):

We currently consider "system" files to be any that are installed anywhere
under the 


octave_config_info ('fcnfiledir')


directory.  By default, these files are skipped when checking timestamps.

So it seems to me that any file that would be considered a "system" file
should be excluded.  So if you install packages under this directory, they
would be excluded.  I don't think we should give special treatment to any
other files by default.  

But there should be ways to mark individual directories using a command that
could go in a PKG_ADD file.  That would allow individual Octave Forge packages
to declare that they are exempt from the Matlab incompatible warning.

Further, we might also consider some way for individual files to declare that
they are exempt.  Perhaps this could be done with a special comment similar to
#pragma in C or C++.

For the per-directory and per-file settings, we should probably think about
whether to only handle the matlab-incompatible warning, or make per-directory
and per-file settings more general so they can be applied to other things as
well.

Currently, we only check for matlab incompatible code in the lexer, so the
check should not be too expensive.  It should be as simple simple as checking
a flag in the  gripe_matlab_incompatible function.  But doing that will
require a little refactoring since we don't currently stash the "system file"
designation until after the file is parsed.

Also, if we expand matlab compatibility warnings to features that can only be
checked when a function is actually evaluated, then things will be more
complicated.  For example, suppose we want to have a function warn that it was
called in a matlab-incompatible way, but not if it is called from a function
that was marked as exempt from the warning.  Doing that requires looking at
the call stack.  It's possible, but will require a little more work.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36743>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]