Re: DEFVARs again (was Re: MinGW version binary gobbledygook error messages?)

[David Bateman]

John W. Eaton wrote:

> On 28-Feb-2006, David Bateman wrote:
>
> | 2) The DEFVAR of the gnuplot variables doesn't happen till the first 
> use
> | of gnuplot. This causes particular problems with things that use
> | automatic_replot. Try "spy(sprandn(10,10,0.2))" for example at the 
> first
> | prompt. See the thread on DEFVAR recently for more details of the
> | potentially intrusive fix.
>
> Yes, I'm still waiting on some comments about that.  I would really
> like to fix this problem, but I'm uncertain about whether consistency
> of implementation is worth the trouble it could cause.
Frankly, I'd say don't think it for 2.9.5, but rather add a call to the 
gnuplot_init code. This will hide the problem for 2.9.5. Get that 
release out of the way and then we can fix this and add the package 
manager. The fact is that apart from this bug, I consider 2.9.5 to be 
pretty stable, and the DEFVAR changes will break things...

> Built-in constants are no problem.  It doesn't matter whether they are
> defined internally as variables or functions since they are never
> supposed to appear on the LHS of an assignment.
>
> Built-in variables are affected, since it has been well-documented
> that the way to change something like LOADPATH is to write
>
>   LOADPATH = "new loadpath";
>
> We currently have about 75 built-in variables.  21 are warn_*
> variables that can be removed and replaced with the new warning tag
> mechanishm.  Of the rest, I think the biggest problem will be with
> LOADPATH, gnuplot_binary, automatic_replot, page_screen_output,
> page_output_immediately, etc.  These are symbols that we have told
> people to use as variables that would now have to be used
> differently.
>
> But the change has the advantage of simplifying the internals of
> Octave a bit (no more lookup up built-in variables separately from
> functions, for example).
>
> This is a big change.  I'd like to see some discussion before deciding
> what to do about it.  If I don't see any discussion, I might think
> that everyone enthusiatically supports making the change.
>
> jwe
I think it has to be done as there is no other way that makes sense. I 
think the pain might be slightly alleviated if addpath.m is migrated 
from octave-forge to octave, as I'd imagine that it is this variable 
that is the most likely to be used, and if a matlab compatible 
alternative can be offered immediately then we can convince people to 
migrate to the new syntax.

In a similar manner page_screen_output can already be replaced with the 
more() function. Perhaps we can add more("immediate") to replace the 
page_output_immediately variable as well. The other variable are mainly 
for gnuplot stuff and we should be hiding this behind an HG interface, 
so I see no issues in change the interface to that.

However, this change will firmly put the 2.9.x tree back into unstable, 
so if you want a testing version of 2.9.x it might be better to hold off 
with the above proposed stopgap, till you feel confident in marking a 
2.9.x release as a testing release..

Regards
David

--
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary