Re: overloaded function handles

Re: overloaded function handles

On Sat, Aug 1, 2009 at 5:42 AM, Robert T.
Short<octave <at> phaselockedsystems.com> wrote:
> Jaroslav Hajek wrote:
>
> On Thu, Jul 30, 2009 at 10:38 PM, Robert T.
> Short<octave <at> phaselockedsystems.com> wrote:
>
>
> Jaroslav Hajek wrote:
>
>
> I would stretch it even a little farther - I wouldn't like the feature
> to be removed or severely crippled (yes, performance also matters)
> just to workaround a US patent (and I still say workaround would be
> darn hard), because I want to use it. OTOH, I understand that this may
> be a really big problem for users from USA, so maybe we should really
> fork. This particular patent is fairly broad (intentionally, no
> doubt), but even if it can be worked around, future patents may not
> be.
>
> Finally, one more, slightly silly idea: What position would the
> Mathworks take on this matter? Maybe they wouldn't actually mind to
> make some sort of license disclaimer, giving Octave users from USA the
> license to use the feature? Or at least for non-commercial use
> (provided that it's not automatically guaranteed by the law)?
>
>
>
> Well, I am a U.S. citizen and have never felt unfortunate.  I also am OK
> with the idea of software patents, but this one seems to egregiously
> violate the obviousness criteria.  The U.S. patent system has gone kind
> of whacko in recent years to the point that the U.S. Congress and the
> USPTO are really rethinking the problem.  Unfortunately this patent has
> already been issued.
>
>
> I don't think we should cripple octave for some silly U.S. issue.  I am
> meeting with my patent attorney for some other matters in the next few
> weeks and we have put this on the agenda.  I will get some formal
> advice.  I will ask him about the whole problem including remedies and
> penalties, but for the short term here is what I think we should do.
>
> First, Jaroslav (and anybody else working this problem), just do the
> work so that this feature is available.
>
> Second, I don't think a simple compile-time flag is enough.  However
> suppose you leave some critical piece of the code out so the feature
> can't simply be compiled back in.  Then create a patch that is available
> only from a non-U.S. web site that enables the code.  For example, maybe
> just pull the parser section out or brain-damage the data structure or
> something that makes it nontrivial for a U.S. user to recreate the
> feature.  The patch will not be available in the U.S. and so I think we
> have demonstrated a willingness to abide by the U.S. patent laws.  If
> this isn't enough, I will get real advice on how to proceed.
>
> Of course, we can't prevent U.S. residents from downloading the patch,
> but I don't think that is really our problem.  This is not a new issue.
> The debian distribution used to (still does?) have a nonus portion of
> the archive mostly because of encryption and other export issues.
>
> I would really like to avoid a whole fork.  That may be the best way to
> manage it, but it seems like a small set of patches would suffice.
>
>
>
> To me, having a separate branch seems much simpler. It would be a real
> burden to always reapply a set of patches when rebuilding Octave (and
> I do that often). A patent-free branch could be hosted on Thomas
> Weber's site, for instance. The main point is, that while I like
> developing Octave, I'm really not willing to scan through the US (or
> any other, for that matter) patent database for possible
> infringements, so I can't guarantee that I won't create more
> infringements in the future.
>
>
>
>
> Hmmm.  I apply a set of local patches every time I pull from savannah (at
> least once each week).  Doesn't seem like much of a burden.

That may make the difference. I pull almost every day (except the
weekend). I also have multiple repos to build from on different
machines.

> Once in a while
> I have to fix the patches because of changes, but not often.  On the other
> hand, I was suggesting a short term fix.  At this point all we know is that
> we might infringe a patent.  It doesn't make much sense to create a real
> infrastructure to deal with a situation we don't really understand.
> Furthermore, I don't really care how we do it.  In fact as long as I am not
> personally liable I don't even care IF we do it.  It was just a suggestion.
>

A slight correction: The present situation is that we know that the
technique in question is almost surely covered by the patent.
According to wikipedia,
"a patent is a right to exclude others from making, using, selling,
offering for sale, exporting components to be assembled into an
infringing device outside the U.S., importing the product of a
patented process practiced outside the U.S., inducing others to
infringe, offering a product specially adapted for practice of the
patent"
This seems to imply that MathWorks can eventually prohibit usage of
Octave in the US, hosting the Octave archive in the US, or
contributing to Octave by US citizens.

>
> If anybody else has access to the appropriate attorney types it wouldn't
> hurt to get some other advice.  Also, even though I think it unlikely,
> would it hurt to ask the Mathworks folks about some sort of
> permissions?
>
>
> The problem is whom the permission would be given to, and how. I think
> it can't be made part of the license, because then it couldn't be
> limited to non-commercial usage (due to GPL).
>
>
>
> Well, it WAS your idea.  I think it is incredibly unlikely that the other
> guys would license octave to use anything.
>

Yeah, probably not (given that it would be technically difficult).
Still; they might make an unofficial disclaimer that they don't intend
to collect royalties from Octave users, or from non-commercial usage
only.

>
> I think we just see the negative effect of software patents in
> reality. If there was always an easy way out, they wouldn't be such an
> issue.
>
>
> This is simply a reality of the patent system.  Not just software patents.
>

True; however, I think it is apparent that here the patent was fairly
obvious to a person ordinarily skilled in the art (me) and the only
actually useful idea that I got from MathWorks is not even part of the
patent.

>
> So, I would like to warn any Octave users whom it may concern, that
> the development archive of Octave infringes certain US software
> patents (this might have been true even before, but now it's almost
> sure), with all possible implications for users of Octave in USA.
>
>
>
> Sounds good.
>
>
> Some notes.
>
> In the following, remember my "I ain't a patent attorney" disclaimer.  I am
> simply interpreting some readings and really don't KNOW anything.
>
> Here is a quote from a patent law text.
>
> "use of a patented device which has been legally purchased does not
> constitute infringement"
>
>
> Even though octave is not purchased, our users obtain the product legally
> and are probably not liable to infringement charges.  The point here is that
> the users of octave are very unlikely to have penalties applied for the use
> of the product.  I know that there have been attempts to impose fees on
> users of allegedly infringing products (c.f. Jaroslav's earlier message),
> but I feel this is simply a scare tactic.  I think it very unlikely that any
> U.S. court would approve any penalties for users that honestly obtained the
> software (opinion!).
>

Interesting.

>
> In contrast, I am reasonably sure that the octave developers are at risk for
> liability.  Since octave is not a product and is not owned by anybody, I
> don't have any idea how that would play out in court, but since JWE has
> publicly stated that he is in control of the software, I wonder if he could
> be the primary target. Also, anybody who contributes infringing code may be
> liable.  The question is who else could be liable?  Does that mean anybody
> who contributes is liable?  I have no idea.  It may be that anyone who
> redistributes octave could be liable.  Again, I don't know.
>

That sounds serious. But I wonder what "in control" means here and
where did JWE claim it.

>
> Now comes the question that really matters.  Assuming liability is decided,
> what is the penalty?  Referring to the same text (An Introduction to Patent
> Law, Mueller),
>
> -  There have been no profits, so the standard formulas for profits don't
> work.

Depends. I have profit from using Octave (or my employer has).

> -  It could be argued that octave has hurt the sales of MATLAB in which case
> someone may be liable for the lost revenue, but only for the revenue lost
> due to infringing items.  It seems that the octave developers could be
> liable for the portion of the lost sales.  Again, I am just guessing.
>

Oh god. Another ridiculous calculation of lost profits, no doubt.

> -  Legal costs.
>
> Except for legal costs, I don't see how any of this is a serious problem.
> Most likely octave would simply end up with an injunction to cease U.S.
> distribution.  That alone seems pretty serious to me!
>
>
> My real point in all of this is that we are trying to solve a problem
> without understanding the problem.  We need legal advice and we need a short
> term solution until we get it.
>
> I have offered to obtain such advice, but this will take a while - I can't
> fork out the cash required to get a good attorney to drop what he is doing
> and research the problem.
>

OK, that's nice of you.

>
> So, for now, I am going to withdraw from this discussion.  I have
> contributed all I can.  My opinions are just that, opinions, and anything
> else I say is just more speculation.  This problem requires leadership and
> legal advice and I am not in a position to contribute much of either.
>

OK, no problem. I just wanted to avoid some user from USA getting into
trouble due to my contribution. Now that I saw the claims, I have no
idea how to implement the feature without violating the patent.
(Mathematically speaking, even the previous implementation seems to be
covered by the claims).

Indeed, if nobody brought up the patent issue, I would be just happy I
improved Octave a bit further, as usual :)

cheers

--

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

Re: Classdef parser patch

John W. Eaton skrev:
> On 28-Apr-2009, Ryan Rusaw wrote:
>
> | Attached is a first stab at adding the basis for classdef files to the
> | lexer & the parser. With it the parser should be able to correctly
> | parse classdef files, although it currently doesn't do anything more
> | with them, as a number of items are still necessary to complete a
> | serviceable implementation:
> | 
> | 1. +package directory support.
> | 2. classdef support added to pt-* hierarchy.
> | 3. octave_value subclass for classdef objects.
> | 4. integrate with metaclass code, either the code Michael Goffioul
> | provided previously on the mailing list or something similar.
> | 5. add support for class events.
> | 6. add support for the automatic resolution of class property get & set methods.
> | 
> | Note: I used the Matlab documentation available at
> | http://www.mathworks.com/access/helpdesk/help/techdoc/index.html?/access/helpdesk/help/techdoc/matlab_oop/ug_intropage.html
> | as the basis for the changes, so it should be as close to complete as
> | the documentation allowed. If anyone finds something I've missed or
> | overlooked, please let me know.
>
> I checked in this changeset with some additional changes.
>
> | +maybe_property_get_set : // empty
> | +		  { 
> | +		    if (reading_classdef_file || lexer_flags.parsing_classdef) 
> | +			  {
> | +			    lexer_flags.maybe_classdef_get_set_method = true; 
> | +			  } 
> | +		  }
> | +		;
> | +
> |  function_beg	: push_fcn_symtab FCN stash_comment
> | -		  { $$ = $3; }
> | -		;
> | -
> | -function	: function_beg function1
> | +		  { $$ = $3; 
> | +		    if (reading_classdef_file || lexer_flags.parsing_classdef) 
> | +			  {
> | +		  	    lexer_flags.parsing_class_method = true;
> | +		  	  } 
> | +		  }
> | +		;
> | +		
> | +function : function_beg function1
> |  		  {
> |  		    $$ = finish_function (0, $2, $1);
> |  		    recover_from_parsing_function ();
> |  		  }
> | -		| function_beg return_list '=' function1
> | -		  {
> | -		    $$ = finish_function ($2, $4, $1);
> | +		| function_beg return_list maybe_property_get_set '=' function1
> | +		  {
> | +		    $$ = finish_function ($2, $5, $1);
> |  		    recover_from_parsing_function ();
> |  		  }
> |  		;
>
> This doesn't look quite right to me.  It appears that
> lexer_flags.parsing_class_method will be set to true after
> function_beg is recognized in a classdef file, but then you have
> maybe_property_get_set doing that again in the
>
>   function_beg return_list maybe_property_get_set '=' function1
>
> pattern.  Since that seems redundant, I eliminated the
> maybe_property_get_set non-terminal.  But it seems that you might have
> intended to avoid having lexer_flags.parsing_class_method set to true
> when the return_list is parsed.  I don't see how to do that without
> adding another shift/reduce conflict to the parser, but maybe you or
> someone else will have a clue about how it could be done, or maybe
> there is a better way to handle the get/set methods.
>
> David, I'm copying you on this mail because you recently modified the
> parser.  Not surprisingly, your changes caused some conflicts when
> applying Ryan's patch.  I fixed them up as best I could, but it would
> be helpful if both of you could look at the current versions of
> parse.y and lex.l and see if I screwed anything up with my merge.
>   

I've looked at the diff and it seems alright, as far as I can tell.

Regards,
David

> Ryan, also created a ChangeLog entry for you.  It would be helpful if
> you could include a ChangeLog entry with future changesets.
>
> Thanks,
>
> jwe
>   

Octave improvement proposal

Hello!

I want to help with improvement of the Octave.

I am author of the ALGLIB - open source project. ALGLIB is a numerical
analysis  library,  which  use  automatic  translation  from specially
designed  language to represent each algorithm in multiple programming
languages.   C++,   C#,  Pascal,  VBA  are  supported,  and  one  more
translation   mode  -  C++  with  multiple  precision  floating  point
arithmetics (GNU MP/MPFR).

I could help with integration of ALGLIB functionality in Octave.

In my opinion, you could use:
*  improved  hybrid  Levenberg-Marquardt algorithm (several times less
Hessian calculations due to quadratic model reuse)
*  interpolation  algorithms  -  barycentric  polynomial  (better than
standard  Neville  algorithm),  barycentric rational without poles and
with O(N) complexity
*  classification and regression algorithms - linear and logit models,
neural networks, neural network ensembles, random decision forests
* data analysis algorithms - LDA, PCA, k-means clustering
*  upcoming  release (algorithms are ready, I am working on docs) will
contain    improved    Gauss/Gauss-Kronrod    quadrature    generation
subroutines, FFT, fast convolution/correlation

These   are  the  most important algorithms. ALGLIB contains ever more
algorithms   (special   functions,   linear  algebra,  ...)  but  this
functionality is already implemented in Octave.

One  more  interesting  improvement is implementing multiple precision
calculations  in  Octave  using  GNU  MP  / MPFR libraries. Almost all
ALGLIB   algorithms   support   multiple   precision  arithmetics.  In
particular  -  linear  algebra algorithms; I've ported part of LAPACK,
small  part, but it is enough for daily work. As far as I know, MATLAB
does  not  support multiple precision arithmetics nor it have multiple
precision   linear  algebra/interpolation/integration/... Octave could
leave MATLAB far behind :)

I want to find someone interested in creating ALGLIB/Octave interface.
I   don't   know  Octave  internals, so I can't do it alone, but I can
help to someone who knows what to do.

Anyone interested?

With best regards,
Sergey Bochkanov.

Re: Growing x11 plot window (was: Flickering movies)

On Jul 31, 2009, at 7:37 AM, Ben Abbott wrote:

> On Jun 27, 2009, at 1:15 PM, Ben Abbott wrote:
>
>> On Jun 25, 2009, at 8:38 PM, Ben Abbott wrote:
>>
>>> On Jun 25, 2009, at 4:05 PM, Ben Abbott wrote:
>>>
>>>> On Thursday, June 25, 2009, at 10:45AM, "Marco Caliari" <marco.caliari <at> univr.it 
>>>> > wrote:
>>>>> Dear maintainers,
>>>>>
>>>>> I'm not sure I will describe a bug or just a different behavior,  
>>>>> so I'm
>>>>> writing to the maintainers' list.
>>>>> The execution of the following code in Octave 3.0.5
>>>>>
>>>>> x = linspace(-1,1);
>>>>> for i = 1:50
>>>>> plot(x,i*x.^2)
>>>>> axis([-1,1,0,50])
>>>>> pause(0.1)
>>>>> end
>>>>>
>>>>> produces a nice and fluent "movie". In particular, the axis box  
>>>>> seems
>>>>> fixed (it is fixed to my eyes), and only the curve inside moves.  
>>>>> With
>>>>> 3.2.0, I get a very flickering movie, with the axis box clearly  
>>>>> redrawn
>>>>> at each step. What is strange, moreover, is that if I change
>>>>>
>>>>> pause(0.1)
>>>>>
>>>>> with
>>>>>
>>>>> pause(0.01)
>>>>>
>>>>> the axis box changes its dimensions during the loop and so the  
>>>>> illusion of
>>>>> a movie disappears. I'm using gnuplot 4.2.5.
>>>>
>>>> Marco, I see the same effect.
>>>>
>>>> This "feature" has been present since Gnuplot allowed the x11  
>>>> window position and size to be set. Gnuplot allows the x11 window  
>>>> position and size to be set for gnuplot 4.2.5 and later.
>>>>
>>>> Unfortunately, I've been unable to demonstrate this behavior  
>>>> using gnuplot scripts (i.e. no Octave). Thus, I'm inclined to  
>>>> conclude the problem is with the plot stream octave send's to  
>>>> gnuplot, but have been unable to debug (isolate) the problem.
>>>>
>>>> Ben
>>>
>>> Marco / others
>>>
>>> I've taken a fresh look at this and have found a simple gnuplot  
>>> script that demonstrates (for me) the problem of the figure window  
>>> changing its dimension (nearly always resulting in vertical  
>>> growth). I've attached a copy of the script.
>>>
>>> The script is very simple
>>>
>>> set terminal x11
>>> set multiplot; plot sin(x); unset multiplot;
>>> set multiplot; plot sin(x); unset multiplot;
>>> set multiplot; plot sin(x); unset multiplot;
>>> set multiplot; plot sin(x); unset multiplot;
>>> set multiplot; plot sin(x); unset multiplot;
>>> set multiplot; plot sin(x); unset multiplot;
>>> ...
>>>
>>> My experience is that the x11 figure window's growth (or change in  
>>> dimension) is related to timing. A sufficiently fast computer may  
>>> not produce the problem.
>>>
>>> In any event, if anyone is running gnuplot 4.2.5 or above, I'd  
>>> appreciate it if they'd run this script and report back what  
>>> happens. Just type ...
>>>
>>> 	gnuplot --persist "debug.gp"
>>>
>>> ... or run gnuplot and type
>>>
>>> 	load "debug.gp"
>>>
>>> Thanks,
>>> Ben
>>
>> I've produced a initial changeset that attempt to work around the  
>> problem.
>>
>> When there are multiple axes or, at least one image objects,  
>> gnuplot's multiplot is set (meaning the growth problem remains).  
>> For other plots, multiplot is unset (meaning the growth problem is  
>> absent).
>>
>> I've tried gnuplot 4.2.3, 4.2.5, and the developers 4.3.0. I see no  
>> new problems., and only see a growing window for running 4.2.5 for  
>> 4.3.0, and when multiplot is set.
>>
>> The figure window growth problem remains obvious for me when  
>> running the colorbar demos.
>>
>> Ben
>>
>> <changeset.patch>
>
> Update.
>
> The problem with the growing window has been fixed in gnuplot's  
> sources.
>
> 	http://sourceforge.net/tracker/?func=detail&aid=2812476&group_id=2055&atid=102055
>
> I found a bug with the prior changeset when printing. The attached  
> resolves that.
>
> This change is a bit hacky. I am only able to avoid a flicking x11  
> window for a plot with a single axes object and no image objects.
>
> If there are no suggestions for a better implementation, I'll push  
> later today.
>
> Ben
>
> <changeset.patch>

I've pushed this change.

Ben

README.MSVC and README.cygwin (was Re: can this compile on vs2008 or not)

Hello

I this it is better to remove README.MSVC from source tar ball to avoid inquiry like the below.

http://www.nabble.com/can-this-compile-on-vs2008-or-not-td24783040.html

I also found that the changeset for README.cygwin by Macrco was omitted from current source tar ball.

http://www.nabble.com/patch-for-LD_PRELOAD-compatibility-on-cygwin-p23853377.html

Regards

Tatsuro 

--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> Sorry
> I have misled.
> --- Tatsuro MATSUOKA wrote:
> > > What a 2-fer! They dropped the can't do it anyway bombshell plus
> > > would not publicly reveal the location of the glob library.
> > > 
> > > Is this true or isn't it? It would be very nice if you would correct all
> > > references to this. The readme.msvc file is still there.
> 
> Certainly readme.msvc is still on the source package and the some of information is too old.
> I think it should be removed from source tar ball.
> 
> Regards
> 
> Tatsuro 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

README.MSVC and README.cygwin (was Re: can this compile on vs2008 or not)

Hello

I this it is better to remove README.MSVC from source tar ball to avoid inquiry like the below.

http://www.nabble.com/can-this-compile-on-vs2008-or-not-td24783040.html

I also found that the changeset for README.cygwin by Macrco was omitted from current source tar ball.

http://www.nabble.com/patch-for-LD_PRELOAD-compatibility-on-cygwin-p23853377.html

Regards

Tatsuro 

--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> Sorry
> I have misled.
> --- Tatsuro MATSUOKA wrote:
> > > What a 2-fer! They dropped the can't do it anyway bombshell plus
> > > would not publicly reveal the location of the glob library.
> > > 
> > > Is this true or isn't it? It would be very nice if you would correct all
> > > references to this. The readme.msvc file is still there.
> 
> Certainly readme.msvc is still on the source package and the some of information is too old.
> I think it should be removed from source tar ball.
> 
> Regards
> 
> Tatsuro 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: README.MSVC and README.cygwin (was Re: can this compile on vs2008 or not)

Hello

> I also found that the changeset for README.cygwin by Macrco was omitted from current source tar
> ball.
> 
> http://www.nabble.com/patch-for-LD_PRELOAD-compatibility-on-cygwin-p23853377.html
The changeset the above was applied to source tress on the development branch.  The changeset was not
applied to the source tree of 3.2.x.

However, the changeset to README.Cygwin is not up to date. 

Hello Macro. 

Can you prepare the changeset for README.Cygwin?

Regards

Tatsuro

--- Tatsuro MATSUOKA wrote:

> Hello
> 
> I this it is better to remove README.MSVC from source tar ball to avoid inquiry like the below.
> 
> http://www.nabble.com/can-this-compile-on-vs2008-or-not-td24783040.html
> 
> I also found that the changeset for README.cygwin by Macrco was omitted from current source tar
> ball.
> 
> http://www.nabble.com/patch-for-LD_PRELOAD-compatibility-on-cygwin-p23853377.html
> 
> Regards
> 
> Tatsuro 
> 
> --- Tatsuro MATSUOKA  wrote:
> 
> > Hello
> > 
> > Sorry
> > I have misled.
> > --- Tatsuro MATSUOKA wrote:
> > > > What a 2-fer! They dropped the can't do it anyway bombshell plus
> > > > would not publicly reveal the location of the glob library.
> > > > 
> > > > Is this true or isn't it? It would be very nice if you would correct all
> > > > references to this. The readme.msvc file is still there.
> > 
> > Certainly readme.msvc is still on the source package and the some of information is too old.
> > I think it should be removed from source tar ball.
> > 
> > Regards
> > 
> > Tatsuro 
> > 
> > --------------------------------------
> > Power up the Internet with Yahoo! Toolbar.
> > http://pr.mail.yahoo.co.jp/toolbar/
> > 
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Fwd: Re: [OctDev] Patch: Improved filename/symbol completing

On  5-Apr-2008, Tatsuro MATSUOKA wrote:

| Hello
| 
| octave-dev <at> lists.sourceforge.net is for octave-forge package list. 
| 
| I forwarded the below to octave maintainers list 
| 
| maintainers <at> octave.org
| 
| Regards
| 
| Tatsuro
| 
| --- Kristian Rumberg <kristianrumberg <at> gmail.com> wrote:
| This very simple patch makes sure that only files and no matlab
| symbols shows up when completing a "cd" och "ls" command. It also
| makes sure no files are displayed when completing the first command on
| the line. It's still not possible to complete a path-three such as "cd
| projects/octave/stacking", only files/folders in the current directory
| are showned in the completion list (just like before I touched the
| code).
| 
| The intelligence of "is_completing_dirfns" needs serious enhancement
| but at least it's a start.
| 
| Please leave feedback. Which kind of completion behavior do you prefer?

Sorry for the long delay.

This change doesn't limit completions if "cd" or "ls" is not at the
beginning of the line but is the initial word of a statement.  For
example,

  x = 1; cd <TAB>

lists symbols and filenames.

Maybe cd should also limit completions to directory names instead of
showing all files?

It does not limit completions to filenames for things like

  cd("<TAB>

It does limit the completions to filenames for things like

  cd foo; x = <TAB>

But I checked in a modified version of your patch anyway, since it
does seem to help in some cases and probably isn't generally much
worse than the current behavior.  The version I checked in is here:

  http://hg.savannah.gnu.org/hgweb/octave/rev/3cee58bf4acf

Thanks,

jwe

Re: Growing x11 plot window (was: Flickering movies)

On Sun, Aug 2, 2009 at 11:14 PM, Ben Abbott<bpabbott <at> mac.com> wrote:
> On Jul 31, 2009, at 7:37 AM, Ben Abbott wrote:
>
>> On Jun 27, 2009, at 1:15 PM, Ben Abbott wrote:
>>
>>> On Jun 25, 2009, at 8:38 PM, Ben Abbott wrote:
>>>
>>>> On Jun 25, 2009, at 4:05 PM, Ben Abbott wrote:
>>>>
>>>>> On Thursday, June 25, 2009, at 10:45AM, "Marco Caliari"
>>>>> <marco.caliari <at> univr.it> wrote:
>>>>>>
>>>>>> Dear maintainers,
>>>>>>
>>>>>> I'm not sure I will describe a bug or just a different behavior, so
>>>>>> I'm
>>>>>> writing to the maintainers' list.
>>>>>> The execution of the following code in Octave 3.0.5
>>>>>>
>>>>>> x = linspace(-1,1);
>>>>>> for i = 1:50
>>>>>> plot(x,i*x.^2)
>>>>>> axis([-1,1,0,50])
>>>>>> pause(0.1)
>>>>>> end
>>>>>>
>>>>>> produces a nice and fluent "movie". In particular, the axis box seems
>>>>>> fixed (it is fixed to my eyes), and only the curve inside moves. With
>>>>>> 3.2.0, I get a very flickering movie, with the axis box clearly
>>>>>> redrawn
>>>>>> at each step. What is strange, moreover, is that if I change
>>>>>>
>>>>>> pause(0.1)
>>>>>>
>>>>>> with
>>>>>>
>>>>>> pause(0.01)
>>>>>>
>>>>>> the axis box changes its dimensions during the loop and so the
>>>>>> illusion of
>>>>>> a movie disappears. I'm using gnuplot 4.2.5.
>>>>>
>>>>> Marco, I see the same effect.
>>>>>
>>>>> This "feature" has been present since Gnuplot allowed the x11 window
>>>>> position and size to be set. Gnuplot allows the x11 window position and size
>>>>> to be set for gnuplot 4.2.5 and later.
>>>>>
>>>>> Unfortunately, I've been unable to demonstrate this behavior using
>>>>> gnuplot scripts (i.e. no Octave). Thus, I'm inclined to conclude the problem
>>>>> is with the plot stream octave send's to gnuplot, but have been unable to
>>>>> debug (isolate) the problem.
>>>>>
>>>>> Ben
>>>>
>>>> Marco / others
>>>>
>>>> I've taken a fresh look at this and have found a simple gnuplot script
>>>> that demonstrates (for me) the problem of the figure window changing its
>>>> dimension (nearly always resulting in vertical growth). I've attached a copy
>>>> of the script.
>>>>
>>>> The script is very simple
>>>>
>>>> set terminal x11
>>>> set multiplot; plot sin(x); unset multiplot;
>>>> set multiplot; plot sin(x); unset multiplot;
>>>> set multiplot; plot sin(x); unset multiplot;
>>>> set multiplot; plot sin(x); unset multiplot;
>>>> set multiplot; plot sin(x); unset multiplot;
>>>> set multiplot; plot sin(x); unset multiplot;
>>>> ...
>>>>
>>>> My experience is that the x11 figure window's growth (or change in
>>>> dimension) is related to timing. A sufficiently fast computer may not
>>>> produce the problem.
>>>>
>>>> In any event, if anyone is running gnuplot 4.2.5 or above, I'd
>>>> appreciate it if they'd run this script and report back what happens. Just
>>>> type ...
>>>>
>>>>        gnuplot --persist "debug.gp"
>>>>
>>>> ... or run gnuplot and type
>>>>
>>>>        load "debug.gp"
>>>>
>>>> Thanks,
>>>> Ben
>>>
>>> I've produced a initial changeset that attempt to work around the
>>> problem.
>>>
>>> When there are multiple axes or, at least one image objects, gnuplot's
>>> multiplot is set (meaning the growth problem remains). For other plots,
>>> multiplot is unset (meaning the growth problem is absent).
>>>
>>> I've tried gnuplot 4.2.3, 4.2.5, and the developers 4.3.0. I see no new
>>> problems., and only see a growing window for running 4.2.5 for 4.3.0, and
>>> when multiplot is set.
>>>
>>> The figure window growth problem remains obvious for me when running the
>>> colorbar demos.
>>>
>>> Ben
>>>
>>> <changeset.patch>
>>
>> Update.
>>
>> The problem with the growing window has been fixed in gnuplot's sources.
>>
>>
>>  http://sourceforge.net/tracker/?func=detail&aid=2812476&group_id=2055&atid=102055
>>
>> I found a bug with the prior changeset when printing. The attached
>> resolves that.
>>
>> This change is a bit hacky. I am only able to avoid a flicking x11 window
>> for a plot with a single axes object and no image objects.
>>
>> If there are no suggestions for a better implementation, I'll push later
>> today.
>>
>> Ben
>>
>> <changeset.patch>
>
> I've pushed this change.
>
> Ben
>
>
>

I transplanted it to 3.2.x

--

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz