From highegg at gmail.com  Sat Aug  1 01:15:26 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Sat, 1 Aug 2009 08:15:26 +0200
Subject: overloaded function handles
In-Reply-To: <4A73B9C2.8070105@phaselockedsystems.com>
References: <69d8d540907230549l2ca456a2n3cdb05531a2f1dfe@mail.gmail.com>
	<69d8d540907290241i85dcb4dy6214398f6ce103e7@mail.gmail.com>
	<a0daad600907291219j8c026e9x99ee306f58cd443b@mail.gmail.com>
	<4A70C98A.3020701@phaselockedsystems.com>
	<69d8d540907300001m604c9c87tb08b6a38567e86da@mail.gmail.com>
	<1248939735.3653.5.camel@sh-t400>
	<69d8d540907300112k4004ee75p55cc8d575477b28f@mail.gmail.com>
	<4A7204C3.1070403@phaselockedsystems.com>
	<69d8d540907302332j64f6499euca7d40b937b4977a@mail.gmail.com>
	<4A73B9C2.8070105@phaselockedsystems.com>
Message-ID: <69d8d540907312315x76a0e564u438fff0e39884690@mail.gmail.com>

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


From individ at acc.umu.se  Sat Aug  1 01:44:14 2009
From: individ at acc.umu.se (David Grundberg)
Date: Sat, 01 Aug 2009 08:44:14 +0200
Subject: Classdef parser patch
In-Reply-To: <19058.1298.295261.898747@segfault.lan>
References: <afb89e850904282043r1f987a3cy25fceccae61527f3@mail.gmail.com>
	<19058.1298.295261.898747@segfault.lan>
Message-ID: <4A73E43E.3040902@acc.umu.se>

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
>   


From shadeofgray at yandex.ru  Sat Aug  1 01:51:10 2009
From: shadeofgray at yandex.ru (=?windows-1251?B?0eXw4+XpIMHu9+rg7e7i?=)
Date: Sat, 1 Aug 2009 10:51:10 +0400
Subject: Octave improvement proposal
Message-ID: <991100945.20090801105110@yandex.ru>

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.



From bpabbott at mac.com  Sun Aug  2 16:14:03 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Sun, 02 Aug 2009 17:14:03 -0400
Subject: Growing x11 plot window (was: Flickering movies)
In-Reply-To: <A5CBCCD7-D0EC-480E-AC4E-F82EB7B3D313@mac.com>
References: <51622158972621923137937399617781517452-Webmail2@me.com>
	<4D72EF4A-16A0-48C2-993A-123CDF16EF9B@mac.com>
	<6450DCA6-C657-4795-98CF-9F0EB4FAC549@mac.com>
	<A5CBCCD7-D0EC-480E-AC4E-F82EB7B3D313@mac.com>
Message-ID: <525790C1-EE52-4B16-B539-A7A3F5988EBD@mac.com>

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



From tmacchant at yahoo.co.jp  Sun Aug  2 21:06:26 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Mon, 3 Aug 2009 11:06:26 +0900 (JST)
Subject: README.MSVC and README.cygwin (was Re: can this compile on vs2008 or
	not)
In-Reply-To: <20090803005852.83646.qmail@web3815.mail.bbt.yahoo.co.jp>
Message-ID: <20090803020626.76412.qmail@web3813.mail.bbt.yahoo.co.jp>

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/

From tmacchant at yahoo.co.jp  Sun Aug  2 21:28:33 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Mon, 3 Aug 2009 11:28:33 +0900 (JST)
Subject: README.MSVC and README.cygwin (was Re: can this compile on vs2008 or
	not)
In-Reply-To: <20090803005852.83646.qmail@web3815.mail.bbt.yahoo.co.jp>
Message-ID: <20090803022833.59005.qmail@web3811.mail.bbt.yahoo.co.jp>

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/

From tmacchant at yahoo.co.jp  Mon Aug  3 00:26:10 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Mon, 3 Aug 2009 14:26:10 +0900 (JST)
Subject: README.MSVC and README.cygwin (was Re: can this compile on vs2008
	or not)
In-Reply-To: <20090803020626.76412.qmail@web3813.mail.bbt.yahoo.co.jp>
Message-ID: <20090803052610.8400.qmail@web3803.mail.bbt.yahoo.co.jp>

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/

From jwe at octave.org  Tue Aug  4 15:37:18 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 4 Aug 2009 16:37:18 -0400
Subject: Fwd: Re: [OctDev] Patch: Improved filename/symbol completing
In-Reply-To: <20080405001345.9183.qmail@web3803.mail.bbt.yahoo.co.jp>
References: <54e55d600804041550k3a80293fsde42920451529850@mail.gmail.com>
	<20080405001345.9183.qmail@web3803.mail.bbt.yahoo.co.jp>
Message-ID: <19064.39934.142079.564694@segfault.lan>

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

From highegg at gmail.com  Thu Aug  6 00:30:45 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 6 Aug 2009 07:30:45 +0200
Subject: Growing x11 plot window (was: Flickering movies)
In-Reply-To: <525790C1-EE52-4B16-B539-A7A3F5988EBD@mac.com>
References: <51622158972621923137937399617781517452-Webmail2@me.com>
	<4D72EF4A-16A0-48C2-993A-123CDF16EF9B@mac.com>
	<6450DCA6-C657-4795-98CF-9F0EB4FAC549@mac.com>
	<A5CBCCD7-D0EC-480E-AC4E-F82EB7B3D313@mac.com>
	<525790C1-EE52-4B16-B539-A7A3F5988EBD@mac.com>
Message-ID: <69d8d540908052230k34b7f2c5n46777f744eefd004@mail.gmail.com>

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


From individ at acc.umu.se  Thu Aug  6 09:55:48 2009
From: individ at acc.umu.se (David Grundberg)
Date: Thu, 06 Aug 2009 16:55:48 +0200
Subject: [changeset] GraphicsMagick++ configuration
Message-ID: <4A7AEEF4.2070101@acc.umu.se>

Hi,

I've rearranged the GraphicsMagick++ configuration. I had some trouble 
since I'm running a custom GraphicsMagick installation. The Octave build 
system was running GraphicsMagick++-config during make. It was missing 
ldflags and using only the basename of the config executable (as opposed 
to a full path).

I've changed it so that GraphicsMagick++-config is only run in the 
configure script. Also introduced MAGICK_CONFIG as a precious variable.

Best regards,
David
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: magick.changeset
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090806/68442eaa/attachment.ksh 

From individ at acc.umu.se  Thu Aug  6 09:54:34 2009
From: individ at acc.umu.se (David Grundberg)
Date: Thu, 06 Aug 2009 16:54:34 +0200
Subject: linking changes for ftgl and qrupdate?
Message-ID: <4A7AEEAA.4050203@acc.umu.se>

Hello,

I'm having trouble linking to FTGL since I updated from 9476 to 9498. 
Anyone have the same problem?

My FTGL is a custom install, not obtained using a package manager. The 
./configure checks works fine for FTGL but linking liboctinterp fails 
during make. (paraphrase: cannot find -lftgl) Also, qrupdate seems to 
have similar problems. I'm setting up LDFLAGS and CPPFLAGS as before, 
passing them as arguments to configure.

Regards,
David

From jwe at octave.org  Thu Aug  6 10:25:44 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 6 Aug 2009 11:25:44 -0400
Subject: [changeset] GraphicsMagick++ configuration
In-Reply-To: <4A7AEEF4.2070101@acc.umu.se>
References: <4A7AEEF4.2070101@acc.umu.se>
Message-ID: <19066.62968.137520.390478@segfault.lan>

On  6-Aug-2009, David Grundberg wrote:

| I've rearranged the GraphicsMagick++ configuration. I had some trouble 
| since I'm running a custom GraphicsMagick installation. The Octave build 
| system was running GraphicsMagick++-config during make. It was missing 
| ldflags and using only the basename of the config executable (as opposed 
| to a full path).
| 
| I've changed it so that GraphicsMagick++-config is only run in the 
| configure script. Also introduced MAGICK_CONFIG as a precious variable.

I removed --ldflags to fix the following mysterious problem on my
system:

  https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-July/012879.html

So I don't think I can put it back without breaking __magick_read__
again, at least for me and other Debian users.

What are -Wl,-z,relro and -pie doing in the ldflags anyway?  Are those
arguments not present on your system?  Maybe they are present on mine
because of the way Debian builds the graphics magick library package?
Perhaps these flags make sense for creating the graphics magick
library itself, but I can't see any reason for them to be required to
link the graphics magick library with __magick_read__.oct.

jwe

From jwe at octave.org  Thu Aug  6 10:37:17 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 6 Aug 2009 11:37:17 -0400
Subject: linking changes for ftgl and qrupdate?
In-Reply-To: <4A7AEEAA.4050203@acc.umu.se>
References: <4A7AEEAA.4050203@acc.umu.se>
Message-ID: <19066.63661.94453.39016@segfault.lan>

On  6-Aug-2009, David Grundberg wrote:

| I'm having trouble linking to FTGL since I updated from 9476 to 9498. 
| Anyone have the same problem?
| 
| My FTGL is a custom install, not obtained using a package manager. The 
| ./configure checks works fine for FTGL but linking liboctinterp fails 
| during make. (paraphrase: cannot find -lftgl) Also, qrupdate seems to 
| have similar problems. I'm setting up LDFLAGS and CPPFLAGS as before, 
| passing them as arguments to configure.

I recently made some changes to the way things are linked.  My intent
was to not list all libraries on the final link for building Octave,
but have library dependencies resolved by linking the required
dependencies with each shared library.

Looking at src/Makefile.in, it seems that SH_LDFLAGS needs to have
some extra directories in it.  But I guess I'd rather avoid putting
all directories in that, and somehow group the FTGL -LDIR options with
the -lftgl option, so that the special FTGL directory only appears
when linking liboctinterp, not also when linking libcruft, or
liboctave, which don't depend on FTGL (for example).

If you install FTGL in a custom directory that is not searched by
default when linking, are you arranging for the FTGL library to be
found at run time through ld.so.conf or similar?  Or do we also need
to add an --rpath option for your custom directory?  Or should we
leave it up to you to do the configuration or set LD_LIBRARY_PATH
appropriately? 

jwe

From individ at acc.umu.se  Thu Aug  6 15:09:12 2009
From: individ at acc.umu.se (David Grundberg)
Date: Thu, 06 Aug 2009 22:09:12 +0200
Subject: [changeset] GraphicsMagick++ configuration
In-Reply-To: <19066.62968.137520.390478@segfault.lan>
References: <4A7AEEF4.2070101@acc.umu.se>
	<19066.62968.137520.390478@segfault.lan>
Message-ID: <4A7B3868.9020001@acc.umu.se>

John W. Eaton skrev:
> On  6-Aug-2009, David Grundberg wrote:
>
> | I've rearranged the GraphicsMagick++ configuration. I had some trouble 
> | since I'm running a custom GraphicsMagick installation. The Octave build 
> | system was running GraphicsMagick++-config during make. It was missing 
> | ldflags and using only the basename of the config executable (as opposed 
> | to a full path).
> | 
> | I've changed it so that GraphicsMagick++-config is only run in the 
> | configure script. Also introduced MAGICK_CONFIG as a precious variable.
>
> I removed --ldflags to fix the following mysterious problem on my
> system:
>
>   https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-July/012879.html
>
> So I don't think I can put it back without breaking __magick_read__
> again, at least for me and other Debian users.
>
> What are -Wl,-z,relro and -pie doing in the ldflags anyway?  Are those
> arguments not present on your system?  Maybe they are present on mine
> because of the way Debian builds the graphics magick library package?
> Perhaps these flags make sense for creating the graphics magick
> library itself, but I can't see any reason for them to be required to
> link the graphics magick library with __magick_read__.oct.
>
> jwe
>   
So that's why --ldflags was taken away! I don't have that problem. This 
is the output from my config (where I'm building):

$ 
octave-patching/dependencies/graphicsmagick-install/bin/GraphicsMagick++-config 
--ldflags --libs
-L/Home/staff/davidg/octave-patching/dependencies/graphicsmagick-install/lib 
-L/usr/lib -L/usr/lib
-lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper 
-ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm 
-lgomp -lpthread

My ubuntu 9.04 box says this about the managed package (haven't tried 
building against it):
david at lack:~$ GraphicsMagick++-config --ldflags --libs
-L/usr/lib -Wl,-Bsymbolic-functions -L/usr/lib/X11 -L/usr/lib -L/usr/lib
-lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper 
-ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm 
-lpthread

David

From jwe at octave.org  Thu Aug  6 15:15:56 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 6 Aug 2009 16:15:56 -0400
Subject: [changeset] GraphicsMagick++ configuration
In-Reply-To: <4A7B3868.9020001@acc.umu.se>
References: <4A7AEEF4.2070101@acc.umu.se>
	<19066.62968.137520.390478@segfault.lan>
	<4A7B3868.9020001@acc.umu.se>
Message-ID: <19067.14844.220747.257229@segfault.lan>

On  6-Aug-2009, David Grundberg wrote:

| John W. Eaton skrev:
| > On  6-Aug-2009, David Grundberg wrote:
| >
| > | I've rearranged the GraphicsMagick++ configuration. I had some trouble 
| > | since I'm running a custom GraphicsMagick installation. The Octave build 
| > | system was running GraphicsMagick++-config during make. It was missing 
| > | ldflags and using only the basename of the config executable (as opposed 
| > | to a full path).
| > | 
| > | I've changed it so that GraphicsMagick++-config is only run in the 
| > | configure script. Also introduced MAGICK_CONFIG as a precious variable.
| >
| > I removed --ldflags to fix the following mysterious problem on my
| > system:
| >
| >   https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-July/012879.html
| >
| > So I don't think I can put it back without breaking __magick_read__
| > again, at least for me and other Debian users.
| >
| > What are -Wl,-z,relro and -pie doing in the ldflags anyway?  Are those
| > arguments not present on your system?  Maybe they are present on mine
| > because of the way Debian builds the graphics magick library package?
| > Perhaps these flags make sense for creating the graphics magick
| > library itself, but I can't see any reason for them to be required to
| > link the graphics magick library with __magick_read__.oct.
| >
| > jwe
| >   
| So that's why --ldflags was taken away! I don't have that problem. This 
| is the output from my config (where I'm building):
| 
| $ 
| octave-patching/dependencies/graphicsmagick-install/bin/GraphicsMagick++-config 
| --ldflags --libs
| -L/Home/staff/davidg/octave-patching/dependencies/graphicsmagick-install/lib 
| -L/usr/lib -L/usr/lib
| -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper 
| -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm 
| -lgomp -lpthread
| 
| My ubuntu 9.04 box says this about the managed package (haven't tried 
| building against it):
| david at lack:~$ GraphicsMagick++-config --ldflags --libs
| -L/usr/lib -Wl,-Bsymbolic-functions -L/usr/lib/X11 -L/usr/lib -L/usr/lib
| -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper 
| -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm 
| -lpthread

So what should we do about this?  I suppose we could try working
around it by filtering out everything except -L options from the
--ldflags output, but I'd rather see it fixed in graphics magick.
What should graphics magick really be storing in the config script
for --ldflags?  Should options like -pie and -Wl,-z,relro really
appear there?  Or is this just a Debian packaging problem?

jwe

From individ at acc.umu.se  Thu Aug  6 15:28:24 2009
From: individ at acc.umu.se (David Grundberg)
Date: Thu, 06 Aug 2009 22:28:24 +0200
Subject: linking changes for ftgl and qrupdate?
In-Reply-To: <19066.63661.94453.39016@segfault.lan>
References: <4A7AEEAA.4050203@acc.umu.se>
	<19066.63661.94453.39016@segfault.lan>
Message-ID: <4A7B3CE8.9020701@acc.umu.se>

John W. Eaton skrev:
> On  6-Aug-2009, David Grundberg wrote:
>
> | I'm having trouble linking to FTGL since I updated from 9476 to 9498. 
> | Anyone have the same problem?
> | 
> | My FTGL is a custom install, not obtained using a package manager. The 
> | ./configure checks works fine for FTGL but linking liboctinterp fails 
> | during make. (paraphrase: cannot find -lftgl) Also, qrupdate seems to 
> | have similar problems. I'm setting up LDFLAGS and CPPFLAGS as before, 
> | passing them as arguments to configure.
>
> I recently made some changes to the way things are linked.  My intent
> was to not list all libraries on the final link for building Octave,
> but have library dependencies resolved by linking the required
> dependencies with each shared library.
>
> Looking at src/Makefile.in, it seems that SH_LDFLAGS needs to have
> some extra directories in it.  But I guess I'd rather avoid putting
> all directories in that, and somehow group the FTGL -LDIR options with
> the -lftgl option, so that the special FTGL directory only appears
> when linking liboctinterp, not also when linking libcruft, or
> liboctave, which don't depend on FTGL (for example).
>   

It occurs to me that FTGL uses pkg-config. I should have set that up 
correctly instead of just building LDFLAGS and CPPFLAGS. Missed that 
completely. But on the other hand, looking in the configure script, 
pkg-config isn't used for ftgl. And there is no way -lftgl will be 
accompanied with a -L flag to point out the ftgl library. (But LDFLAGS 
used to accompany before, apparently, since I was able to build earlier) 
I think configure.in needs to add a -L flag together with the -lftgl to 
$OPENGL_LIBS, or something like that.

> If you install FTGL in a custom directory that is not searched by
> default when linking, are you arranging for the FTGL library to be
> found at run time through ld.so.conf or similar?  Or do we also need
> to add an --rpath option for your custom directory?  Or should we
> leave it up to you to do the configuration or set LD_LIBRARY_PATH
> appropriately? 
>
> jwe
>   

I'm used to having to set LD_LIBRARY_PATH properly. I wouldn't expect 
rpath to be set.

David

From individ at acc.umu.se  Thu Aug  6 15:40:15 2009
From: individ at acc.umu.se (David Grundberg)
Date: Thu, 06 Aug 2009 22:40:15 +0200
Subject: [changeset] GraphicsMagick++ configuration
In-Reply-To: <19067.14844.220747.257229@segfault.lan>
References: <4A7AEEF4.2070101@acc.umu.se>	<19066.62968.137520.390478@segfault.lan>	<4A7B3868.9020001@acc.umu.se>
	<19067.14844.220747.257229@segfault.lan>
Message-ID: <4A7B3FAF.5060509@acc.umu.se>

John W. Eaton skrev:
> On  6-Aug-2009, David Grundberg wrote:
>
> | John W. Eaton skrev:
> | > On  6-Aug-2009, David Grundberg wrote:
> | >
> | > | I've rearranged the GraphicsMagick++ configuration. I had some trouble 
> | > | since I'm running a custom GraphicsMagick installation. The Octave build 
> | > | system was running GraphicsMagick++-config during make. It was missing 
> | > | ldflags and using only the basename of the config executable (as opposed 
> | > | to a full path).
> | > | 
> | > | I've changed it so that GraphicsMagick++-config is only run in the 
> | > | configure script. Also introduced MAGICK_CONFIG as a precious variable.
> | >
> | > I removed --ldflags to fix the following mysterious problem on my
> | > system:
> | >
> | >   https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-July/012879.html
> | >
> | > So I don't think I can put it back without breaking __magick_read__
> | > again, at least for me and other Debian users.
> | >
> | > What are -Wl,-z,relro and -pie doing in the ldflags anyway?  Are those
> | > arguments not present on your system?  Maybe they are present on mine
> | > because of the way Debian builds the graphics magick library package?
> | > Perhaps these flags make sense for creating the graphics magick
> | > library itself, but I can't see any reason for them to be required to
> | > link the graphics magick library with __magick_read__.oct.
> | >
> | > jwe
> | >   
> | So that's why --ldflags was taken away! I don't have that problem. This 
> | is the output from my config (where I'm building):
> | 
> | $ 
> | octave-patching/dependencies/graphicsmagick-install/bin/GraphicsMagick++-config 
> | --ldflags --libs
> | -L/Home/staff/davidg/octave-patching/dependencies/graphicsmagick-install/lib 
> | -L/usr/lib -L/usr/lib
> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper 
> | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm 
> | -lgomp -lpthread
> | 
> | My ubuntu 9.04 box says this about the managed package (haven't tried 
> | building against it):
> | david at lack:~$ GraphicsMagick++-config --ldflags --libs
> | -L/usr/lib -Wl,-Bsymbolic-functions -L/usr/lib/X11 -L/usr/lib -L/usr/lib
> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper 
> | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm 
> | -lpthread
>
> So what should we do about this?  I suppose we could try working
> around it by filtering out everything except -L options from the
> --ldflags output, but I'd rather see it fixed in graphics magick.
> What should graphics magick really be storing in the config script
> for --ldflags?  Should options like -pie and -Wl,-z,relro really
> appear there?  Or is this just a Debian packaging problem?
>
> jwe
>   

I don't know. Maybe pkg-config lists something better? On my ubuntu it 
lists exactly the same flags as gm-config, though. I'm not particularly 
good at this, but ld -Bsymbolic-functions seems like something one would 
only need while building gm itself.

David

From jwe at octave.org  Thu Aug  6 15:43:46 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 6 Aug 2009 16:43:46 -0400
Subject: problem with structure assignment
Message-ID: <19067.16514.923398.841366@segfault.lan>

The following bug was reported before 3.2.2

  https://www-old.cae.wisc.edu/pipermail/bug-octave/2009-July/008949.html

Looking at the hg log for the release-3-2-x archive, it looks like the
patch was applied before version 3.2.2, but I still have the problem
in the copy of 3.2.2 that I built.

Examples that cause trouble are

  a.b{1}.c = 1

or the one given in the original report

  s.a(1).c.d = 123

(with a and S previously undefined).  My copy of 3.2.2 gives the error

  error: can't perform indexing operations for <unknown type> type

in both cases.

Looking at the Octave 3.2.2 sources from ftp.octave.org, the patch
appears to be there.

Both work correctly for me in the current development version.

Is it just me?  Do these examples work properly for other people with
3.2.2?

Thanks,

jwe

From bpabbott at mac.com  Thu Aug  6 17:33:50 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Thu, 06 Aug 2009 18:33:50 -0400
Subject: problem with structure assignment
In-Reply-To: <19067.16514.923398.841366@segfault.lan>
References: <19067.16514.923398.841366@segfault.lan>
Message-ID: <4D5ACCF3-A1F3-4B72-A8F6-C14FB722A106@mac.com>


On Aug 6, 2009, at 4:43 PM, John W. Eaton wrote:

> The following bug was reported before 3.2.2
>
>  https://www-old.cae.wisc.edu/pipermail/bug-octave/2009-July/008949.html
>
> Looking at the hg log for the release-3-2-x archive, it looks like the
> patch was applied before version 3.2.2, but I still have the problem
> in the copy of 3.2.2 that I built.
>
> Examples that cause trouble are
>
>  a.b{1}.c = 1
>
> or the one given in the original report
>
>  s.a(1).c.d = 123
>
> (with a and S previously undefined).  My copy of 3.2.2 gives the error
>
>  error: can't perform indexing operations for <unknown type> type
>
> in both cases.
>
> Looking at the Octave 3.2.2 sources from ftp.octave.org, the patch
> appears to be there.
>
> Both work correctly for me in the current development version.
>
> Is it just me?  Do these examples work properly for other people with
> 3.2.2?
>
> Thanks,
>
> jwe

I haven't pulled in a few days, and I get the same error you did.

octave:1> b=1
b =  1
octave:2> s.a(b).c.d=123
error: can't perform indexing operations for <unknown type> type

I've just pulled and started the make. If anything changes, I'll reply  
again.

Ben




From marco.caliari at univr.it  Fri Aug  7 04:55:13 2009
From: marco.caliari at univr.it (Marco Caliari)
Date: Fri, 07 Aug 2009 11:55:13 +0200 (CEST)
Subject: Logaritmic plots of nonpositive data
Message-ID: <alpine.DEB.1.00.0908071137210.9302@profs.sci.univr.it>

Dear maintainers,

the following

semilogy([0,0])

produces an empty window (without axes) in Octave 3.2.2 (though I remember 
that some days ago it produced nothing, as in Octave 3.0.5, I cannot 
explain why) and no warning about nonpositive data.
With the enclosed patch the axes are computed is a quite ml compatible way
and the warning is there. As a ChangeLog I would say

2009-08-07  Marco Caliari  <marco.caliari at univr.it>

         * graphics.cc (get_array_limits): set min_pos value to 0.1
 	if data are nonpositive.

Best regards,

Marco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics.cc.patch
Type: text/x-diff
Size: 230 bytes
Desc: 
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090807/2128cad9/attachment.bin 

From jwe at octave.org  Fri Aug  7 14:55:59 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 7 Aug 2009 15:55:59 -0400
Subject: overloaded function handles
In-Reply-To: <69d8d540907312315x76a0e564u438fff0e39884690@mail.gmail.com>
References: <69d8d540907230549l2ca456a2n3cdb05531a2f1dfe@mail.gmail.com>
	<69d8d540907290241i85dcb4dy6214398f6ce103e7@mail.gmail.com>
	<a0daad600907291219j8c026e9x99ee306f58cd443b@mail.gmail.com>
	<4A70C98A.3020701@phaselockedsystems.com>
	<69d8d540907300001m604c9c87tb08b6a38567e86da@mail.gmail.com>
	<1248939735.3653.5.camel@sh-t400>
	<69d8d540907300112k4004ee75p55cc8d575477b28f@mail.gmail.com>
	<4A7204C3.1070403@phaselockedsystems.com>
	<69d8d540907302332j64f6499euca7d40b937b4977a@mail.gmail.com>
	<4A73B9C2.8070105@phaselockedsystems.com>
	<69d8d540907312315x76a0e564u438fff0e39884690@mail.gmail.com>
Message-ID: <19068.34511.978894.757819@segfault.lan>

If we know that some part of Octave is likely to infringe on a patent,
then I think we should either find a non-infringing way to implement
the feature, or remove the code that is likely to be infringing.

The MathWorks has sued at least one other company for patent
infringement.  See for example the recent case against COMSOL, which
appears to still be pending.

Perhaps more troubling than the patent case is the related breech of
contract and copyright infringement case which the MathWorks won.
Part of the claims of that case were apparently about "software
copyrightability, including the copyrightability of a compilation of
software commands, command names, and command syntax".  The result of
the judgement was apparently several million dollars in damages and a
permanent injunction against distributing COMSOL script (the
Matlab-like environment written and distributed by COMSOL).  BTW,
COMSOL is apparently a Swedish company which also does business in the
US.  So simply being based outside the US apparently doesn't allow you
to do whatever you like and to completely disregard US copyright and
patent laws.

It is up to you whether you want to distribute a patch separately from
Octave, but I think it would be best to remove any code that we think
infringes on any patent from the core Octave distribution.

In the case of MathWorks patents, it will be hard to claim ignorance
of one of their patents since they are listed on the MathWorks web
site.  Not that ignorance of a patent helps us anyway, since
independent invention is not a valid defense in patent infringement
cases.

If you think it is impossible to implement the feature in a
non-infringing way, then I guess that is a clear example of the
trouble software patents can cause.  Perhaps we should use this as a
way to clearly show people in the numerical software community why
software patents are harmful to users, and why members of our
community should not be rewarding the MathWorks for this kind of
behavior.  I suspect most Matlab users don't even know anything about
the litigation the MathWorks has been involved with in recent years.

jwe

From storrsjm at email.uc.edu  Fri Aug  7 16:09:33 2009
From: storrsjm at email.uc.edu (Judd Storrs)
Date: Fri, 7 Aug 2009 17:09:33 -0400
Subject: overloaded function handles
In-Reply-To: <19068.34511.978894.757819@segfault.lan>
References: <69d8d540907230549l2ca456a2n3cdb05531a2f1dfe@mail.gmail.com>
	<4A70C98A.3020701@phaselockedsystems.com>
	<69d8d540907300001m604c9c87tb08b6a38567e86da@mail.gmail.com>
	<1248939735.3653.5.camel@sh-t400>
	<69d8d540907300112k4004ee75p55cc8d575477b28f@mail.gmail.com>
	<4A7204C3.1070403@phaselockedsystems.com>
	<69d8d540907302332j64f6499euca7d40b937b4977a@mail.gmail.com>
	<4A73B9C2.8070105@phaselockedsystems.com>
	<69d8d540907312315x76a0e564u438fff0e39884690@mail.gmail.com>
	<19068.34511.978894.757819@segfault.lan>
Message-ID: <a0daad600908071409i30538998gdc7c96d4c3e708b2@mail.gmail.com>

I came across this article sometime this week and bookmarked it for further
reading (I haven't yet had time to read closely) about the newest
specification of the java virtual machine now including bytecodes for
function handles. This was added to improve support and performance of
dynamic scripting languages that target the JVM.

http://java.sun.com/developer/technicalArticles/DynTypeLang/index.html

There is a discussion about (supposedly annoying) ways to emulate the
desired behavior that have been used by scripting languages on the JVM in
the past.

--judd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090807/c01c2a27/attachment.html 

From highegg at gmail.com  Fri Aug  7 23:19:24 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Sat, 8 Aug 2009 06:19:24 +0200
Subject: overloaded function handles
In-Reply-To: <19068.34511.978894.757819@segfault.lan>
References: <69d8d540907230549l2ca456a2n3cdb05531a2f1dfe@mail.gmail.com>
	<4A70C98A.3020701@phaselockedsystems.com>
	<69d8d540907300001m604c9c87tb08b6a38567e86da@mail.gmail.com>
	<1248939735.3653.5.camel@sh-t400>
	<69d8d540907300112k4004ee75p55cc8d575477b28f@mail.gmail.com>
	<4A7204C3.1070403@phaselockedsystems.com>
	<69d8d540907302332j64f6499euca7d40b937b4977a@mail.gmail.com>
	<4A73B9C2.8070105@phaselockedsystems.com>
	<69d8d540907312315x76a0e564u438fff0e39884690@mail.gmail.com>
	<19068.34511.978894.757819@segfault.lan>
Message-ID: <69d8d540908072119y52cedf0ds2c3983dc34ae9ab9@mail.gmail.com>

On Fri, Aug 7, 2009 at 9:55 PM, John W. Eaton<jwe at octave.org> wrote:
> If we know that some part of Octave is likely to infringe on a patent,
> then I think we should either find a non-infringing way to implement
> the feature, or remove the code that is likely to be infringing.
>

What if it can't be removed?

>
> The MathWorks has sued at least one other company for patent
> infringement. ?See for example the recent case against COMSOL, which
> appears to still be pending.
>
> Perhaps more troubling than the patent case is the related breech of
> contract and copyright infringement case which the MathWorks won.
> Part of the claims of that case were apparently about "software
> copyrightability, including the copyrightability of a compilation of
> software commands, command names, and command syntax". ?The result of
> the judgement was apparently several million dollars in damages and a
> permanent injunction against distributing COMSOL script (the
> Matlab-like environment written and distributed by COMSOL). ?BTW,
> COMSOL is apparently a Swedish company which also does business in the
> US. ?So simply being based outside the US apparently doesn't allow you
> to do whatever you like and to completely disregard US copyright and
> patent laws.
>

Well, obviously, anyone doing business in USA must abide by US laws.

>
> It is up to you whether you want to distribute a patch separately from
> Octave, but I think it would be best to remove any code that we think
> infringes on any patent from the core Octave distribution.
>

I think a separate repo would be more convenient, at least for me.

>
> In the case of MathWorks patents, it will be hard to claim ignorance
> of one of their patents since they are listed on the MathWorks web
> site. ?Not that ignorance of a patent helps us anyway, since
> independent invention is not a valid defense in patent infringement
> cases.
>

Well, I *would* be ignorant about the patent if you didn't bring it
up. I can think of billion times better spending my time than reading
patent claims. But of course you're right, that doesn't help.

>
> If you think it is impossible to implement the feature in a
> non-infringing way, then I guess that is a clear example of the
> trouble software patents can cause. ?Perhaps we should use this as a
> way to clearly show people in the numerical software community why
> software patents are harmful to users, and why members of our
> community should not be rewarding the MathWorks for this kind of
> behavior. ?I suspect most Matlab users don't even know anything about
> the litigation the MathWorks has been involved with in recent years.
>

In a strict mathematical sense, even the previous implementation did
violate the patent - at least claim 1.
Only it was less obvious. The only way to be really sure would be
removing function handles completely, which would severely cripple
Octave. Also, for instance, I think symbol_table::fcn_info is likely
violating the US patent 7,051,338. And I wonder if there are more.

I think these patents are clearly designed to *prevent* the creation
of a competing software - which is exactly what Octave tries to do. So
either Octave abandons that goal, or it will likely be in perpetual
danger of infringing patents.

Personally, I can neither guarantee that my contributions to Octave
don't infringe software patents, nor am I willing to spend time to do
so. So I really think that to protect the US users from infringements,
we need a patent-free branch for the USA, or a patent-safe branch for
the rest of the world (OK, maybe there are also relevant patents in
other countries, but I hope not).

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


From lindnerben at gmx.net  Wed Aug  5 07:49:54 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Wed, 05 Aug 2009 14:49:54 +0200
Subject: octave 3.2.2 build with libstdc++_s.a by GCC-4.4.0 (MinGW
	Official)
In-Reply-To: <20090726023056.32701.qmail@web3815.mail.bbt.yahoo.co.jp>
References: <20090726023056.32701.qmail@web3815.mail.bbt.yahoo.co.jp>
Message-ID: <4A797FF2.9000605@gmx.net>

Tatsuro MATSUOKA wrote:
> The first post included mistakes so that please ignore that.
> 
> ***********
> Hello
> 
> I have tried to build octave 3.2.2  with libstdc++_s.a by GCC-4.4.0 (MinGW Official) .
> 
> With very tricky way, I have got a successful result.
> 

:) Yes it is tricky.
I have a local changeset to include the -lstdc++_s where necessary, but 
hesitated to push it here.

I have been following the discussion on shared libstd++ on mingw/cgwin a 
bit (also in view of mingw64 compilers) an it seems that work is done to 
get a shared lib working, but it does not build standard-conformant. 
There seems to be a problem with user-defined new/delete handlers when 
linking shared libraries beause windows does not allow undefined symbols 
for dlls (didn't fully grasp the wpicture, though).
anyway, discussion is also to add respectively enable the flag 
-shared-libstd++ which would then set all compile/link flags accoringly.

So I think the current way of dealing with shared libstd++ is a bit of a 
hack, and because for that - long story's short morale - I hesitate to 
get it into octave's build code.

We could share it here if anyone's interested, though.

> 
> is the same as the following without shared libstdc++
> 
> http://www.nabble.com/Re:-Octave-Version-3.2.2-Released-p24652801.html
> 
> However my way was too tricky, I think. 
> 
> Does anyone tried to build  octave by GCC-4.4.0-MinGW official with shared libstdc++ ?
> 

Not yet. On my todo list (which is frightfully long at the moment...).

benjamin


From jwe at octave.org  Tue Aug 11 18:36:51 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 11 Aug 2009 19:36:51 -0400
Subject: patch for 3.2.x branch
Message-ID: <19074.147.454273.474519@segfault.lan>

Does anyone object to applying the following patch to the 3.2.x
release branch?

  http://hg.savannah.gnu.org/hgweb/octave/rev/f2d354df53ee

Thanks,

jwe

From highegg at gmail.com  Thu Aug 13 00:56:24 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 13 Aug 2009 07:56:24 +0200
Subject: patch for 3.2.x branch
In-Reply-To: <19074.147.454273.474519@segfault.lan>
References: <19074.147.454273.474519@segfault.lan>
Message-ID: <69d8d540908122256g15b59c2al17282cfa1d8386be@mail.gmail.com>

On Wed, Aug 12, 2009 at 1:36 AM, John W. Eaton<jwe at octave.org> wrote:
> Does anyone object to applying the following patch to the 3.2.x
> release branch?
>
> ?http://hg.savannah.gnu.org/hgweb/octave/rev/f2d354df53ee
>
> Thanks,
>
> jwe
>

I applied it.

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


From highegg at gmail.com  Thu Aug 13 09:41:45 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 13 Aug 2009 16:41:45 +0200
Subject: FYI: subasgn argument optimization
Message-ID: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>

hi all,

this originated as a proof-of-concept, but eventually I managed to put
it in a usable state, so I pushed it to get possible feedback.
http://hg.savannah.gnu.org/hgweb/octave/rev/e79470be3ecb

Summary & background:
with this patch, Octave will attempt to optimize certain calls to
overloaded subsasgn (indexed assignment) m-file methods for user
classes.
Specifically, when A is a value of user class, then doing
A(I) = X
actually translates to
A = subsasgn (A, substruct("()",{I}), X);

The problem with the latter is that inherently, multiple copies of A
will exist at the time of the call (caller's scope and callee's scope,
as well as an internal copy),
thus an attempt to modify the copy inside subsasgn will cause a copy
to unshare the data.
With the new patch, when
A(I) = X
is executed, and the corresponding overloaded subsasgn method is
declared like this:

function obj = subsasgn (obj, subs, val)

then Octave will try to be smart and ignore the copy still stored
inside A; this will allow the method to modify the object's fields
without a redundant copy.

The effect can be demonstrated by the following benchmark, using the
polynomial class from Octave examples.

p = polynomial ([1:2e6]); # a big polynomial
tic;
for i = 0:50
  p{i} = i;  # change i-th order coefficient.
endfor
toc

with a recent version, I get:

Elapsed time is 0.485235 seconds.

with the new patch, the result is:

Elapsed time is 0.0172369 seconds.

while the first version copies 2 million numbers in each cycle, the
latter avoids it. Another way to observe this is to use system memory
monitor.
For classes storing significant amounts of data, the performance
improvements may be significant.
Of course, another option is to use a handle class, but those are less
Octavish (or Matlabish) and you need to handle multiple references all
yourself.

2 more comments:
1. this doesn't quite solve the problem in its entirety, since a
common practice inside subsasgn methods is to call subsasgn again to
handle the rest of index chain if needed.
However, calling through subsasgn bypasses the optimizations.
2. Since only one physical copy of the object always exists, an error
inside subsasgn.m does not revoke changes that have already been made.
It is solely the callee's responsibility not to leave the object in an
invalid state. This may possibly alter the way code works (though well
written code should probably work well). The internal variable
optimize_subsasgn_calls is provided to switch off the optimization, if
it causes problems. Another option is to declare different output and
input arguments in the method.
If this feature eventually stays in Octave, I think there should be a
big warning added somewhere in the docs.

Comments? Thoughts?

cheers

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

From highegg at gmail.com  Thu Aug 13 09:46:19 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 13 Aug 2009 16:46:19 +0200
Subject: FYI: subasgn argument optimization
In-Reply-To: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
Message-ID: <69d8d540908130746k948365dn9cfc8daf80901e78@mail.gmail.com>

On Thu, Aug 13, 2009 at 4:41 PM, Jaroslav Hajek<highegg at gmail.com> wrote:
> hi all,
>
> this originated as a proof-of-concept, but eventually I managed to put
> it in a usable state, so I pushed it to get possible feedback.
> http://hg.savannah.gnu.org/hgweb/octave/rev/e79470be3ecb
>
> Summary & background:
> with this patch, Octave will attempt to optimize certain calls to
> overloaded subsasgn (indexed assignment) m-file methods for user
> classes.
> Specifically, when A is a value of user class, then doing
> A(I) = X
> actually translates to
> A = subsasgn (A, substruct("()",{I}), X);
>
> The problem with the latter is that inherently, multiple copies of A
> will exist at the time of the call (caller's scope and callee's scope,
> as well as an internal copy),
> thus an attempt to modify the copy inside subsasgn will cause a copy
> to unshare the data.
> With the new patch, when
> A(I) = X
> is executed, and the corresponding overloaded subsasgn method is
> declared like this:
>
> function obj = subsasgn (obj, subs, val)
>
> then Octave will try to be smart and ignore the copy still stored
> inside A; this will allow the method to modify the object's fields
> without a redundant copy.
>
> The effect can be demonstrated by the following benchmark, using the
> polynomial class from Octave examples.
>
> p = polynomial ([1:2e6]); # a big polynomial
> tic;
> for i = 0:50
> ?p{i} = i; ?# change i-th order coefficient.
> endfor
> toc
>
> with a recent version, I get:
>
> Elapsed time is 0.485235 seconds.
>
> with the new patch, the result is:
>
> Elapsed time is 0.0172369 seconds.
>
> while the first version copies 2 million numbers in each cycle, the
> latter avoids it. Another way to observe this is to use system memory
> monitor.
> For classes storing significant amounts of data, the performance
> improvements may be significant.
> Of course, another option is to use a handle class, but those are less
> Octavish (or Matlabish) and you need to handle multiple references all
> yourself.
>
> 2 more comments:
> 1. this doesn't quite solve the problem in its entirety, since a
> common practice inside subsasgn methods is to call subsasgn again to
> handle the rest of index chain if needed.
> However, calling through subsasgn bypasses the optimizations.
> 2. Since only one physical copy of the object always exists, an error
> inside subsasgn.m does not revoke changes that have already been made.
> It is solely the callee's responsibility not to leave the object in an
> invalid state. This may possibly alter the way code works (though well
> written code should probably work well). The internal variable
> optimize_subsasgn_calls is provided to switch off the optimization, if
> it causes problems. Another option is to declare different output and
> input arguments in the method.
> If this feature eventually stays in Octave, I think there should be a
> big warning added somewhere in the docs.
>
> Comments? Thoughts?
>
> cheers
>

PS. This patch rebases octave_class on top of octave_struct. This
allows reusing a plausible amount of code, but creates a couple of
other problems. These are, of course, solved in the code, but I can't
say I like the result very much (but then I didn't like very much even
the almost-duplicated subsref and subsasgn bodies). The way field
references should work for ancestor classes is still somewhat of a
mystery to me. I'd appreciate comments and suggestions from John or
anyone interested.

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


From lindnerben at gmx.net  Thu Aug 13 11:35:58 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Thu, 13 Aug 2009 18:35:58 +0200
Subject: "dir" crashing oactve 3.2.0/mingw32
In-Reply-To: <69d8d540907240501m78125a88oc0dfaf73d7790aa0@mail.gmail.com>
References: <4A464F59.50303@gmx.net>	
	<69d8d540907020252x6de9d5c1v1d8de55047a4a65b@mail.gmail.com>	
	<19030.16243.393456.35058@segfault.lan>
	<69d8d540907240501m78125a88oc0dfaf73d7790aa0@mail.gmail.com>
Message-ID: <4A8440EE.1050209@gmx.net>

Jaroslav Hajek wrote:
> On Thu, Jul 9, 2009 at 9:05 PM, John W. Eaton<jwe at octave.org> wrote:
>> On  2-Jul-2009, Jaroslav Hajek wrote:
>>
>> | On Sat, Jun 27, 2009 at 6:56 PM, Benjamin Lindner<lindnerben at gmx.net> wrote:
>> | > Hello,
>> | >
>> | > there have been some reports that simply calling "dir" crashes octave
>> | > 3.2.0/mingw32 on some windows platforms.
>> | > This has been tracked down to calls to strftime() failing with a "%T" format
>> | > specifier.
>> | >
>> | > Mingw uses the strftime function provided by microsoft C runtime library,
>> | > and indeed msdn states that the following format specifiers are supported:
>> | > aAbBcdHIjmMpSUwWxXyYzZ
>> | >
>> | > Mind that "T" is not supported, neither is "e".
>> | >
>> | > Don't ask me why MS does not simply ignore other format specifiers, but
>> | > causes applications to crash. But changing "%T" to the equivalent "%H:%M:%S"
>> | > fixes the crashes in "dir".
>> | > Since "e" is neither supported, I propose to change it to "d" (with "%e"
>> | > being sprintf("%d",dayofmonth) and "%d" being sprintf("%02d",dayofmonth).
>> | >
>> | > See the attached changeset.
>> | >
>> | > It would be great to have this also fixed in 3.2.x
>> | >
>> | > benjamin
>> |
>> |
>> | I don't think this is a good solution, since using %e in strftime will
>> | still crash. It would be much better if the replacements were
>> | conditionally (on windows) done directly in strftime.
>>
>> How about this change instead?
>>
>>  http://hg.savannah.gnu.org/hgweb/octave/rev/69d05d1a63b9
>>
>> jwe
>>
> 
> I transplanted it to 3.2.x
> 

just back from holiday and catching up on unread emails.
thanks for the fix, it's of course the right thing to do.

benjamin


From jordigh at gmail.com  Thu Aug 13 12:10:42 2009
From: jordigh at gmail.com (=?UTF-8?Q?Jordi_Guti=C3=A9rrez_Hermos?=)
Date: Thu, 13 Aug 2009 12:10:42 -0500
Subject: Requesting an Octave mentor
Message-ID: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>

Hello, Octave devs.

I'd like to try again to get into Octave development. I've realised
that for the kind of work I want to do, being able to point at work
I've done on Octave would be very good for my CV. I've tried in the
past to get into Octave development, but I've never been able to find
my way around the sources by myself.

I'm therefore asking for a kind soul with pedagogical inclinations to
help me get started, perhaps even with a pet project that they don't
want to undertake themselves but are willing to direct. I would like
to be able to coordinate work via email, and if time zones allow it,
via IRC or some IM program. My time zone is UTC - 05:00 or UTC - 04:00
depending on daylight savings time.

Does anyone feel like teaching me about how Octave sources are laid
out, how to start, how to find the functionality I may want to
improve?

Thanks,
- Jordi G. H.

From lindnerben at gmx.net  Thu Aug 13 12:14:21 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Thu, 13 Aug 2009 19:14:21 +0200
Subject: linking liboctave fails (lapack missing?)
Message-ID: <4A8449ED.1090506@gmx.net>

Hello,

I just tried to build the recent development tip on mingw32 and building 
fails at linking liboctave with a phletora of missing symbols from the 
lapack library.

looking at the linker command I see that indeed there is no -llapack 
present.

Digging the changelog I find that at revision 9490:3aeb7d881578
$(BLAS_LIBS) has been removed from LINK_DEPS in liboctave/makefile.in

I guess it should still be there, since arpack, qrupdate and quite some 
octave code depends on it.

benjamin

From lindnerben at gmx.net  Thu Aug 13 12:42:11 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Thu, 13 Aug 2009 19:42:11 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A8449ED.1090506@gmx.net>
References: <4A8449ED.1090506@gmx.net>
Message-ID: <4A845073.5010601@gmx.net>

Benjamin Lindner wrote:
> Hello,
> 
> I just tried to build the recent development tip on mingw32 and building 
> fails at linking liboctave with a phletora of missing symbols from the 
> lapack library.
> 
> looking at the linker command I see that indeed there is no -llapack 
> present.
> 
> Digging the changelog I find that at revision 9490:3aeb7d881578
> $(BLAS_LIBS) has been removed from LINK_DEPS in liboctave/makefile.in
> 
> I guess it should still be there, since arpack, qrupdate and quite some 
> octave code depends on it.
> 

I see that there is already a thread covering this topic on the bugs 
list. Sorry for the double-post.

Hovever, liboctave directly uses functinos from lapack, and uses the 
qrupdate and qrpack library which both depend on lapack, so lapack 
*should* be listed in LINK_DEPS.

benjamin





From lindnerben at gmx.net  Thu Aug 13 13:33:25 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Thu, 13 Aug 2009 20:33:25 +0200
Subject: "dir" crashing oactve 3.2.0/mingw32
In-Reply-To: <4A8440EE.1050209@gmx.net>
References: <4A464F59.50303@gmx.net>		<69d8d540907020252x6de9d5c1v1d8de55047a4a65b@mail.gmail.com>		<19030.16243.393456.35058@segfault.lan>	<69d8d540907240501m78125a88oc0dfaf73d7790aa0@mail.gmail.com>
	<4A8440EE.1050209@gmx.net>
Message-ID: <4A845C75.5060703@gmx.net>

> 
> just back from holiday and catching up on unread emails.
> thanks for the fix, it's of course the right thing to do.
> 
> benjamin
> 

Hmm, the patch introduces a regression when building both 3.2.x and 
current development tip.
At linking stage of liboctave ld.exe fails with missing symbols related 
to tzname.

I found that liboctave/strftime.c declares

#if HAVE_TZNAME
extern OCTAVE_IMPORT char *tzname[];
#endif

However, on mingw32, tzname[] is declared in <time.h> which is included 
by liboctave/strftime.c. The specific declaration in <time.h> does not 
match the one in strftime.c and I suppose the declaration in <time.h> is 
hidden by the declaration in strftime.c.

There is a config.h preprocessor macro HAVE_DECL_TZNAME, which according 
to config.h is defined if a tzname declaration is present. So the 
double-declaration is redundant and in the case of mingw32 breaks linking.

My suggestion is to change strftime.c to

#if HAVE_TZNAME && !HAVE_DECL_TZNAME
extern OCTAVE_IMPORT char *tzname[];
#endif

as the attached changeset does.

benjamin

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: strftime-fix-double-decl-tztime.changeset
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090813/e3c55575/attachment.ksh 

From bpabbott at mac.com  Thu Aug 13 13:50:09 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Thu, 13 Aug 2009 14:50:09 -0400
Subject: Requesting an Octave mentor
In-Reply-To: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
References: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
Message-ID: <54621609648180284731662518950939384701-Webmail@me.com>

 
On Thursday, August 13, 2009, at 01:10PM, "Jordi Guti?rrez Hermos" <jordigh at gmail.com> wrote:
>Hello, Octave devs.
>
>I'd like to try again to get into Octave development. I've realised
>that for the kind of work I want to do, being able to point at work
>I've done on Octave would be very good for my CV. I've tried in the
>past to get into Octave development, but I've never been able to find
>my way around the sources by myself.
>
>I'm therefore asking for a kind soul with pedagogical inclinations to
>help me get started, perhaps even with a pet project that they don't
>want to undertake themselves but are willing to direct. I would like
>to be able to coordinate work via email, and if time zones allow it,
>via IRC or some IM program. My time zone is UTC - 05:00 or UTC - 04:00
>depending on daylight savings time.
>
>Does anyone feel like teaching me about how Octave sources are laid
>out, how to start, how to find the functionality I may want to
>improve?
>
>Thanks,
>- Jordi G. H.

Jori,

I'll be of little help understanding the c++ sources, but regarding something to work on, the listeners for the backend would be nice to have. In particular having one to convert between the various units would be great!

If you're not familiar with what I'm referring to, I can explain.

Ben



From lindnerben at gmx.net  Thu Aug 13 15:51:56 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Thu, 13 Aug 2009 22:51:56 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A845073.5010601@gmx.net>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
Message-ID: <4A847CEC.6090800@gmx.net>

Benjamin Lindner wrote:
> Benjamin Lindner wrote:
>> Hello,
>>
>> I just tried to build the recent development tip on mingw32 and 
>> building fails at linking liboctave with a phletora of missing symbols 
>> from the lapack library.
>>
>> looking at the linker command I see that indeed there is no -llapack 
>> present.
>>
>> Digging the changelog I find that at revision 9490:3aeb7d881578
>> $(BLAS_LIBS) has been removed from LINK_DEPS in liboctave/makefile.in
>>
>> I guess it should still be there, since arpack, qrupdate and quite 
>> some octave code depends on it.
>>
> 
> I see that there is already a thread covering this topic on the bugs 
> list. Sorry for the double-post.
> 
> Hovever, liboctave directly uses functinos from lapack, and uses the 
> qrupdate and qrpack library which both depend on lapack, so lapack 
> *should* be listed in LINK_DEPS.
> 

The attached changeset fixes the linker issues for mingw32 platform by 
adding $(BLAS_LIBS) in liboctave's link depencendies.

benjamin
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: liboctave-linkdeps.changeset
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090813/6cd4bd11/attachment.ksh 

From octave at phaselockedsystems.com  Thu Aug 13 17:27:11 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Thu, 13 Aug 2009 15:27:11 -0700
Subject: Requesting an Octave mentor
In-Reply-To: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
References: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
Message-ID: <4A84933F.7070709@phaselockedsystems.com>

Jordi Guti?rrez Hermos wrote:
> Hello, Octave devs.
>
> I'd like to try again to get into Octave development. I've realised
> that for the kind of work I want to do, being able to point at work
> I've done on Octave would be very good for my CV. I've tried in the
> past to get into Octave development, but I've never been able to find
> my way around the sources by myself.
>
> I'm therefore asking for a kind soul with pedagogical inclinations to
> help me get started, perhaps even with a pet project that they don't
> want to undertake themselves but are willing to direct. I would like
> to be able to coordinate work via email, and if time zones allow it,
> via IRC or some IM program. My time zone is UTC - 05:00 or UTC - 04:00
> depending on daylight savings time.
>
> Does anyone feel like teaching me about how Octave sources are laid
> out, how to start, how to find the functionality I may want to
> improve?
>
> Thanks,
> - Jordi G. H.
>
>
>   
In my case it is a case of the blind leading the blind, but I would be 
happy to give this a try myself.  Nothing teaches like teaching!

I have been messing with the object-oriented programming and there are 
still lots of areas that could use attention, and I have found a bug in 
the load/save code that should be fixed.

Also, if there is anything I can do to help if you like the stuff Ben is 
looking at, that would be fine.

Bob

From octave at phaselockedsystems.com  Thu Aug 13 17:29:21 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Thu, 13 Aug 2009 15:29:21 -0700
Subject: FYI: subasgn argument optimization
In-Reply-To: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
Message-ID: <4A8493C1.9040504@phaselockedsystems.com>

Jaroslav,

I would hate you to think you are being ignored.  I will look at your 
patch and comment.  Time is really tight for the next few weeks, so 
please be patient.

I had suggested deriving octave-class from octave-struct sometime past 
and had intended to try it out.  I *think* it will solve a couple of 
problems with the OOP stuff, so I am glad you did it.

Bob

Jaroslav Hajek wrote:
> hi all,
>
> this originated as a proof-of-concept, but eventually I managed to put
> it in a usable state, so I pushed it to get possible feedback.
> http://hg.savannah.gnu.org/hgweb/octave/rev/e79470be3ecb
>
> Summary & background:
> with this patch, Octave will attempt to optimize certain calls to
> overloaded subsasgn (indexed assignment) m-file methods for user
> classes.
> Specifically, when A is a value of user class, then doing
> A(I) = X
> actually translates to
> A = subsasgn (A, substruct("()",{I}), X);
>
> The problem with the latter is that inherently, multiple copies of A
> will exist at the time of the call (caller's scope and callee's scope,
> as well as an internal copy),
> thus an attempt to modify the copy inside subsasgn will cause a copy
> to unshare the data.
> With the new patch, when
> A(I) = X
> is executed, and the corresponding overloaded subsasgn method is
> declared like this:
>
> function obj = subsasgn (obj, subs, val)
>
> then Octave will try to be smart and ignore the copy still stored
> inside A; this will allow the method to modify the object's fields
> without a redundant copy.
>
> The effect can be demonstrated by the following benchmark, using the
> polynomial class from Octave examples.
>
> p = polynomial ([1:2e6]); # a big polynomial
> tic;
> for i = 0:50
>   p{i} = i;  # change i-th order coefficient.
> endfor
> toc
>
> with a recent version, I get:
>
> Elapsed time is 0.485235 seconds.
>
> with the new patch, the result is:
>
> Elapsed time is 0.0172369 seconds.
>
> while the first version copies 2 million numbers in each cycle, the
> latter avoids it. Another way to observe this is to use system memory
> monitor.
> For classes storing significant amounts of data, the performance
> improvements may be significant.
> Of course, another option is to use a handle class, but those are less
> Octavish (or Matlabish) and you need to handle multiple references all
> yourself.
>
> 2 more comments:
> 1. this doesn't quite solve the problem in its entirety, since a
> common practice inside subsasgn methods is to call subsasgn again to
> handle the rest of index chain if needed.
> However, calling through subsasgn bypasses the optimizations.
> 2. Since only one physical copy of the object always exists, an error
> inside subsasgn.m does not revoke changes that have already been made.
> It is solely the callee's responsibility not to leave the object in an
> invalid state. This may possibly alter the way code works (though well
> written code should probably work well). The internal variable
> optimize_subsasgn_calls is provided to switch off the optimization, if
> it causes problems. Another option is to declare different output and
> input arguments in the method.
> If this feature eventually stays in Octave, I think there should be a
> big warning added somewhere in the docs.
>
> Comments? Thoughts?
>
> cheers
>
>   


From highegg at gmail.com  Fri Aug 14 00:30:30 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 14 Aug 2009 07:30:30 +0200
Subject: Requesting an Octave mentor
In-Reply-To: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
References: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
Message-ID: <69d8d540908132230y1e7c7d7cse07480b8012dba3b@mail.gmail.com>

On Thu, Aug 13, 2009 at 7:10 PM, Jordi Guti?rrez
Hermos<jordigh at gmail.com> wrote:
> Hello, Octave devs.
>
> I'd like to try again to get into Octave development. I've realised
> that for the kind of work I want to do, being able to point at work
> I've done on Octave would be very good for my CV. I've tried in the
> past to get into Octave development, but I've never been able to find
> my way around the sources by myself.
>
> I'm therefore asking for a kind soul with pedagogical inclinations to
> help me get started, perhaps even with a pet project that they don't
> want to undertake themselves but are willing to direct. I would like
> to be able to coordinate work via email, and if time zones allow it,
> via IRC or some IM program. My time zone is UTC - 05:00 or UTC - 04:00
> depending on daylight savings time.
>
> Does anyone feel like teaching me about how Octave sources are laid
> out,

That's easy - the whole lot of Octave sources is a horrible mess of
ill-designed classes, random hacks, gotchas and incomprehensible
blocks of unreadable code that you just hope are never actually
executed. And I'm proud to have contributed some of the messiest
pieces myself :D

> how to start, how to find the functionality I may want to
> improve?

First, decide what functionality you want to improve; share your idea
and discuss the possible implementation. Bug hunting is also an
excellent way to get familiar with the overall Octave code.

cheers

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


From jwe at octave.org  Fri Aug 14 00:41:38 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 14 Aug 2009 01:41:38 -0400
Subject: Requesting an Octave mentor
In-Reply-To: <69d8d540908132230y1e7c7d7cse07480b8012dba3b@mail.gmail.com>
References: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
	<69d8d540908132230y1e7c7d7cse07480b8012dba3b@mail.gmail.com>
Message-ID: <19076.63762.997506.547880@segfault.lan>

On 14-Aug-2009, Jaroslav Hajek wrote:

| That's easy - the whole lot of Octave sources is a horrible mess of
| ill-designed classes, random hacks, gotchas and incomprehensible
| blocks of unreadable code that you just hope are never actually
| executed.

Thanks.

jwe

From jwe at octave.org  Fri Aug 14 09:12:14 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 14 Aug 2009 10:12:14 -0400
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A847CEC.6090800@gmx.net>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net>
Message-ID: <19077.28862.827842.41629@segfault.lan>

On 13-Aug-2009, Benjamin Lindner wrote:

| Benjamin Lindner wrote:
| > Benjamin Lindner wrote:
| >> Hello,
| >>
| >> I just tried to build the recent development tip on mingw32 and 
| >> building fails at linking liboctave with a phletora of missing symbols 
| >> from the lapack library.
| >>
| >> looking at the linker command I see that indeed there is no -llapack 
| >> present.
| >>
| >> Digging the changelog I find that at revision 9490:3aeb7d881578
| >> $(BLAS_LIBS) has been removed from LINK_DEPS in liboctave/makefile.in
| >>
| >> I guess it should still be there, since arpack, qrupdate and quite 
| >> some octave code depends on it.
| >>
| > 
| > I see that there is already a thread covering this topic on the bugs 
| > list. Sorry for the double-post.
| > 
| > Hovever, liboctave directly uses functinos from lapack, and uses the 
| > qrupdate and qrpack library which both depend on lapack, so lapack 
| > *should* be listed in LINK_DEPS.
| > 
| 
| The attached changeset fixes the linker issues for mingw32 platform by 
| adding $(BLAS_LIBS) in liboctave's link depencendies.

I made this change.

It would be helpful if people building Octave on Windows and OS X
systems could configure and build the latest Octave sources on and
send a list of symbols that are unresolved when creating the libcruft,
liboctave, liboctinterp shared libraries, when linking the Octave
executable file, and when building the .oct files.

When building the liboctinterp shared library, is it necesary to
explicitly list all of the libraries that are linked with liboctave?
Or are only some required, and if so, which ones, and why only those?

Thanks,

jwe

From jordigh at gmail.com  Fri Aug 14 10:11:42 2009
From: jordigh at gmail.com (=?UTF-8?Q?Jordi_Guti=C3=A9rrez_Hermos?=)
Date: Fri, 14 Aug 2009 10:11:42 -0500
Subject: Requesting an Octave mentor
In-Reply-To: <19076.63762.997506.547880@segfault.lan>
References: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
	<69d8d540908132230y1e7c7d7cse07480b8012dba3b@mail.gmail.com>
	<19076.63762.997506.547880@segfault.lan>
Message-ID: <9543b3a40908140811i7860ef09lac66c157fb4232e6@mail.gmail.com>

I hope it's ok if I respond to several people at once.

2009/8/13 Ben Abbott <bpabbott at mac.com>:
> I'll be of little help understanding the c++ sources, but regarding
> something to work on, the listeners for the backend would be nice to
> have. In particular having one to convert between the various units
> would be great!
>
> If you're not familiar with what I'm referring to, I can explain.

Alright, this sounds interesting. I really want Octave's plotting to
shine. This is likely to attract more people to the project. Yes,
please, I'd like more explanations. I'll contact you privately
momentarily to see if you have an IM account I can use for chatting
about this.

Or if IRC is convenient, maybe #octave in Freenode?

2009/8/13 Robert T. Short <octave at phaselockedsystems.com>:
> In my case it is a case of the blind leading the blind, but I would be happy
> to give this a try myself. Nothing teaches like teaching!

I agree. Perhaps you'd be more comfortable thinking of yourself as my
study buddy?

> Also, if there is anything I can do to help if you like the stuff Ben is
> looking at, that would be fine.

Let's do that. Let's work together with Ben.

2009/8/14 John W. Eaton <jwe at octave.org>:
> On 14-Aug-2009, Jaroslav Hajek wrote:
>
> | That's easy - the whole lot of Octave sources is a horrible mess of
> | ill-designed classes, random hacks, gotchas and incomprehensible
> | blocks of unreadable code that you just hope are never actually
> | executed.
>
> Thanks.

I consider it a well-established theorem of software development that
everyone's code sucks. Jaroslav's, mine, yours, everyone's. ;-) Proof:
either you stick to a rigid design methodology or you adapt loose and
flexible coding standard. In the former case, you will eventually come
upon a situation where your original design isn't flexible enough, in
which case it sucks, and in the latter situation your design is a
horrible mess of ad-hoc hacks, which also sucks. QED.

No, but seriously, Octave's code is messy because it's trying to solve
many complicated problems, but despite that, to quote the bard, I know
that there is method in the madness, because I've seen you guys talk
about it, and because I've glimpsed it myself. I have also worked with
very messy source trees, but with a little dedication, I've seen the
patterns emerging.

All I'm asking for is a little help in seeing those patterns in Octave
sources. :-)

Hopefully Ben and Robert above can help me get started.

- Jordi G. H.

From jwe at octave.org  Fri Aug 14 10:32:39 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 14 Aug 2009 11:32:39 -0400
Subject: Requesting an Octave mentor
In-Reply-To: <9543b3a40908140811i7860ef09lac66c157fb4232e6@mail.gmail.com>
References: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
	<69d8d540908132230y1e7c7d7cse07480b8012dba3b@mail.gmail.com>
	<19076.63762.997506.547880@segfault.lan>
	<9543b3a40908140811i7860ef09lac66c157fb4232e6@mail.gmail.com>
Message-ID: <19077.33687.138590.714603@segfault.lan>

On 14-Aug-2009, Jordi Guti?rrez Hermos wrote:

| No, but seriously, Octave's code is messy because it's trying to
| solve many complicated problems,

Sure, it has some messy parts, but I don't think there is too much
of it is "incomprehensible blocks of unreadable code".  For that, I
think you need to look at Perl.

jwe


From highegg at gmail.com  Fri Aug 14 10:33:03 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 14 Aug 2009 17:33:03 +0200
Subject: Requesting an Octave mentor
In-Reply-To: <9543b3a40908140811i7860ef09lac66c157fb4232e6@mail.gmail.com>
References: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
	<69d8d540908132230y1e7c7d7cse07480b8012dba3b@mail.gmail.com>
	<19076.63762.997506.547880@segfault.lan>
	<9543b3a40908140811i7860ef09lac66c157fb4232e6@mail.gmail.com>
Message-ID: <69d8d540908140833o71aef409o4070a07f62c41271@mail.gmail.com>

On Fri, Aug 14, 2009 at 5:11 PM, Jordi Guti?rrez
Hermos<jordigh at gmail.com> wrote:
> I hope it's ok if I respond to several people at once.
>
> 2009/8/13 Ben Abbott <bpabbott at mac.com>:
>> I'll be of little help understanding the c++ sources, but regarding
>> something to work on, the listeners for the backend would be nice to
>> have. In particular having one to convert between the various units
>> would be great!
>>
>> If you're not familiar with what I'm referring to, I can explain.
>
> Alright, this sounds interesting. I really want Octave's plotting to
> shine. This is likely to attract more people to the project. Yes,
> please, I'd like more explanations. I'll contact you privately
> momentarily to see if you have an IM account I can use for chatting
> about this.
>
> Or if IRC is convenient, maybe #octave in Freenode?
>
> 2009/8/13 Robert T. Short <octave at phaselockedsystems.com>:
>> In my case it is a case of the blind leading the blind, but I would be happy
>> to give this a try myself. Nothing teaches like teaching!
>
> I agree. Perhaps you'd be more comfortable thinking of yourself as my
> study buddy?
>
>> Also, if there is anything I can do to help if you like the stuff Ben is
>> looking at, that would be fine.
>
> Let's do that. Let's work together with Ben.
>
> 2009/8/14 John W. Eaton <jwe at octave.org>:
>> On 14-Aug-2009, Jaroslav Hajek wrote:
>>
>> | That's easy - the whole lot of Octave sources is a horrible mess of
>> | ill-designed classes, random hacks, gotchas and incomprehensible
>> | blocks of unreadable code that you just hope are never actually
>> | executed.
>>
>> Thanks.
>
> I consider it a well-established theorem of software development that
> everyone's code sucks. Jaroslav's, mine, yours, everyone's. ;-) Proof:
> either you stick to a rigid design methodology or you adapt loose and
> flexible coding standard. In the former case, you will eventually come
> upon a situation where your original design isn't flexible enough, in
> which case it sucks, and in the latter situation your design is a
> horrible mess of ad-hoc hacks, which also sucks. QED.
>

Well, I was just trying to be funny, I really didn't mean that any
part of Octave sources "sucks". There's a lot of code duplication; but
not trivial to eliminate; there's also much more macro usage than
today's CS theorists could take, but as John explained multiple times;
Octave started 10 years before the C++ standard and template support
in compilers was more like a non-standard feature. Even now, 10yrs
after the C++ standard (and new one coming), templates are still
tricky - I have already discovered 3 compiler bugs when doing template
work. Moreover, when heavy macro usage is replaced by heavy templating
(like oct-inttypes.h, for example), you can't really say that the
result is much more comprehensible. Of course, there are other
advantages (lack of backslashes, debugging), so in general templates
are better, but not always (which is what I thought in the past).
Combining macros and templates cleverly is particularly powerful.

I daresay that studying and contributing to Octave sources has been
one of the most valuable and enjoyable learning experiences in my
life, and I hope I'd be able to carry it on at least a while. I
started contributing to Octave having essentially zero practical C++
experience, and now I feel almost like an expert. Apart from that, I
also learned a lot more about numerical mathematics and programming
techniques in general, as well as to use autoconf, mercurial, etc.


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


From jwe at octave.org  Fri Aug 14 10:34:55 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 14 Aug 2009 11:34:55 -0400
Subject: Requesting an Octave mentor
In-Reply-To: <9543b3a40908140811i7860ef09lac66c157fb4232e6@mail.gmail.com>
References: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
	<69d8d540908132230y1e7c7d7cse07480b8012dba3b@mail.gmail.com>
	<19076.63762.997506.547880@segfault.lan>
	<9543b3a40908140811i7860ef09lac66c157fb4232e6@mail.gmail.com>
Message-ID: <19077.33823.28131.956634@segfault.lan>

On 14-Aug-2009, Jordi Guti?rrez Hermos wrote:

| Or if IRC is convenient, maybe #octave in Freenode?

Speaking of this, are any other people here interested in using IM/IRC
type communications for quick questions?  I'm not sure how much I
would use it, but if other people are interested, maybe we should have
a semi-official place for this kind of thing?

jwe


From highegg at gmail.com  Fri Aug 14 10:35:08 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 14 Aug 2009 17:35:08 +0200
Subject: Requesting an Octave mentor
In-Reply-To: <19077.33687.138590.714603@segfault.lan>
References: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
	<69d8d540908132230y1e7c7d7cse07480b8012dba3b@mail.gmail.com>
	<19076.63762.997506.547880@segfault.lan>
	<9543b3a40908140811i7860ef09lac66c157fb4232e6@mail.gmail.com>
	<19077.33687.138590.714603@segfault.lan>
Message-ID: <69d8d540908140835v16e658ffo6e7ca5bed97fbf0d@mail.gmail.com>

On Fri, Aug 14, 2009 at 5:32 PM, John W. Eaton<jwe at octave.org> wrote:
> On 14-Aug-2009, Jordi Guti?rrez Hermos wrote:
>
> | No, but seriously, Octave's code is messy because it's trying to
> | solve many complicated problems,
>
> Sure, it has some messy parts, but I don't think there is too much
> of it is "incomprehensible blocks of unreadable code". ?For that, I
> think you need to look at Perl.
>

Er, sorry, John, that was supposed to be a joke. I really didn't mean
it seriously.

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


From jwe at octave.org  Fri Aug 14 10:39:01 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 14 Aug 2009 11:39:01 -0400
Subject: FYI: subasgn argument optimization
In-Reply-To: <69d8d540908130746k948365dn9cfc8daf80901e78@mail.gmail.com>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
	<69d8d540908130746k948365dn9cfc8daf80901e78@mail.gmail.com>
Message-ID: <19077.34069.745516.227226@segfault.lan>

On 13-Aug-2009, Jaroslav Hajek wrote:

| PS. This patch rebases octave_class on top of octave_struct.

It seems that would be a good thing.  I can no longer remember why
I didn't do it originally.  I don't think I would have avoided
inheritance unless I had a reason, but then maybe I didn't realize how
similar classes were to structs.

| The way field
| references should work for ancestor classes is still somewhat of a
| mystery to me. I'd appreciate comments and suggestions from John or
| anyone interested.

If you are asking for specific comments or suggestions about ancestor
classes, then I probably don't understand the way things are supposed
to work any better than you.  I think I would need specific questions
with examples.

jwe

From michael.goffioul at gmail.com  Fri Aug 14 10:49:34 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Fri, 14 Aug 2009 16:49:34 +0100
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <19077.28862.827842.41629@segfault.lan>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
Message-ID: <128f38bd0908140849v51a9ab02u3cdfca2a28702ff8@mail.gmail.com>

On Fri, Aug 14, 2009 at 3:12 PM, John W. Eaton<jwe at octave.org> wrote:
> I made this change.
>
> It would be helpful if people building Octave on Windows and OS X
> systems could configure and build the latest Octave sources on and
> send a list of symbols that are unresolved when creating the libcruft,
> liboctave, liboctinterp shared libraries, when linking the Octave
> executable file, and when building the .oct files.
>
> When building the liboctinterp shared library, is it necesary to
> explicitly list all of the libraries that are linked with liboctave?
> Or are only some required, and if so, which ones, and why only those?

Under Windows, usually you only need to list the libraries whose
symbols are actually used in the target library. If the target library
does not reference any symbol from a dependent lib, even if this
dependent lib is required by another dependent lib, it does not
need to be listed.

Michael.

From jwe at octave.org  Fri Aug 14 10:55:56 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 14 Aug 2009 11:55:56 -0400
Subject: FYI: subasgn argument optimization
In-Reply-To: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
Message-ID: <19077.35084.859814.827701@segfault.lan>

On 13-Aug-2009, Jaroslav Hajek wrote:

| 2. Since only one physical copy of the object always exists, an error
| inside subsasgn.m does not revoke changes that have already been made.
| It is solely the callee's responsibility not to leave the object in an
| invalid state. This may possibly alter the way code works (though well
| written code should probably work well). The internal variable
| optimize_subsasgn_calls is provided to switch off the optimization, if
| it causes problems. Another option is to declare different output and
| input arguments in the method.

This seems a bit problematic, since users have reason to expect that
an error during assignment doesn't alter existing data.

I'm a bit surprised that the situation is as bad as you describe, at
least for things like structs or cell arrays, which contain arrays of
octave_value objects, which are themselves reference counted objects.
So maybe we could do better and still preserve the current semantics
with regard to errors?

When you do something like

  s1 = struct (...);

you create a map with a collection of octave_value objects.  If
multiple copies of s1 are made, then the reference count for the
underlying octave_struct object is incremented.  Unsharing should
generate a separate copy the octave_struct object, but when copying
the elements in the map, we should only have to increment the count
for those objects.  What I would expect to happen is that we would
only copy the actual data for those objects if they were actually
changed.  If that's not happening and we are actually copying
everything at the first point of unsharing, then maybe that is
something that should be fixed?  Or maybe I'm misunderstanding
something and a complete copy of all elements in the map must happen
even when only a few elements are modified.

I probably won't be able to follow up on this discussion until
sometime Sunday at the earliest.

jwe

From jwe at octave.org  Fri Aug 14 11:04:48 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 14 Aug 2009 12:04:48 -0400
Subject: Requesting an Octave mentor
In-Reply-To: <69d8d540908140833o71aef409o4070a07f62c41271@mail.gmail.com>
References: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
	<69d8d540908132230y1e7c7d7cse07480b8012dba3b@mail.gmail.com>
	<19076.63762.997506.547880@segfault.lan>
	<9543b3a40908140811i7860ef09lac66c157fb4232e6@mail.gmail.com>
	<69d8d540908140833o71aef409o4070a07f62c41271@mail.gmail.com>
Message-ID: <19077.35616.586581.262670@segfault.lan>

On 14-Aug-2009, Jaroslav Hajek wrote:

| Well, I was just trying to be funny,

And don't take my replies too seriously either.

| There's a lot of code duplication; but
| not trivial to eliminate; there's also much more macro usage than
| today's CS theorists could take,

And I'm in favor of trying to clean things up.  (If I weren't, would I
be trying to clean up the configure script now?)

| Combining macros and templates cleverly is particularly powerful.

Yes, I'd like to move in this direction where possible, but you are
right that it doesn't make sense to try to remove all macros.

jwe

From highegg at gmail.com  Fri Aug 14 11:30:07 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 14 Aug 2009 18:30:07 +0200
Subject: FYI: subasgn argument optimization
In-Reply-To: <19077.35084.859814.827701@segfault.lan>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
	<19077.35084.859814.827701@segfault.lan>
Message-ID: <69d8d540908140930n110f3e2dh7adbf1e72655b459@mail.gmail.com>

On Fri, Aug 14, 2009 at 5:55 PM, John W. Eaton<jwe at octave.org> wrote:
> On 13-Aug-2009, Jaroslav Hajek wrote:
>
> | 2. Since only one physical copy of the object always exists, an error
> | inside subsasgn.m does not revoke changes that have already been made.
> | It is solely the callee's responsibility not to leave the object in an
> | invalid state. This may possibly alter the way code works (though well
> | written code should probably work well). The internal variable
> | optimize_subsasgn_calls is provided to switch off the optimization, if
> | it causes problems. Another option is to declare different output and
> | input arguments in the method.
>
> This seems a bit problematic, since users have reason to expect that
> an error during assignment doesn't alter existing data.
>
> I'm a bit surprised that the situation is as bad as you describe, at
> least for things like structs or cell arrays, which contain arrays of
> octave_value objects, which are themselves reference counted objects.
> So maybe we could do better and still preserve the current semantics
> with regard to errors?
>
> When you do something like
>
> ?s1 = struct (...);
>
> you create a map with a collection of octave_value objects. ?If
> multiple copies of s1 are made, then the reference count for the
> underlying octave_struct object is incremented. ?Unsharing should
> generate a separate copy the octave_struct object, but when copying
> the elements in the map, we should only have to increment the count
> for those objects. ?What I would expect to happen is that we would
> only copy the actual data for those objects if they were actually
> changed. ?If that's not happening and we are actually copying
> everything at the first point of unsharing, then maybe that is
> something that should be fixed?

Yes, it is what is happening - I inadvertently used the word "copy"
for both shallow copy and physical (deep) copy.
The problem is with large arrays as class member fields (for instance,
imagine a triangular matrix class). Suppose a struct x has a big
matrix field a = zeros(1000), that has no shallow copies. Then, the
statement
x.a(1,1) = 1;
directly modifies the stored array (although it did copy in 3.0.x).
If, however, x is a class, then what happens is this
1. x is shallow-copied and passed to the subsasgn method (say, as xx).
2. subsasgn method invokes the assignment xx.a(1,1) = 1;
2a. xx is unshared; xx.a is a shallow copy of x.a
2b. xx.a is unshared to complete the assignment, this causes a
physical copy of a's data.
3. at this point, x.a and xx.a are almost equal arrays; differing only
in the element 1,1.
4. the subsasgn method finishes and control is given back to caller
5. xx is assigned to x. x.a is released and replaced by xx.a.
6. xx is cleared.

the point is, that the physical copy created at point 2b is almost
always unnecessary, because the value of x.a will be replaced as soon
as the method finishes. unless an error occurs.

there is no way to both have this optimization and preserve the
behavior w.r.t. errors - this is easy to see. suppose the subsasgn
method first changes 999999 elements of the matrix, and then an error
occurs when changing the last element. there is no way to restore back
the prior values of the 999999 elements, because there is no copy.

so, of course, when working this way, the subsasgn method should be
coded using the paradigm
"first check everything, then assign" so that you never generate an
error *after* you have already overwritten something. this is exactly
what the nested assignment code inside ov-cell and ov-struct now does.

I believe that well written code already conforms to this paradigm, or
is very close. But of course, a flag should be provided to possibly
disable it - or it could be off by default, that can still be decided.
Another option is to declare the method with different input/output
variable; this is what one usually does when one wants to use a
copy-and-change approach rather than change-in-place.



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


From highegg at gmail.com  Fri Aug 14 12:05:45 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 14 Aug 2009 19:05:45 +0200
Subject: FYI: subasgn argument optimization
In-Reply-To: <19077.34069.745516.227226@segfault.lan>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
	<69d8d540908130746k948365dn9cfc8daf80901e78@mail.gmail.com>
	<19077.34069.745516.227226@segfault.lan>
Message-ID: <69d8d540908141005gfa669dkbe6475992effcaf4@mail.gmail.com>

On Fri, Aug 14, 2009 at 5:39 PM, John W. Eaton<jwe at octave.org> wrote:
> On 13-Aug-2009, Jaroslav Hajek wrote:
>
> | PS. This patch rebases octave_class on top of octave_struct.
>
> It seems that would be a good thing. ?I can no longer remember why
> I didn't do it originally. ?I don't think I would have avoided
> inheritance unless I had a reason, but then maybe I didn't realize how
> similar classes were to structs.
>
> | The way field
> | references should work for ancestor classes is still somewhat of a
> | mystery to me. I'd appreciate comments and suggestions from John or
> | anyone interested.
>
> If you are asking for specific comments or suggestions about ancestor
> classes, then I probably don't understand the way things are supposed
> to work any better than you. ?I think I would need specific questions
> with examples.
>

OK, here are some:

* A class is constructed from a struct. Can the struct be
multidimensional? (if the answer is no, then there is no need to read
further).
* Ancestor class is represented by a special field. If the struct is
multidimensional, what about this field?
* When an inherited method is called for an object, the inherited
method is called with the whole object, not just with the parent
subobject; field references are automatically forwarded to the proper
parent subobject. But what happens, for instance, if a multi-dim class
object is indexed just with ()?

I will try to read some Matlab docs and answer myself. I think the
most sensible approach is just to not allow multi-dim classes; I don't
see much use for it anyway.

regards

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


From jordigh at gmail.com  Fri Aug 14 12:44:30 2009
From: jordigh at gmail.com (=?UTF-8?Q?Jordi_Guti=C3=A9rrez_Hermos?=)
Date: Fri, 14 Aug 2009 12:44:30 -0500
Subject: Requesting an Octave mentor
In-Reply-To: <19077.33823.28131.956634@segfault.lan>
References: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
	<69d8d540908132230y1e7c7d7cse07480b8012dba3b@mail.gmail.com>
	<19076.63762.997506.547880@segfault.lan>
	<9543b3a40908140811i7860ef09lac66c157fb4232e6@mail.gmail.com>
	<19077.33823.28131.956634@segfault.lan>
Message-ID: <9543b3a40908141044r1db5f5ceh104cf8a0f786a1c1@mail.gmail.com>

2009/8/14 John W. Eaton <jwe at octave.org>:
> On 14-Aug-2009, Jordi Guti?rrez Hermos wrote:
>
> | Or if IRC is convenient, maybe #octave in Freenode?
>
> Speaking of this, are any other people here interested in using IM/IRC
> type communications for quick questions?

Well, there are a few people there already in Freenode, but I don't
see any familiar faces.

I'm very chatty, so yes, I obviously would like an official-looking
place for Octave chat.

- Jordi G. H.


From Thomas.Treichl at gmx.net  Fri Aug 14 12:47:09 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Fri, 14 Aug 2009 19:47:09 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <19077.28862.827842.41629@segfault.lan>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>
	<19077.28862.827842.41629@segfault.lan>
Message-ID: <4A85A31D.1000109@gmx.net>

John W. Eaton schrieb:
> On 13-Aug-2009, Benjamin Lindner wrote:
> 
> | Benjamin Lindner wrote:
> | > Benjamin Lindner wrote:
> | >> Hello,
> | >>
> | >> I just tried to build the recent development tip on mingw32 and 
> | >> building fails at linking liboctave with a phletora of missing symbols 
> | >> from the lapack library.
> | >>
> | >> looking at the linker command I see that indeed there is no -llapack 
> | >> present.
> | >>
> | >> Digging the changelog I find that at revision 9490:3aeb7d881578
> | >> $(BLAS_LIBS) has been removed from LINK_DEPS in liboctave/makefile.in
> | >>
> | >> I guess it should still be there, since arpack, qrupdate and quite 
> | >> some octave code depends on it.
> | >>
> | > 
> | > I see that there is already a thread covering this topic on the bugs 
> | > list. Sorry for the double-post.
> | > 
> | > Hovever, liboctave directly uses functinos from lapack, and uses the 
> | > qrupdate and qrpack library which both depend on lapack, so lapack 
> | > *should* be listed in LINK_DEPS.
> | > 
> | 
> | The attached changeset fixes the linker issues for mingw32 platform by 
> | adding $(BLAS_LIBS) in liboctave's link depencendies.
> 
> I made this change.
> 
> It would be helpful if people building Octave on Windows and OS X
> systems could configure and build the latest Octave sources on and
> send a list of symbols that are unresolved when creating the libcruft,
> liboctave, liboctinterp shared libraries, when linking the Octave
> executable file, and when building the .oct files.

Ok, I'll be one of those OS X people. I always do an ./autogen.sh before 
building (so I did this time). Now, ./configure fails with the message:

   ./configure: line 9350: syntax error near unexpected token `,'
   ./configure: line 9350: `    m4_ifnblank(, AC_LANG_PUSH())'

which in my configure script is

   TEXINFO_QHULL=
   warn_qhull="Qhull library not found -- this will result in loss of
   functionality of some geometry functions."
   if test -n "$QHULL_LIBS"; then
     save_CPPFLAGS="$CPPFLAGS"
     CPPFLAGS="$QHULL_CPPFLAGS $CPPFLAGS"
     m4_ifnblank(, AC_LANG_PUSH())

if I have a look at configure.in's part of this code I see the new macro 
OCTAVE_CHECK_LIBRARY with the sixth argument LANG being [].

But I also see this when I do ./autogen.sh:

   calling autoconf and autoheader...
   /Users/Thomas/Development/octave
   configure.in:40: error: possibly undefined macro: AC_DEFINE
       If this token and others are legitimate, please use m4_pattern_allow.
       See the Autoconf documentation.
   configure.in:63: error: possibly undefined macro: AS_HELP_STRING
   configure.in:617: error: possibly undefined macro: AC_LANG_PUSH
   configure.in:665: error: possibly undefined macro: AC_LANG_POP
   configure:1647: error: possibly undefined macro: m4_ifblank
   configure:9353: error: possibly undefined macro: m4_ifnblank
   configure:9565: error: possibly undefined macro: m4_toupper

?

MacMini:~/Development/octave Me$ autoconf --version
autoconf (GNU Autoconf) 2.62
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later
<http://gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David J. MacKenzie and Akim Demaille.

MacMini:~/Development/octave Me$ autoheader --version
autoheader (GNU Autoconf) 2.62
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later
<http://gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Roland McGrath and Akim Demaille.

> When building the liboctinterp shared library, is it necesary to
> explicitly list all of the libraries that are linked with liboctave?
> Or are only some required, and if so, which ones, and why only those?
> 
> Thanks,
> 
> jwe

From octave at phaselockedsystems.com  Fri Aug 14 12:49:18 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Fri, 14 Aug 2009 10:49:18 -0700
Subject: Requesting an Octave mentor
In-Reply-To: <9543b3a40908140811i7860ef09lac66c157fb4232e6@mail.gmail.com>
References: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>	<69d8d540908132230y1e7c7d7cse07480b8012dba3b@mail.gmail.com>	<19076.63762.997506.547880@segfault.lan>
	<9543b3a40908140811i7860ef09lac66c157fb4232e6@mail.gmail.com>
Message-ID: <4A85A39E.5090709@phaselockedsystems.com>

An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090814/14be98df/attachment.html 

From lindnerben at gmx.net  Fri Aug 14 13:28:35 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Fri, 14 Aug 2009 20:28:35 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <19077.28862.827842.41629@segfault.lan>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>
	<19077.28862.827842.41629@segfault.lan>
Message-ID: <4A85ACD3.2000305@gmx.net>

John W. Eaton wrote:
> I made this change.
> 
> It would be helpful if people building Octave on Windows and OS X
> systems could configure and build the latest Octave sources on and
> send a list of symbols that are unresolved when creating the libcruft,
> liboctave, liboctinterp shared libraries, when linking the Octave
> executable file, and when building the .oct files.
> 

On mingw32/msys, calling ./autogen.sh now displays

calling autoconf and autoheader...
/octmgw32/octave/octave-3.3.x
configure.in:40: error: possibly undefined macro: AC_DEFINE
       If this token and others are legitimate, please use m4_pattern_allow.
       See the Autoconf documentation.
configure.in:63: error: possibly undefined macro: AS_HELP_STRING
configure.in:617: error: possibly undefined macro: AC_LANG_PUSH
configure.in:665: error: possibly undefined macro: AC_LANG_POP
configure:1511: error: possibly undefined macro: m4_ifblank
configure:9276: error: possibly undefined macro: m4_ifnblank
configure:9479: error: possibly undefined macro: m4_toupper
/octmgw32/octave/octave-3.3.x/scripts
skipping autoheader in ./scripts
done

and a subsequent call to ./configure fails with

checking for sin in -lm... yes
/octmgw32/octave/octave-3.3.x/configure: line 9276: syntax error near 
unexpected token `,'
/octmgw32/octave/octave-3.3.x/configure: line 9276: `    m4_ifnblank(, 
AC_LANG_PUSH())'

?

$ autoconf --version
autoconf (GNU Autoconf) 2.61
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.

$ autoheader --version
autoheader (GNU Autoconf) 2.61
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.

Written by Roland McGrath and Akim Demaille.

benjamin

From lindnerben at gmx.net  Fri Aug 14 14:12:28 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Fri, 14 Aug 2009 21:12:28 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A85ACD3.2000305@gmx.net>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>	<19077.28862.827842.41629@segfault.lan>
	<4A85ACD3.2000305@gmx.net>
Message-ID: <4A85B71C.4070605@gmx.net>

Benjamin Lindner wrote:
> John W. Eaton wrote:
>> I made this change.
>>
>> It would be helpful if people building Octave on Windows and OS X
>> systems could configure and build the latest Octave sources on and
>> send a list of symbols that are unresolved when creating the libcruft,
>> liboctave, liboctinterp shared libraries, when linking the Octave
>> executable file, and when building the .oct files.
>>
> 
> On mingw32/msys, calling ./autogen.sh now displays
> 
> calling autoconf and autoheader...
> /octmgw32/octave/octave-3.3.x
> configure.in:40: error: possibly undefined macro: AC_DEFINE
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
> configure.in:63: error: possibly undefined macro: AS_HELP_STRING
> configure.in:617: error: possibly undefined macro: AC_LANG_PUSH
> configure.in:665: error: possibly undefined macro: AC_LANG_POP
> configure:1511: error: possibly undefined macro: m4_ifblank
> configure:9276: error: possibly undefined macro: m4_ifnblank
> configure:9479: error: possibly undefined macro: m4_toupper
> /octmgw32/octave/octave-3.3.x/scripts
> skipping autoheader in ./scripts
> done
> 
> and a subsequent call to ./configure fails with
> 
> checking for sin in -lm... yes
> /octmgw32/octave/octave-3.3.x/configure: line 9276: syntax error near 
> unexpected token `,'
> /octmgw32/octave/octave-3.3.x/configure: line 9276: `    m4_ifnblank(, 
> AC_LANG_PUSH())'
> 
> ?
> 
> $ autoconf --version
> autoconf (GNU Autoconf) 2.61
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software.  You may redistribute copies of it under the 
> terms of
> the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Written by David J. MacKenzie and Akim Demaille.
> 
> $ autoheader --version
> autoheader (GNU Autoconf) 2.61
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software.  You may redistribute copies of it under the 
> terms of
> the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Written by Roland McGrath and Akim Demaille.
> 
> benjamin
> 

I also tried with updated versions of msys and tools, but the same 
errors occur.

$ autoheader --version
autoheader (GNU Autoconf) 2.63
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later
<http://gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Roland McGrath and Akim Demaille.

$ automake --version
automake (GNU automake) 1.11
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later 
<http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey <tromey at redhat.com>
        and Alexandre Duret-Lutz <adl at gnu.org>.

benjamin

From Thomas.Treichl at gmx.net  Fri Aug 14 14:17:48 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Fri, 14 Aug 2009 21:17:48 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A85B71C.4070605@gmx.net>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>	<19077.28862.827842.41629@segfault.lan>	<4A85ACD3.2000305@gmx.net>
	<4A85B71C.4070605@gmx.net>
Message-ID: <4A85B85C.2070109@gmx.net>

Benjamin Lindner schrieb:
> I also tried with updated versions of msys and tools, but the same 
> errors occur.
> 
> $ autoheader --version
> autoheader (GNU Autoconf) 2.63
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv2+: GNU GPL version 2 or later
> <http://gnu.org/licenses/old-licenses/gpl-2.0.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Written by Roland McGrath and Akim Demaille.
> 
> $ automake --version
> automake (GNU automake) 1.11
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv2+: GNU GPL version 2 or later 
> <http://gnu.org/licenses/gpl-2.0.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Written by Tom Tromey <tromey at redhat.com>
>        and Alexandre Duret-Lutz <adl at gnu.org>.
> 
> benjamin

The problems do come somewhere from inside of "m4_ifnblank", "m4_ifblank" and 
"m4_toupper" in file aclocal.m4 and macro OCTAVE_CHECK_LIBRARY. It seems that 
these functions don't like any of AC_DEFINE, AC_LANG_POP etc. as an argument, 
but I don't get it corrected...

Best regards
   Thomas

From lindnerben at gmx.net  Fri Aug 14 14:23:32 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Fri, 14 Aug 2009 21:23:32 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A85B85C.2070109@gmx.net>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>	<19077.28862.827842.41629@segfault.lan>	<4A85ACD3.2000305@gmx.net>
	<4A85B71C.4070605@gmx.net> <4A85B85C.2070109@gmx.net>
Message-ID: <4A85B9B4.9070704@gmx.net>

Thomas Treichl wrote:
> Benjamin Lindner schrieb:
>> I also tried with updated versions of msys and tools, but the same 
>> errors occur.
>>
>> $ autoheader --version
>> autoheader (GNU Autoconf) 2.63
>> Copyright (C) 2008 Free Software Foundation, Inc.
>> License GPLv2+: GNU GPL version 2 or later
>> <http://gnu.org/licenses/old-licenses/gpl-2.0.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>>
>> Written by Roland McGrath and Akim Demaille.
>>
>> $ automake --version
>> automake (GNU automake) 1.11
>> Copyright (C) 2009 Free Software Foundation, Inc.
>> License GPLv2+: GNU GPL version 2 or later 
>> <http://gnu.org/licenses/gpl-2.0.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>>
>> Written by Tom Tromey <tromey at redhat.com>
>>        and Alexandre Duret-Lutz <adl at gnu.org>.
>>
>> benjamin
> 
> The problems do come somewhere from inside of "m4_ifnblank", 
> "m4_ifblank" and "m4_toupper" in file aclocal.m4 and macro 
> OCTAVE_CHECK_LIBRARY. It seems that these functions don't like any of 
> AC_DEFINE, AC_LANG_POP etc. as an argument, but I don't get it corrected...
> 

As a wild guess, can it have something to do with the version of perl or 
m4 used?

$ perl --version
This is perl, v5.6.1 built for msys
$ m4 --version
GNU M4 1.4.7

benjamin

From Thomas.Treichl at gmx.net  Fri Aug 14 14:31:14 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Fri, 14 Aug 2009 21:31:14 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A85B9B4.9070704@gmx.net>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>	<19077.28862.827842.41629@segfault.lan>	<4A85ACD3.2000305@gmx.net>
	<4A85B71C.4070605@gmx.net> <4A85B85C.2070109@gmx.net>
	<4A85B9B4.9070704@gmx.net>
Message-ID: <4A85BB82.8080109@gmx.net>

Benjamin Lindner schrieb:
> Thomas Treichl wrote:
>> Benjamin Lindner schrieb:
>>> I also tried with updated versions of msys and tools, but the same 
>>> errors occur.
>>>
>>> $ autoheader --version
>>> autoheader (GNU Autoconf) 2.63
>>> Copyright (C) 2008 Free Software Foundation, Inc.
>>> License GPLv2+: GNU GPL version 2 or later
>>> <http://gnu.org/licenses/old-licenses/gpl-2.0.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>>
>>> Written by Roland McGrath and Akim Demaille.
>>>
>>> $ automake --version
>>> automake (GNU automake) 1.11
>>> Copyright (C) 2009 Free Software Foundation, Inc.
>>> License GPLv2+: GNU GPL version 2 or later 
>>> <http://gnu.org/licenses/gpl-2.0.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>>
>>> Written by Tom Tromey <tromey at redhat.com>
>>>        and Alexandre Duret-Lutz <adl at gnu.org>.
>>>
>>> benjamin
>>
>> The problems do come somewhere from inside of "m4_ifnblank", 
>> "m4_ifblank" and "m4_toupper" in file aclocal.m4 and macro 
>> OCTAVE_CHECK_LIBRARY. It seems that these functions don't like any of 
>> AC_DEFINE, AC_LANG_POP etc. as an argument, but I don't get it 
>> corrected...
>>
> 
> As a wild guess, can it have something to do with the version of perl or 
> m4 used?
> 
> $ perl --version
> This is perl, v5.6.1 built for msys
> $ m4 --version
> GNU M4 1.4.7
> 
> benjamin
> 

I don't know Benjamin, mine are not very much newer:

MacMini:~/Development/octave Me$ perl --version
This is perl, v5.8.6 built for darwin-thread-multi-2level
(with 5 registered patches, see perl -V for more detail)

Copyright 1987-2004, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'.  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

MacMini:~/Development/octave Me$ m4 --version
m4 (GNU M4) 1.4.11
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Rene' Seindal.

Anybody seeing those configure problems on Linux?

From lindnerben at gmx.net  Fri Aug 14 14:42:05 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Fri, 14 Aug 2009 21:42:05 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A85B9B4.9070704@gmx.net>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>	<19077.28862.827842.41629@segfault.lan>	<4A85ACD3.2000305@gmx.net>	<4A85B71C.4070605@gmx.net>
	<4A85B85C.2070109@gmx.net> <4A85B9B4.9070704@gmx.net>
Message-ID: <4A85BE0D.5010608@gmx.net>

Benjamin Lindner wrote:
> Thomas Treichl wrote:
>> Benjamin Lindner schrieb:
>>> I also tried with updated versions of msys and tools, but the same 
>>> errors occur.
>>>
>>> $ autoheader --version
>>> autoheader (GNU Autoconf) 2.63
>>> Copyright (C) 2008 Free Software Foundation, Inc.
>>> License GPLv2+: GNU GPL version 2 or later
>>> <http://gnu.org/licenses/old-licenses/gpl-2.0.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>>
>>> Written by Roland McGrath and Akim Demaille.
>>>
>>> $ automake --version
>>> automake (GNU automake) 1.11
>>> Copyright (C) 2009 Free Software Foundation, Inc.
>>> License GPLv2+: GNU GPL version 2 or later 
>>> <http://gnu.org/licenses/gpl-2.0.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>>
>>> Written by Tom Tromey <tromey at redhat.com>
>>>        and Alexandre Duret-Lutz <adl at gnu.org>.
>>>
>>> benjamin
>>
>> The problems do come somewhere from inside of "m4_ifnblank", 
>> "m4_ifblank" and "m4_toupper" in file aclocal.m4 and macro 
>> OCTAVE_CHECK_LIBRARY. It seems that these functions don't like any of 
>> AC_DEFINE, AC_LANG_POP etc. as an argument, but I don't get it 
>> corrected...
>>
> 
> As a wild guess, can it have something to do with the version of perl or 
> m4 used?
> 
> $ perl --version
> This is perl, v5.6.1 built for msys
> $ m4 --version
> GNU M4 1.4.7
> 

Too wild a guess,
the macro m4_ifnblank has been introduced in version 2.64.
there is only 2.63 available on msys, so no wonder it fails, sigh

benjamin



From Thomas.Treichl at gmx.net  Fri Aug 14 14:53:01 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Fri, 14 Aug 2009 21:53:01 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A85BE0D.5010608@gmx.net>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>	<19077.28862.827842.41629@segfault.lan>	<4A85ACD3.2000305@gmx.net>	<4A85B71C.4070605@gmx.net>
	<4A85B85C.2070109@gmx.net> <4A85B9B4.9070704@gmx.net>
	<4A85BE0D.5010608@gmx.net>
Message-ID: <4A85C09D.3010107@gmx.net>

Benjamin Lindner schrieb:
> Benjamin Lindner wrote:
>> Thomas Treichl wrote:
>>> Benjamin Lindner schrieb:
>>>> I also tried with updated versions of msys and tools, but the same 
>>>> errors occur.
>>>>
>>>> $ autoheader --version
>>>> autoheader (GNU Autoconf) 2.63
>>>> Copyright (C) 2008 Free Software Foundation, Inc.
>>>> License GPLv2+: GNU GPL version 2 or later
>>>> <http://gnu.org/licenses/old-licenses/gpl-2.0.html>
>>>> This is free software: you are free to change and redistribute it.
>>>> There is NO WARRANTY, to the extent permitted by law.
>>>>
>>>> Written by Roland McGrath and Akim Demaille.
>>>>
>>>> $ automake --version
>>>> automake (GNU automake) 1.11
>>>> Copyright (C) 2009 Free Software Foundation, Inc.
>>>> License GPLv2+: GNU GPL version 2 or later 
>>>> <http://gnu.org/licenses/gpl-2.0.html>
>>>> This is free software: you are free to change and redistribute it.
>>>> There is NO WARRANTY, to the extent permitted by law.
>>>>
>>>> Written by Tom Tromey <tromey at redhat.com>
>>>>        and Alexandre Duret-Lutz <adl at gnu.org>.
>>>>
>>>> benjamin
>>>
>>> The problems do come somewhere from inside of "m4_ifnblank", 
>>> "m4_ifblank" and "m4_toupper" in file aclocal.m4 and macro 
>>> OCTAVE_CHECK_LIBRARY. It seems that these functions don't like any of 
>>> AC_DEFINE, AC_LANG_POP etc. as an argument, but I don't get it 
>>> corrected...
>>>
>>
>> As a wild guess, can it have something to do with the version of perl 
>> or m4 used?
>>
>> $ perl --version
>> This is perl, v5.6.1 built for msys
>> $ m4 --version
>> GNU M4 1.4.7
>>
> 
> Too wild a guess,
> the macro m4_ifnblank has been introduced in version 2.64.
> there is only 2.63 available on msys, so no wonder it fails, sigh
> 
> benjamin

Ha, true ;o)
This fixes all the ./autogen.sh problems. There is no error left anymore,
so AC_PREREQ(2.60) of configure.in should be changed to AC_PREREQ(2.64).

Best regards

   Thomas

From storrsjm at email.uc.edu  Fri Aug 14 16:05:01 2009
From: storrsjm at email.uc.edu (Judd Storrs)
Date: Fri, 14 Aug 2009 17:05:01 -0400
Subject: FYI: subasgn argument optimization
In-Reply-To: <69d8d540908141005gfa669dkbe6475992effcaf4@mail.gmail.com>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
	<69d8d540908130746k948365dn9cfc8daf80901e78@mail.gmail.com>
	<19077.34069.745516.227226@segfault.lan>
	<69d8d540908141005gfa669dkbe6475992effcaf4@mail.gmail.com>
Message-ID: <a0daad600908141405y373fd65ar87c03394b1fe252d@mail.gmail.com>

On Fri, Aug 14, 2009 at 1:05 PM, Jaroslav Hajek <highegg at gmail.com> wrote:

> OK, here are some:
>
> * A class is constructed from a struct. Can the struct be
> multidimensional? (if the answer is no, then there is no need to read
> further).


Apparently, yes. But, it seems to come out as an array of objects.

@foo/foo.m:
function obj = foo()
    obj(10).data = 1 ;
    obj = class(obj,'foo') ;
end

Then in matlab (I edited the whitespace):

>> a = foo()
a = foo object: 1-by-10
>> b = a(1)
b = foo object: 1-by-1
>>

Now I created

@bar/bar.m
function obj = foo()
    obj.data = 1 ;

    obj = class(obj,'foo') ;
end


>> b = bar()
??? Error using ==> class
Size of struct array being made into an object and the parent objects must
be consistent.

Error in ==> bar.bar at 4
    obj = class(obj,'bar',parent) ;

>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090814/f40ea677/attachment.html 

From storrsjm at email.uc.edu  Fri Aug 14 16:06:55 2009
From: storrsjm at email.uc.edu (Judd Storrs)
Date: Fri, 14 Aug 2009 17:06:55 -0400
Subject: FYI: subasgn argument optimization
In-Reply-To: <a0daad600908141405y373fd65ar87c03394b1fe252d@mail.gmail.com>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
	<69d8d540908130746k948365dn9cfc8daf80901e78@mail.gmail.com>
	<19077.34069.745516.227226@segfault.lan>
	<69d8d540908141005gfa669dkbe6475992effcaf4@mail.gmail.com>
	<a0daad600908141405y373fd65ar87c03394b1fe252d@mail.gmail.com>
Message-ID: <a0daad600908141406t65d7d400i84af60b61cd315b9@mail.gmail.com>

On Fri, Aug 14, 2009 at 5:05 PM, Judd Storrs <storrsjm at email.uc.edu> wrote:

> @bar/bar.m
> function obj = foo()
>     obj.data = 1 ;
>
>     obj = class(obj,'foo') ;
> end
>

Sorry, bad edit

@bar/bar.m:
function obj = bar()
    obj.data = 1 ;
    parent = foo() ;
    obj = class(obj,'bar',parent) ;
end


--judd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090814/bb995e1d/attachment.html 

From storrsjm at email.uc.edu  Fri Aug 14 16:07:44 2009
From: storrsjm at email.uc.edu (Judd Storrs)
Date: Fri, 14 Aug 2009 17:07:44 -0400
Subject: FYI: subasgn argument optimization
In-Reply-To: <a0daad600908141406t65d7d400i84af60b61cd315b9@mail.gmail.com>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
	<69d8d540908130746k948365dn9cfc8daf80901e78@mail.gmail.com>
	<19077.34069.745516.227226@segfault.lan>
	<69d8d540908141005gfa669dkbe6475992effcaf4@mail.gmail.com>
	<a0daad600908141405y373fd65ar87c03394b1fe252d@mail.gmail.com>
	<a0daad600908141406t65d7d400i84af60b61cd315b9@mail.gmail.com>
Message-ID: <a0daad600908141407t4261109ar7be02980dda5a73e@mail.gmail.com>

On Fri, Aug 14, 2009 at 5:06 PM, Judd Storrs <storrsjm at email.uc.edu> wrote:

> On Fri, Aug 14, 2009 at 5:05 PM, Judd Storrs <storrsjm at email.uc.edu>wrote:
>
>> @bar/bar.m
>> function obj = foo()
>>     obj.data = 1 ;
>>
>>     obj = class(obj,'foo') ;
>> end
>>
>
Grrr.

function obj = bar()
    obj.data = 1 ;
    parent = foo() ;
    obj = class(obj,'bar',parent) ;
end
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090814/e2a2f262/attachment-0001.html 

From michael.goffioul at gmail.com  Fri Aug 14 17:02:38 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Fri, 14 Aug 2009 23:02:38 +0100
Subject: autoconf-2.64 required?
Message-ID: <128f38bd0908141502med3723ev41c8e6cd25ddebd1@mail.gmail.com>

Hi,

it seems that octave now requires autoconf-2.64 and not 2.60 as mentioned
in the AC_PREREQ of configure.in. Since change 0ce82753dd72, my
autoconf-2.61 is unable to process configure.in and fails with:

configure.in:40: error: possibly undefined macro: AC_DEFINE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.in:63: error: possibly undefined macro: AS_HELP_STRING
configure.in:617: error: possibly undefined macro: AC_LANG_PUSH
configure.in:665: error: possibly undefined macro: AC_LANG_POP
configure:1511: error: possibly undefined macro: m4_ifblank
configure:9276: error: possibly undefined macro: m4_ifnblank
configure:9479: error: possibly undefined macro: m4_toupper

Can anybody confirm this?

Michael.

From bpabbott at mac.com  Fri Aug 14 18:43:42 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Fri, 14 Aug 2009 19:43:42 -0400
Subject: backend listeners (was: Requesting an Octave mentor)
In-Reply-To: <9543b3a40908140811i7860ef09lac66c157fb4232e6@mail.gmail.com>
References: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
	<69d8d540908132230y1e7c7d7cse07480b8012dba3b@mail.gmail.com>
	<19076.63762.997506.547880@segfault.lan>
	<9543b3a40908140811i7860ef09lac66c157fb4232e6@mail.gmail.com>
Message-ID: <3A6AF806-1691-4B33-BFE2-34D5089713F4@mac.com>

On Aug 14, 2009, at 11:11 AM, Jordi Guti?rrez Hermos wrote:

> Hopefully Ben and Robert above can help me get started.
>
> - Jordi G. H.

Ok, this will be a bit of a core-dump, but  ...

Although I thought it belonged at a lower level, last year, I worked  
on an m-file implementation of graphics property listeners. My thought  
was that it could be used it as a template in a latter attempt to  
implement the functionality in c++.

As my c++ skills are limited to those of a unconvincing mimic, I'm  
grateful to you and/or anyone who wants to take this on.

I'm going to trust my memory, which isn't very reliable ... in any  
event, here goes.

The listeners I was referring to react to changes in some property and  
modify the value of one or more other properties, which generally will  
trigger another listener ... and down the rabbit hole we go ;-)

If we ignore changes to the units of the property values, the  
listeners which would be most beneficial to the backends (imo) are ...

text.{fontsize, fontname, string, horizontalalignment,  
verticalalignment} -> text.{extent}
text.{extent, position} -> axes.{tightinset}
axes.{tightinset, activepositionproperty, position, outerposition} ->  
axes.{position, outerposition}
figure.papersize -> figure.papertype
figure.papertype -> figure.papersize

(this list totally ignores 3D effects)

However, I think listeners reacting to changes in units are more  
important. Implementing these listeners doesn't require extensive  
knowledge to get started, but you'll learn a lot that will be needed  
to implement the listeners above.

Listeners reacting the changes in units are ...

text.units -> text.{position, extent}
text.fontunits -> text.fontsize
axes.units -> axes.{position, outerposition, tightinset}
figure.units -> figure.position
figure.paperunits -> figure.{paperposition, papersize}
root.units -> figure.screensize

A single routine can (should?) handles all conversions. The units to  
be supported are {inches, centimeters, points, pixels, characters,  
normalized, data}. For "characters" the conversion is 5.6x11.2 points/ 
character.

To relate pixels to physical units, such as points, inches,  
centimeters, & characters, the root property screenpixelsperinch may  
be used. Note that a change to "screenpixelsperinch" results in a  
massive domino effect.

Returning to where I began, the m-files I wrote are attached. I've  
included tests which passed, and although they did in January '09,  
they are not presently passing. As time permits (and if it would  
help), I can try to debug them.

For details on specific properties, please ask. You can also get quite  
a bit info by googling "matlab <property-name>".

Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: update_property.m
Type: application/octet-stream
Size: 21666 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090814/f5069819/attachment-0002.obj 
-------------- next part --------------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: set_listeners.m
Type: application/octet-stream
Size: 2119 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090814/f5069819/attachment-0003.obj 
-------------- next part --------------






From xavier.delacour at gmail.com  Fri Aug 14 20:30:50 2009
From: xavier.delacour at gmail.com (Xavier Delacour)
Date: Fri, 14 Aug 2009 18:30:50 -0700
Subject: autoconf-2.64 required?
In-Reply-To: <128f38bd0908141502med3723ev41c8e6cd25ddebd1@mail.gmail.com>
References: <128f38bd0908141502med3723ev41c8e6cd25ddebd1@mail.gmail.com>
Message-ID: <67abaf50908141830y6e3b3fc6k3f88f06345b37f61@mail.gmail.com>

On Fri, Aug 14, 2009 at 3:02 PM, Michael
Goffioul<michael.goffioul at gmail.com> wrote:
> Hi,
>
> it seems that octave now requires autoconf-2.64 and not 2.60 as mentioned
> in the AC_PREREQ of configure.in. Since change 0ce82753dd72, my
> autoconf-2.61 is unable to process configure.in and fails with:
>
> configure.in:40: error: possibly undefined macro: AC_DEFINE
> ? ? ?If this token and others are legitimate, please use m4_pattern_allow.
> ? ? ?See the Autoconf documentation.
> configure.in:63: error: possibly undefined macro: AS_HELP_STRING
> configure.in:617: error: possibly undefined macro: AC_LANG_PUSH
> configure.in:665: error: possibly undefined macro: AC_LANG_POP
> configure:1511: error: possibly undefined macro: m4_ifblank
> configure:9276: error: possibly undefined macro: m4_ifnblank
> configure:9479: error: possibly undefined macro: m4_toupper
>
> Can anybody confirm this?

Yes, same happens for me w/ fresh checkout. And it's rather
unfortunate since autoconf 2.61 is what comes stock with Ubuntu 8.10.

Xavier

>
> Michael.
>


From storrsjm at email.uc.edu  Fri Aug 14 22:09:56 2009
From: storrsjm at email.uc.edu (Judd Storrs)
Date: Fri, 14 Aug 2009 23:09:56 -0400
Subject: autoconf-2.64 required?
In-Reply-To: <67abaf50908141830y6e3b3fc6k3f88f06345b37f61@mail.gmail.com>
References: <128f38bd0908141502med3723ev41c8e6cd25ddebd1@mail.gmail.com>
	<67abaf50908141830y6e3b3fc6k3f88f06345b37f61@mail.gmail.com>
Message-ID: <a0daad600908142009h53cf62awf10332a70e294f3d@mail.gmail.com>

I can confirm this also happens with 2.63 on Ubuntu 9.10

$ autoconf --version
autoconf (GNU Autoconf) 2.63


--judd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090814/9ddf7adb/attachment.html 

From highegg at gmail.com  Sat Aug 15 00:07:15 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Sat, 15 Aug 2009 07:07:15 +0200
Subject: autoconf-2.64 required?
In-Reply-To: <128f38bd0908141502med3723ev41c8e6cd25ddebd1@mail.gmail.com>
References: <128f38bd0908141502med3723ev41c8e6cd25ddebd1@mail.gmail.com>
Message-ID: <69d8d540908142207o49aba50au92eb8d5100c75574@mail.gmail.com>

On Sat, Aug 15, 2009 at 12:02 AM, Michael
Goffioul<michael.goffioul at gmail.com> wrote:
> Hi,
>
> it seems that octave now requires autoconf-2.64 and not 2.60 as mentioned
> in the AC_PREREQ of configure.in. Since change 0ce82753dd72, my
> autoconf-2.61 is unable to process configure.in and fails with:
>
> configure.in:40: error: possibly undefined macro: AC_DEFINE
> ? ? ?If this token and others are legitimate, please use m4_pattern_allow.
> ? ? ?See the Autoconf documentation.
> configure.in:63: error: possibly undefined macro: AS_HELP_STRING
> configure.in:617: error: possibly undefined macro: AC_LANG_PUSH
> configure.in:665: error: possibly undefined macro: AC_LANG_POP
> configure:1511: error: possibly undefined macro: m4_ifblank
> configure:9276: error: possibly undefined macro: m4_ifnblank
> configure:9479: error: possibly undefined macro: m4_toupper
>
> Can anybody confirm this?
>
> Michael.
>

Autoconf 2.64 is really very new; though by the time Octave 3.4 will
be released, it may already be widespread.
However, in this case apparently it's just m4_ifblank and m4_ifnblank
missing, so an easy remedy is to steal them out from autoconf 2.64 and
define them ourselves if they're not there:
http://hg.savannah.gnu.org/hgweb/octave/rev/691545147aca

this enables use of autoconf 2.63 for me.

cheers

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


From highegg at gmail.com  Sat Aug 15 02:04:02 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Sat, 15 Aug 2009 09:04:02 +0200
Subject: FYI: subasgn argument optimization
In-Reply-To: <a0daad600908141405y373fd65ar87c03394b1fe252d@mail.gmail.com>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
	<69d8d540908130746k948365dn9cfc8daf80901e78@mail.gmail.com>
	<19077.34069.745516.227226@segfault.lan>
	<69d8d540908141005gfa669dkbe6475992effcaf4@mail.gmail.com>
	<a0daad600908141405y373fd65ar87c03394b1fe252d@mail.gmail.com>
Message-ID: <69d8d540908150004re068133w9978bf5024606441@mail.gmail.com>

On Fri, Aug 14, 2009 at 11:05 PM, Judd Storrs<storrsjm at email.uc.edu> wrote:
> On Fri, Aug 14, 2009 at 1:05 PM, Jaroslav Hajek <highegg at gmail.com> wrote:
>>
>> OK, here are some:
>>
>> * A class is constructed from a struct. Can the struct be
>> multidimensional? (if the answer is no, then there is no need to read
>> further).
>
> Apparently, yes. But, it seems to come out as an array of objects.
>
> @foo/foo.m:
> function obj = foo()
> ??? obj(10).data = 1 ;
> ??? obj = class(obj,'foo') ;
> end
>
> Then in matlab (I edited the whitespace):
>
>>> a = foo()
> a = foo object: 1-by-10
>>> b = a(1)
> b = foo object: 1-by-1
>>>
>
> Now I created
>
> @bar/bar.m
> function obj = foo()
> ??? obj.data = 1 ;
>
> ??? obj = class(obj,'foo') ;
> end
>
>
>>> b = bar()
> ??? Error using ==> class
> Size of struct array being made into an object and the parent objects must
> be consistent.
>
> Error in ==> bar.bar at 4
> ??? obj = class(obj,'bar',parent) ;
>
>>>
>

That just adds more confusion. SO, if I want to do
class (obj, 'bar', parent), and obj is m-by-n, what dimensions should
parent be? m-by-n.
And what does obj.parent return, then?

Also, does Matlab really auto-forward the field references to parent
classes? I can't find that anywhere in the Matlab docs. For instance,
if a class bar inherits from foo, which has a field xx, does this.xx
really work inside bar methods, or must one do this.foo.xx?

Personally, I really doubt that the old model is much used for
inheritance, so I'd vote to keep the support at minimal level. The
auto-forwarding of the fields is what complicates the implementation
the most.

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


From lindnerben at gmx.net  Sat Aug 15 03:08:28 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Sat, 15 Aug 2009 10:08:28 +0200
Subject: autoconf-2.64 required?
In-Reply-To: <69d8d540908142207o49aba50au92eb8d5100c75574@mail.gmail.com>
References: <128f38bd0908141502med3723ev41c8e6cd25ddebd1@mail.gmail.com>
	<69d8d540908142207o49aba50au92eb8d5100c75574@mail.gmail.com>
Message-ID: <4A866CFC.2050104@gmx.net>

Jaroslav Hajek wrote:
> On Sat, Aug 15, 2009 at 12:02 AM, Michael
> Goffioul<michael.goffioul at gmail.com> wrote:
>> Hi,
>>
>> it seems that octave now requires autoconf-2.64 and not 2.60 as mentioned
>> in the AC_PREREQ of configure.in. Since change 0ce82753dd72, my
>> autoconf-2.61 is unable to process configure.in and fails with:
>>
>> configure.in:40: error: possibly undefined macro: AC_DEFINE
>>      If this token and others are legitimate, please use m4_pattern_allow.
>>      See the Autoconf documentation.
>> configure.in:63: error: possibly undefined macro: AS_HELP_STRING
>> configure.in:617: error: possibly undefined macro: AC_LANG_PUSH
>> configure.in:665: error: possibly undefined macro: AC_LANG_POP
>> configure:1511: error: possibly undefined macro: m4_ifblank
>> configure:9276: error: possibly undefined macro: m4_ifnblank
>> configure:9479: error: possibly undefined macro: m4_toupper
>>
>> Can anybody confirm this?
>>
>> Michael.
>>
> 
> Autoconf 2.64 is really very new; though by the time Octave 3.4 will
> be released, it may already be widespread.
> However, in this case apparently it's just m4_ifblank and m4_ifnblank
> missing, so an easy remedy is to steal them out from autoconf 2.64 and
> define them ourselves if they're not there:
> http://hg.savannah.gnu.org/hgweb/octave/rev/691545147aca
> 
> this enables use of autoconf 2.63 for me.
> 
> cheers
> 

Great!

With this changeset, autoconf & configure run on msys using autoconf 2.61

thanks
benjamin

From michael.goffioul at gmail.com  Sat Aug 15 03:57:23 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Sat, 15 Aug 2009 09:57:23 +0100
Subject: FFTW wrong AC_DEFINE macro
Message-ID: <128f38bd0908150157s320abed8qabc96ba56e9a0bca@mail.gmail.com>

Hi,

It seems the code now uses HAVE_FFTW preprocessor macro,
but the configure script still defines HAVE_FFTW3. So the FFTW
code is not used (leading to undefined symbols at link time for
liboctave). I guess it's related to John's recent changes.

Bye,

Michael.

From Thomas.Treichl at gmx.net  Sat Aug 15 04:08:54 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Sat, 15 Aug 2009 11:08:54 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <19077.28862.827842.41629@segfault.lan>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>
	<19077.28862.827842.41629@segfault.lan>
Message-ID: <4A867B26.3030508@gmx.net>

John W. Eaton schrieb:
> It would be helpful if people building Octave on Windows and OS X
> systems could configure and build the latest Octave sources on and
> send a list of symbols that are unresolved when creating the libcruft,
> liboctave, liboctinterp shared libraries, when linking the Octave
> executable file, and when building the .oct files.

Here are the results for OS X (currently I cannot tell you anything about the 
CURL and GLPK dependencies - these libs are not found by ./configure at the 
moment - seems because of missing -lz in the test procedure):

   libcruft.dylib, liboctave.dylib: no unresolved symbols

   liboctinterp.dylib: (cf. attached file liboctave_symbols.txt.gz)
     for manual compilation I needed to add

     -L../libcruft -lcruft -lreadline -lfftw3 -lfftw3f -lexpat

   octave: (cf. attached file liboctave_symbols.txt.gz)
     for manual compilation I needed to add

     -lz -lhdf5 -lreadline -lfreetype -lfontconfig -lfftw3 -lfftw3f -lexpat

   dld files: (cf. attached file liboctave_symbols.txt.gz)

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: liboctinterp_symbols.txt.gz
Type: application/x-gzip
Size: 1523 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090815/983928e1/attachment-0003.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: octave_symbols.txt.gz
Type: application/x-gzip
Size: 1382 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090815/983928e1/attachment-0004.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dldfiles_symbols.txt.gz
Type: application/x-gzip
Size: 31535 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090815/983928e1/attachment-0005.bin 

From lindnerben at gmx.net  Sat Aug 15 04:42:47 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Sat, 15 Aug 2009 11:42:47 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <19077.28862.827842.41629@segfault.lan>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>
	<19077.28862.827842.41629@segfault.lan>
Message-ID: <4A868317.10203@gmx.net>

John W. Eaton wrote:
> On 13-Aug-2009, Benjamin Lindner wrote:
> 
> | Benjamin Lindner wrote:
> | > Benjamin Lindner wrote:
> | >> Hello,
> | >>
> | >> I just tried to build the recent development tip on mingw32 and 
> | >> building fails at linking liboctave with a phletora of missing symbols 
> | >> from the lapack library.
> | >>
> | >> looking at the linker command I see that indeed there is no -llapack 
> | >> present.
> | >>
> | >> Digging the changelog I find that at revision 9490:3aeb7d881578
> | >> $(BLAS_LIBS) has been removed from LINK_DEPS in liboctave/makefile.in
> | >>
> | >> I guess it should still be there, since arpack, qrupdate and quite 
> | >> some octave code depends on it.
> | >>
> | > 
> | > I see that there is already a thread covering this topic on the bugs 
> | > list. Sorry for the double-post.
> | > 
> | > Hovever, liboctave directly uses functinos from lapack, and uses the 
> | > qrupdate and qrpack library which both depend on lapack, so lapack 
> | > *should* be listed in LINK_DEPS.
> | > 
> | 
> | The attached changeset fixes the linker issues for mingw32 platform by 
> | adding $(BLAS_LIBS) in liboctave's link depencendies.
> 
> I made this change.
> 
> It would be helpful if people building Octave on Windows and OS X
> systems could configure and build the latest Octave sources on and
> send a list of symbols that are unresolved when creating the libcruft,
> liboctave, liboctinterp shared libraries, when linking the Octave
> executable file, and when building the .oct files.

Ok, with Jaroslavs changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/691545147aca
configure completes.

However the build immediately fails at octave-bug.c with

octave-bug.cc: In function 'int main(int, char**)':
octave-bug.cc:102: error: expected primary-expression before '%' token
octave-bug.cc:102: error: 'OCTAVE_CONF_FFTW_LIBS' was not declared in
this scope
octave-bug.cc:102: error: expected primary-expression before ';' token


Looking at the source of octave-bug.c at line 102 I find

    vars["FFTW_LIBS"] = %OCTAVE_CONF_FFTW_LIBS%;

This looks like a missing replacement of conigure-time settings.
The same goes for mkoctfile.cc.in

BTW the shell script versions of octave-bug and mkoctfile will also need
patching.


--- a/mkoctfile.cc.in   Sat Aug 15 10:02:51 2009 +0200
+++ b/mkoctfile.cc.in   Sat Aug 15 10:17:55 2009 +0200
@@ -224,7 +224,7 @@
     vars["READLINE_LIBS"] = "-lreadline";
     vars["LIBCRUFT"] = "-lcruft";
     vars["BLAS_LIBS"] = get_variable ("BLAS_LIBS", 
%OCTAVE_CONF_BLAS_LIBS%);
-  vars["FFTW_LIBS"] = get_variable ("FFTW_LIBS", %OCTAVE_CONF_FFTW_LIBS%);
+  vars["FFTW_LIBS"] = get_variable ("FFTW_LIBS", %OCTAVE_CONF_FFTW3_LIBS%);
     vars["LIBS"] = get_variable ("LIBS", %OCTAVE_CONF_LIBS%);
     vars["CXXLIBS"] = get_variable ("CXXLIBS", %OCTAVE_CONF_CXXLIBS%);
     vars["FLIBS"] = get_variable ("FLIBS", %OCTAVE_CONF_FLIBS%);
diff -r 3f6b1f9238d3 octave-bug.cc.in
--- a/octave-bug.cc.in  Sat Aug 15 10:02:51 2009 +0200
+++ b/octave-bug.cc.in  Sat Aug 15 10:17:55 2009 +0200
@@ -99,7 +99,7 @@
     vars["RLD_FLAG"] = %OCTAVE_CONF_RLD_FLAG%;
     vars["LIBS"] = %OCTAVE_CONF_LIBS%;
     vars["BLAS_LIBS"] = %OCTAVE_CONF_BLAS_LIBS%;
-  vars["FFTW_LIBS"] = %OCTAVE_CONF_FFTW_LIBS%;
+  vars["FFTW_LIBS"] = %OCTAVE_CONF_FFTW3_LIBS%;
     vars["LEXLIB"] = %OCTAVE_CONF_LEXLIB%;
     vars["LIBGLOB"] = %OCTAVE_CONF_LIBGLOB%;
     vars["DEFS"] = %OCTAVE_CONF_DEFS%;

However, I see that many new configure-time variables have been
introduced, and thus octave-bug and mkoctfile and their .c counterparts
need to be updated.

This is I guess best done when the configure changes have settled.



Now for the undefined reference linker errors:
Linking libcruft.dll and liboctave.dll succeed.

Linking liboctinterp.dll fails with the missing symbols attached: (I
omitted double errors in the same object file, otherwise the list is
*really* long and does not contain additional information):

The first group stems from $(LIBCRUFT) missing as link dependency.

The second group stems from missing
    -lgdi32 (GetDeviceCaps)
    -liberty (mkstemps)
The first is the windows system GDI library and the second is the
mingw/gcc support library.
Both are added to $LIBS during configure stage for the mingw platform

The third group stems from $(FLIBS) missing as link dependency.

To link successfully I have to do

OCTINTERP_LINK_DEPS = $(RLD_FLAG) -L../liboctave $(LIBOCTAVE)
-L../libcruft $(LIBCRUFT) \
    $(HDF5_LIBS) $(ZLIB_LIBS) $(X11_LIBS) $(OPENGL_LIBS) $(CARBON_LIBS) \
    $(LIBS) $(FLIBS)




Now for DLD-functions:

Here the undefined reference list is even longer. I attached the full
output.

I need to add $(LIBOCTAVE) to OCT_LINK_DEPS, i.e.

OCT_LINK_DEPS = $(RLD_FLAG) -L../liboctave $(LIBOCTAVE) -L. $(LIBOCTINTERP)

then the link errors reduce to (exemplary)

cellfun.o:cellfun.cc:(.text+0x2d95): undefined reference to
`octave_signal_caught'
cellfun.o:cellfun.cc:(.text+0x2da4): undefined reference to
`octave_handle_signal'

which indicates again that $(LIBCRUFT) is missing.
Changing to

OCT_LINK_DEPS = $(RLD_FLAG) -L../libcruft $(LIBCRUFT) -L../liboctave
$(LIBOCTAVE) -L. $(LIBOCTINTERP)

fixes it.



Then I get the errors attached in dld-link-errors-2.txt:
I need the following changes for successful linking

chol.oct: OCT_LINK_DEPS += $(QRUPDATE_LDFLAGS) $(QRUPDATE_LIBS)
$(CHOLMOD_LIBS)
(add $(CHOLMOD_LIBS))

eigs.oct: OCT_LINK_DEPS += $(ARPACK_LDFLAGS) $(ARPACK_LIBS) 
$(CHOLMOD_LIBS) $(BLAS_LIBS)
(add $(CHOLMOD_LIBS) $(BLAS_LIBS))


ccolamd.oct : OCT_LINK_DEPS += $(CCOLAMD_LIBS)

qz.oct : OCT_LINK_DEPS += $(BLAS_LIBS)

symbfact.oct : OCT_LINK_DEPS += $(CHOLMOD_LIBS)


benjamin



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: liboctinterp-link-errors.txt
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090815/91aaedfa/attachment-0003.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dld-link-errors-2.txt
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090815/91aaedfa/attachment-0004.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dld-link-errors.txt
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090815/91aaedfa/attachment-0005.txt 

From lindnerben at gmx.net  Sat Aug 15 04:49:57 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Sat, 15 Aug 2009 11:49:57 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A868317.10203@gmx.net>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>	<19077.28862.827842.41629@segfault.lan>
	<4A868317.10203@gmx.net>
Message-ID: <4A8684C5.8070302@gmx.net>

Benjamin Lindner wrote:
> 
> Linking liboctinterp.dll fails with the missing symbols attached: (I
> omitted double errors in the same object file, otherwise the list is
> *really* long and does not contain additional information):
> 
> The first group stems from $(LIBCRUFT) missing as link dependency.
> 
> The second group stems from missing
>    -lgdi32 (GetDeviceCaps)
>    -liberty (mkstemps)
> The first is the windows system GDI library and the second is the
> mingw/gcc support library.
> Both are added to $LIBS during configure stage for the mingw platform
> 
> The third group stems from $(FLIBS) missing as link dependency.
> 
> To link successfully I have to do
> 
> OCTINTERP_LINK_DEPS = $(RLD_FLAG) -L../liboctave $(LIBOCTAVE)
> -L../libcruft $(LIBCRUFT) \
>    $(HDF5_LIBS) $(ZLIB_LIBS) $(X11_LIBS) $(OPENGL_LIBS) $(CARBON_LIBS) \
>    $(LIBS) $(FLIBS)

Looking closely I see that $(LIBS) already contains -lgfortran as the 
configure summary tells:

   Fortran libraries:    -lgfortran
   LIBS:                 -liberty -llapack -lblas -lgfortran -lblas -lm 
  -lgdi32 -lws2_32 -luser32 -lkernel32

so actually it suffices to add simply $(LIBS), i.e.

OCTINTERP_LINK_DEPS = $(RLD_FLAG) -L../liboctave $(LIBOCTAVE) 
-L../libcruft $(LIBCRUFT) \
   $(HDF5_LIBS) $(ZLIB_LIBS) $(X11_LIBS) $(OPENGL_LIBS) $(CARBON_LIBS) \
   $(LIBS)

benjamin

From michael.goffioul at gmail.com  Sat Aug 15 07:10:14 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Sat, 15 Aug 2009 13:10:14 +0100
Subject: FFTW wrong AC_DEFINE macro
In-Reply-To: <128f38bd0908150157s320abed8qabc96ba56e9a0bca@mail.gmail.com>
References: <128f38bd0908150157s320abed8qabc96ba56e9a0bca@mail.gmail.com>
Message-ID: <128f38bd0908150510n30ff3379ge057ee597d93a23@mail.gmail.com>

Forget about it, that was my fault. Sorry for the noise.

Michael.


On Sat, Aug 15, 2009 at 9:57 AM, Michael
Goffioul<michael.goffioul at gmail.com> wrote:
> Hi,
>
> It seems the code now uses HAVE_FFTW preprocessor macro,
> but the configure script still defines HAVE_FFTW3. So the FFTW
> code is not used (leading to undefined symbols at link time for
> liboctave). I guess it's related to John's recent changes.
>
> Bye,
>
> Michael.
>

From bpabbott at mac.com  Sat Aug 15 09:54:38 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Sat, 15 Aug 2009 10:54:38 -0400
Subject: backend listeners (was: Requesting an Octave mentor)
In-Reply-To: <3A6AF806-1691-4B33-BFE2-34D5089713F4@mac.com>
References: <9543b3a40908131010s3f6d0db2j1adf66a0754a48cd@mail.gmail.com>
	<69d8d540908132230y1e7c7d7cse07480b8012dba3b@mail.gmail.com>
	<19076.63762.997506.547880@segfault.lan>
	<9543b3a40908140811i7860ef09lac66c157fb4232e6@mail.gmail.com>
	<3A6AF806-1691-4B33-BFE2-34D5089713F4@mac.com>
Message-ID: <6F2068E4-2938-4D79-B3F5-16E86CF1357F@mac.com>


On Aug 14, 2009, at 7:43 PM, Ben Abbott wrote:

> On Aug 14, 2009, at 11:11 AM, Jordi Guti?rrez Hermos wrote:
>
>> Hopefully Ben and Robert above can help me get started.
>>
>> - Jordi G. H.
>
> Ok, this will be a bit of a core-dump, but  ...
>
> <snip>

Its been quite a while since I looked at /src/graphics.cc. It appears  
(to me, I may be wrong) that Michael Goffioul has included some code  
needed for the backend listeners.

MIchael, if you have the time, can you comment on what is needed to  
implement listeners triggered by changes in units/fontunits?

Ben





From xavier.delacour at gmail.com  Sat Aug 15 16:51:55 2009
From: xavier.delacour at gmail.com (Xavier Delacour)
Date: Sat, 15 Aug 2009 14:51:55 -0700
Subject: distinguishing octave versions with ifdef
In-Reply-To: <67abaf50907051725h56c9798fl204808a1f7d6a828@mail.gmail.com>
References: <67abaf50907051725h56c9798fl204808a1f7d6a828@mail.gmail.com>
Message-ID: <67abaf50908151451r411017a3tade54fb73baca18f@mail.gmail.com>

Please consider the following patch that adds a non-string/numerical
form of the octave api version in src/version.h.

This allows use of preprocessor conditionals to distinguish between
octave versions, and in particular is key for SWIG to be able to
generate bindings that compile under multiple versions of octave.

Thanks,
Xavier


On Sun, Jul 5, 2009 at 5:25 PM, Xavier
Delacour<xavier.delacour at gmail.com> wrote:
> I would like to make oct-file plugins that compile properly against
> multiple versions of octave, in the face of internal API changes.
> Ideally I want something like
>
> #if OCTAVE_API_VERSION >= 37
> // use new api
> #else
> // use old api
> #endif
>
> In src/version.h I see
>
> #define OCTAVE_API_VERSION "api-v37"
>
> which is difficult to use from the preprocessor.
>
> Can someone suggest a way to do what I want? (without resorting to
> configure magic and generating my own defines, etc).
>
> Thanks,
> Xavier
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch9525.diff
Type: text/x-patch
Size: 528 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090815/760aca12/attachment.bin 

From michael.goffioul at gmail.com  Sat Aug 15 18:10:05 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Sun, 16 Aug 2009 00:10:05 +0100
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <19077.28862.827842.41629@segfault.lan>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
Message-ID: <128f38bd0908151610o1cfe8efcsffabc0ad8089f1e7@mail.gmail.com>

On Fri, Aug 14, 2009 at 3:12 PM, John W. Eaton<jwe at octave.org> wrote:
> It would be helpful if people building Octave on Windows and OS X
> systems could configure and build the latest Octave sources on and
> send a list of symbols that are unresolved when creating the libcruft,
> liboctave, liboctinterp shared libraries, when linking the Octave
> executable file, and when building the .oct files.

This is what's needed to enable compilation under MSVC.

Michael.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cc_scripts_macro_fix
Type: application/octet-stream
Size: 5178 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090816/553f038a/attachment.obj 

From storrsjm at email.uc.edu  Sat Aug 15 20:33:42 2009
From: storrsjm at email.uc.edu (Judd Storrs)
Date: Sat, 15 Aug 2009 21:33:42 -0400
Subject: FYI: subasgn argument optimization
In-Reply-To: <69d8d540908150004re068133w9978bf5024606441@mail.gmail.com>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
	<69d8d540908130746k948365dn9cfc8daf80901e78@mail.gmail.com>
	<19077.34069.745516.227226@segfault.lan>
	<69d8d540908141005gfa669dkbe6475992effcaf4@mail.gmail.com>
	<a0daad600908141405y373fd65ar87c03394b1fe252d@mail.gmail.com>
	<69d8d540908150004re068133w9978bf5024606441@mail.gmail.com>
Message-ID: <a0daad600908151833y5ad47fbaib8834a2434e33285@mail.gmail.com>

On Sat, Aug 15, 2009 at 3:04 AM, Jaroslav Hajek <highegg at gmail.com> wrote:

> Also, does Matlab really auto-forward the field references to parent
> classes? I can't find that anywhere in the Matlab docs. For instance,
> if a class bar inherits from foo, which has a field xx, does this.xx
> really work inside bar methods, or must one do this.foo.xx?


Apparently, you cannot access fields of a parent class using either
this.foo.xx nor this.xx from a subclass. A subclass can have it's own
this.xx but there doesn't appear to be any forwarding of xx at all. To me it
looks like inheritance only has to do with function lookup.

In the following example, look for @foo/access.m reading the value of bar.xx
instead of bar.foo.xx and not substituting bar.foo.yy for the missing
bar.yy. Also look for @bar/access1.m also not forwarding bar.yy into
bar.foo.yy. In @bar/access2.m, any direct access to bar.foo.xx or bar.foo.yy
is not allowed.


@foo/foo.m:
function obj = foo()
    obj.xx = 10 ;
    obj.yy = 20 ;
    obj = class(obj, 'foo') ;
end

@foo/access.m:
function access(obj)
    disp(obj.xx) ;
    disp(obj,yy) ;
end

@bar/bar.m:
function obj = bar()
    obj.xx = 30 ;
    obj = class(obj, 'bar', foo() ) ;
end

@bar/access1.m:
function access1(obj)
    disp(obj.xx) ;
    disp(obj.yy) ;
end

@bar/access2.m:
function access2(obj)
    disp(obj.foo.xx)
    disp(obj.foo.yy)
end




>> b = bar()

b =

    bar object: 1-by-1

>> access(b)
    10

??? Undefined function or variable 'yy'.

Error in ==> foo.access at 3
    disp(obj,yy) ;

>> access1(b)
    30

??? Reference to non-existent field 'yy'.

Error in ==> bar.access1 at 3
    disp(obj.yy) ;

>> access2(b)
??? Access to an object's fields is only permitted within its methods.

Error in ==> bar.access2 at 2
    disp(obj.foo.xx)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090815/3a1ea0e5/attachment.html 

From storrsjm at email.uc.edu  Sat Aug 15 20:46:26 2009
From: storrsjm at email.uc.edu (Judd Storrs)
Date: Sat, 15 Aug 2009 21:46:26 -0400
Subject: FYI: subasgn argument optimization
In-Reply-To: <a0daad600908151833y5ad47fbaib8834a2434e33285@mail.gmail.com>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
	<69d8d540908130746k948365dn9cfc8daf80901e78@mail.gmail.com>
	<19077.34069.745516.227226@segfault.lan>
	<69d8d540908141005gfa669dkbe6475992effcaf4@mail.gmail.com>
	<a0daad600908141405y373fd65ar87c03394b1fe252d@mail.gmail.com>
	<69d8d540908150004re068133w9978bf5024606441@mail.gmail.com>
	<a0daad600908151833y5ad47fbaib8834a2434e33285@mail.gmail.com>
Message-ID: <a0daad600908151846h41f11d6oedcc54f4c50f1891@mail.gmail.com>

Sorry, I found a typo in @foo/access.m. I typed "disp(obj,yy)" instead of
"disp(obj.yy)" by accident (comma instead of period).

With this version

@foo/access.m:
function access(obj)
    disp(obj.xx) ;
    disp(obj.yy) ;
end

Then the inherited function uses the parent's values.

>> b = bar() ;
>> access(b)
    10
    20

These are the values from the parent class. It is still true that subclasses
cannot access parent class fields and that non-existent fields are not
forwarded. Sorry for any confusion.

--judd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090815/48873b68/attachment.html 

From octave at phaselockedsystems.com  Sat Aug 15 21:38:33 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Sat, 15 Aug 2009 19:38:33 -0700
Subject: FYI: subasgn argument optimization
In-Reply-To: <a0daad600908151846h41f11d6oedcc54f4c50f1891@mail.gmail.com>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>	<69d8d540908130746k948365dn9cfc8daf80901e78@mail.gmail.com>	<19077.34069.745516.227226@segfault.lan>	<69d8d540908141005gfa669dkbe6475992effcaf4@mail.gmail.com>	<a0daad600908141405y373fd65ar87c03394b1fe252d@mail.gmail.com>	<69d8d540908150004re068133w9978bf5024606441@mail.gmail.com>	<a0daad600908151833y5ad47fbaib8834a2434e33285@mail.gmail.com>
	<a0daad600908151846h41f11d6oedcc54f4c50f1891@mail.gmail.com>
Message-ID: <4A877129.5010307@phaselockedsystems.com>

Judd Storrs wrote:
> Sorry, I found a typo in @foo/access.m. I typed "disp(obj,yy)" instead 
> of "disp(obj.yy)" by accident (comma instead of period).
>
> With this version
>
> @foo/access.m:
> function access(obj)
>     disp(obj.xx) ;
>     disp(obj.yy) ;
> end
>
> Then the inherited function uses the parent's values.
>
> >> b = bar() ;
> >> access(b)
>     10
>     20
>
> These are the values from the parent class. It is still true that 
> subclasses cannot access parent class fields and that non-existent 
> fields are not forwarded. Sorry for any confusion.
>
> --judd
The parent class fields may be accessed within a class method or by 
using subsref/subsasgn, but are private to the class by default.

Bob


From thomas.weber.mail at gmail.com  Sun Aug 16 16:09:09 2009
From: thomas.weber.mail at gmail.com (Thomas Weber)
Date: Sun, 16 Aug 2009 23:09:09 +0200
Subject: [changeset] GraphicsMagick++ configuration
In-Reply-To: <19067.14844.220747.257229@segfault.lan>
References: <4A7AEEF4.2070101@acc.umu.se>
	<19066.62968.137520.390478@segfault.lan>
	<4A7B3868.9020001@acc.umu.se>
	<19067.14844.220747.257229@segfault.lan>
Message-ID: <20090816210909.GA15975@atlan>

On Thu, Aug 06, 2009 at 04:15:56PM -0400, John W. Eaton wrote:
> On  6-Aug-2009, David Grundberg wrote:
> 
> | John W. Eaton skrev:
> | > On  6-Aug-2009, David Grundberg wrote:
> | >
> | > | I've rearranged the GraphicsMagick++ configuration. I had some trouble 
> | > | since I'm running a custom GraphicsMagick installation. The Octave build 
> | > | system was running GraphicsMagick++-config during make. It was missing 
> | > | ldflags and using only the basename of the config executable (as opposed 
> | > | to a full path).
> | > | 
> | > | I've changed it so that GraphicsMagick++-config is only run in the 
> | > | configure script. Also introduced MAGICK_CONFIG as a precious variable.
> | >
> | > I removed --ldflags to fix the following mysterious problem on my
> | > system:
> | >
> | >   https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-July/012879.html
> | >
> | > So I don't think I can put it back without breaking __magick_read__
> | > again, at least for me and other Debian users.
> | >
> | > What are -Wl,-z,relro and -pie doing in the ldflags anyway?  Are those
> | > arguments not present on your system?  Maybe they are present on mine
> | > because of the way Debian builds the graphics magick library package?
> | > Perhaps these flags make sense for creating the graphics magick
> | > library itself, but I can't see any reason for them to be required to
> | > link the graphics magick library with __magick_read__.oct.
> | >
> | > jwe
> | >   
> | So that's why --ldflags was taken away! I don't have that problem. This 
> | is the output from my config (where I'm building):
> | 
> | $ 
> | octave-patching/dependencies/graphicsmagick-install/bin/GraphicsMagick++-config 
> | --ldflags --libs
> | -L/Home/staff/davidg/octave-patching/dependencies/graphicsmagick-install/lib 
> | -L/usr/lib -L/usr/lib
> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper 
> | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm 
> | -lgomp -lpthread
> | 
> | My ubuntu 9.04 box says this about the managed package (haven't tried 
> | building against it):
> | david at lack:~$ GraphicsMagick++-config --ldflags --libs
> | -L/usr/lib -Wl,-Bsymbolic-functions -L/usr/lib/X11 -L/usr/lib -L/usr/lib
> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper 
> | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm 
> | -lpthread
> 
> So what should we do about this?  

These are different versions. The Ubuntu version is 1.1.11-something,
your Debian versions is 1.3.5-something.

> around it by filtering out everything except -L options from the
> --ldflags output, but I'd rather see it fixed in graphics magick.
> What should graphics magick really be storing in the config script
> for --ldflags?  Should options like -pie and -Wl,-z,relro really
> appear there?  Or is this just a Debian packaging problem?

The Debian packaging adds the -pie and -Wl options when building
GraphicsMagick to the LDFLAGS. GraphicsMagick then copies LDFLAGS into its
--ldflags output. Looking at Ubuntu's build logs, the same is already
happening with newer versions of graphicsmagick.

I'll ask the Debian maintainer of GraphicsMagick about it.

	Thomas

From jwe at octave.org  Sun Aug 16 23:37:23 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 17 Aug 2009 00:37:23 -0400
Subject: autoconf-2.64 required?
In-Reply-To: <69d8d540908142207o49aba50au92eb8d5100c75574@mail.gmail.com>
References: <128f38bd0908141502med3723ev41c8e6cd25ddebd1@mail.gmail.com>
	<69d8d540908142207o49aba50au92eb8d5100c75574@mail.gmail.com>
Message-ID: <19080.56963.410706.477868@segfault.lan>

On 15-Aug-2009, Jaroslav Hajek wrote:

| Autoconf 2.64 is really very new; though by the time Octave 3.4 will
| be released, it may already be widespread.
| However, in this case apparently it's just m4_ifblank and m4_ifnblank
| missing, so an easy remedy is to steal them out from autoconf 2.64 and
| define them ourselves if they're not there:
| http://hg.savannah.gnu.org/hgweb/octave/rev/691545147aca
| 
| this enables use of autoconf 2.63 for me.

Thanks.  It was not my intent to change the script to require the very
latest autoconf.

jwe

From individ at acc.umu.se  Mon Aug 17 02:11:36 2009
From: individ at acc.umu.se (David Grundberg)
Date: Mon, 17 Aug 2009 09:11:36 +0200
Subject: [changeset] GraphicsMagick++ configuration
In-Reply-To: <20090816210909.GA15975@atlan>
References: <4A7AEEF4.2070101@acc.umu.se>
	<19066.62968.137520.390478@segfault.lan>
	<4A7B3868.9020001@acc.umu.se>
	<19067.14844.220747.257229@segfault.lan>
	<20090816210909.GA15975@atlan>
Message-ID: <4A8902A8.8060100@acc.umu.se>

Thomas Weber wrote:
> On Thu, Aug 06, 2009 at 04:15:56PM -0400, John W. Eaton wrote:
>   
>> On  6-Aug-2009, David Grundberg wrote:
>>
>> | John W. Eaton skrev:
>> | > On  6-Aug-2009, David Grundberg wrote:
>> | >
>> | > | I've rearranged the GraphicsMagick++ configuration. I had some trouble 
>> | > | since I'm running a custom GraphicsMagick installation. The Octave build 
>> | > | system was running GraphicsMagick++-config during make. It was missing 
>> | > | ldflags and using only the basename of the config executable (as opposed 
>> | > | to a full path).
>> | > | 
>> | > | I've changed it so that GraphicsMagick++-config is only run in the 
>> | > | configure script. Also introduced MAGICK_CONFIG as a precious variable.
>> | >
>> | > I removed --ldflags to fix the following mysterious problem on my
>> | > system:
>> | >
>> | >   https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-July/012879.html
>> | >
>> | > So I don't think I can put it back without breaking __magick_read__
>> | > again, at least for me and other Debian users.
>> | >
>> | > What are -Wl,-z,relro and -pie doing in the ldflags anyway?  Are those
>> | > arguments not present on your system?  Maybe they are present on mine
>> | > because of the way Debian builds the graphics magick library package?
>> | > Perhaps these flags make sense for creating the graphics magick
>> | > library itself, but I can't see any reason for them to be required to
>> | > link the graphics magick library with __magick_read__.oct.
>> | >
>> | > jwe
>> | >   
>> | So that's why --ldflags was taken away! I don't have that problem. This 
>> | is the output from my config (where I'm building):
>> | 
>> | $ 
>> | octave-patching/dependencies/graphicsmagick-install/bin/GraphicsMagick++-config 
>> | --ldflags --libs
>> | -L/Home/staff/davidg/octave-patching/dependencies/graphicsmagick-install/lib 
>> | -L/usr/lib -L/usr/lib
>> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper 
>> | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm 
>> | -lgomp -lpthread
>> | 
>> | My ubuntu 9.04 box says this about the managed package (haven't tried 
>> | building against it):
>> | david at lack:~$ GraphicsMagick++-config --ldflags --libs
>> | -L/usr/lib -Wl,-Bsymbolic-functions -L/usr/lib/X11 -L/usr/lib -L/usr/lib
>> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper 
>> | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm 
>> | -lpthread
>>
>> So what should we do about this?  
>>     
>
> These are different versions. The Ubuntu version is 1.1.11-something,
> your Debian versions is 1.3.5-something.
>
>   
>> around it by filtering out everything except -L options from the
>> --ldflags output, but I'd rather see it fixed in graphics magick.
>> What should graphics magick really be storing in the config script
>> for --ldflags?  Should options like -pie and -Wl,-z,relro really
>> appear there?  Or is this just a Debian packaging problem?
>>     
>
> The Debian packaging adds the -pie and -Wl options when building
> GraphicsMagick to the LDFLAGS. GraphicsMagick then copies LDFLAGS into its
> --ldflags output. Looking at Ubuntu's build logs, the same is already
> happening with newer versions of graphicsmagick.
>
> I'll ask the Debian maintainer of GraphicsMagick about it.
>
> 	Thomas
>   
Great!

From highegg at gmail.com  Mon Aug 17 06:35:35 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 17 Aug 2009 13:35:35 +0200
Subject: FYI: subasgn argument optimization
In-Reply-To: <19077.34069.745516.227226@segfault.lan>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
	<69d8d540908130746k948365dn9cfc8daf80901e78@mail.gmail.com>
	<19077.34069.745516.227226@segfault.lan>
Message-ID: <69d8d540908170435i7326996x3acebb197b702def@mail.gmail.com>

On Fri, Aug 14, 2009 at 5:39 PM, John W. Eaton<jwe at octave.org> wrote:
> On 13-Aug-2009, Jaroslav Hajek wrote:
>
> | PS. This patch rebases octave_class on top of octave_struct.
>
> It seems that would be a good thing. ?I can no longer remember why
> I didn't do it originally. ?I don't think I would have avoided
> inheritance unless I had a reason, but then maybe I didn't realize how
> similar classes were to structs.
>

Maybe you had a reason; anyway, my implementation spanned a lot more
problems with inheritance than it was worth, so I reverted the
rebasing:
http://hg.savannah.gnu.org/hgweb/octave/rev/8e5009334661
and I just injected code from ov-struct.cc to optimize out a useless
copy on nested assignment on fields:
obj.x(1) = 1; // does copy x in 3.2.x if x is an object.

Of course, the injection is what I wanted to avoid by using
inheritance, but right now I think it should be done without altering
octave_struct or not done at all.
Your implementation handles multidimensional objects, or inheritance,
but not both (actually, even constructing such things fails):

@foo/foo.m
function f = foo ()
  a = struct ("x", {1 2 3 4});
  f = class (a, "foo");
end

@bar/bar.m
function b = bar ()
  a = struct ("y", {1 2 3 4});
  b = class (a, "bar", foo());
end

octave:1> a = foo
octave:2> b = bar
error: invalid structure assignment
error: called from:
error:   /home/hajek/devel/octave/patches/@bar/bar.m at line 3, column 5

the basic problem is (besides missing code support in the nested part
of octave_class::subsasgn) that you can't store a single object inside
a field of multidimensional Octave_map - all fields must be the same
size.

Maybe a possible solution would be to not store parent objects as
regular fields, but separately; you'd need to hack the field lookup
for that and probably also plain () indexing and indexed assignment.
But then I still wonder what obj.parent_class_name is supposed to do
if obj is multidimensional (normally, you should get a cs-list).
Apparently the old OOP model is documented only poorly from Matlab,
and I don't have Matlab, so I should probably resist further playing
with this part to avoid breaking something.

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


From lindnerben at gmx.net  Mon Aug 17 10:27:05 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Mon, 17 Aug 2009 17:27:05 +0200
Subject: overriding print.m pdf default terminal choices?
Message-ID: <4A8976C9.6060705@gmx.net>

Hello list,

I wondered if it is possible to force print.m to use ghostscript for
printing to pdf even if gnuplot provides a pdfcairo terminal?

I ask because the last available gnuplot for win32 does not include the
patch which fixes the spurious-pages-in-pdf-output bug.
So a command as
  plot(0:0.1:10, sin(0:0.1:10), "@-"); print -dpdf test.pdf
produces a three-page pdf.

I don't know when there will be a new gnuplot release or snapshot
release but the do not happen very frequently.

So for the mingw32 binaries I'd like to have print.m to use ps->pdf via
ghostscript for the moment.

benjamin


From jwe at octave.org  Mon Aug 17 11:23:25 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 17 Aug 2009 12:23:25 -0400
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <128f38bd0908151610o1cfe8efcsffabc0ad8089f1e7@mail.gmail.com>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
	<128f38bd0908151610o1cfe8efcsffabc0ad8089f1e7@mail.gmail.com>
Message-ID: <19081.33789.710879.157942@segfault.lan>

On 16-Aug-2009, Michael Goffioul wrote:

| On Fri, Aug 14, 2009 at 3:12 PM, John W. Eaton<jwe at octave.org> wrote:
| > It would be helpful if people building Octave on Windows and OS X
| > systems could configure and build the latest Octave sources on and
| > send a list of symbols that are unresolved when creating the libcruft,
| > liboctave, liboctinterp shared libraries, when linking the Octave
| > executable file, and when building the .oct files.
| 
| This is what's needed to enable compilation under MSVC.

I applied the changees for aclocal.m4 and src/Makefile.in.  I'll fix
the octave-bug script and c++ program with a change that adds all the
new variables.

For mkoctfile, shouldn't we drop all the extra libraries and by
default only link with $(OCT_LINK_DEPS), same as we now have it for
the .oct files that are part of Octave?

Thanks,

jwe

From jwe at octave.org  Mon Aug 17 11:27:04 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 17 Aug 2009 12:27:04 -0400
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A8684C5.8070302@gmx.net>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
	<4A868317.10203@gmx.net> <4A8684C5.8070302@gmx.net>
Message-ID: <19081.34008.519266.126754@segfault.lan>

On 15-Aug-2009, Benjamin Lindner wrote:

| Benjamin Lindner wrote:
| > 
| > Linking liboctinterp.dll fails with the missing symbols attached: (I
| > omitted double errors in the same object file, otherwise the list is
| > *really* long and does not contain additional information):
| > 
| > The first group stems from $(LIBCRUFT) missing as link dependency.
| > 
| > The second group stems from missing
| >    -lgdi32 (GetDeviceCaps)
| >    -liberty (mkstemps)
| > The first is the windows system GDI library and the second is the
| > mingw/gcc support library.
| > Both are added to $LIBS during configure stage for the mingw platform
| > 
| > The third group stems from $(FLIBS) missing as link dependency.
| > 
| > To link successfully I have to do
| > 
| > OCTINTERP_LINK_DEPS = $(RLD_FLAG) -L../liboctave $(LIBOCTAVE)
| > -L../libcruft $(LIBCRUFT) \
| >    $(HDF5_LIBS) $(ZLIB_LIBS) $(X11_LIBS) $(OPENGL_LIBS) $(CARBON_LIBS) \
| >    $(LIBS) $(FLIBS)
| 
| Looking closely I see that $(LIBS) already contains -lgfortran as the 
| configure summary tells:
| 
|    Fortran libraries:    -lgfortran
|    LIBS:                 -liberty -llapack -lblas -lgfortran -lblas -lm 
|   -lgdi32 -lws2_32 -luser32 -lkernel32

I think it is a mistake that $(BLAS_LIBS) and $(FLIBS) appear in LIBS.

jwe

From jwe at octave.org  Mon Aug 17 11:41:25 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 17 Aug 2009 12:41:25 -0400
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A868317.10203@gmx.net>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
	<4A868317.10203@gmx.net>
Message-ID: <19081.34869.778915.594647@segfault.lan>

On 15-Aug-2009, Benjamin Lindner wrote:

| Now for the undefined reference linker errors:

I checked in some additional changes.  I will deal with the mkoctfile
and octave-bug scripts/programs later, but is there anything that I
missed for building libcruft, liboctave, liboctinterp, and the .oct
files?

Thanks,

jwe

From bpabbott at mac.com  Mon Aug 17 11:50:29 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Mon, 17 Aug 2009 12:50:29 -0400
Subject: overriding print.m pdf default terminal choices?
In-Reply-To: <150650070158267485735317469619294396129-Webmail@me.com>
References: <150650070158267485735317469619294396129-Webmail@me.com>
Message-ID: <152987640169990211162329315010467704320-Webmail@me.com>

On Monday, August 17, 2009, at 11:27AM, "Benjamin Lindner" <lindnerben at gmx.net> wrote:
>Hello list,
>
>I wondered if it is possible to force print.m to use ghostscript for
>printing to pdf even if gnuplot provides a pdfcairo terminal?
>
>I ask because the last available gnuplot for win32 does not include the
>patch which fixes the spurious-pages-in-pdf-output bug.
>So a command as
>  plot(0:0.1:10, sin(0:0.1:10), "@-"); print -dpdf test.pdf
>produces a three-page pdf.
>
>I don't know when there will be a new gnuplot release or snapshot
>release but the do not happen very frequently.
>
>So for the mingw32 binaries I'd like to have print.m to use ps->pdf via
>ghostscript for the moment.
>
>benjamin

I assume you are referring to Octave's latest sources, and that you are not running gnuplot's development sources (meaning your version of gnuplot is 4.2.x, or earlier)?

If so then, what you're asking for should be the default. If it is not, then the check for ghostscript may be failing.

Does the code below indicate you have ghostscript installed?

    if (~isempty (getenv ("GSC")))
      persistent ghostscript_binary = getenv ("GSC");
    else
      persistent ghostscript_binary = "gswin32c";
    endif
    [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1 ) else ( exit /B 0 )", ghostscript_binary));
    have_ghostscript = (status == 0)

Ben


From lindnerben at gmx.net  Mon Aug 17 14:06:08 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Mon, 17 Aug 2009 21:06:08 +0200
Subject: overriding print.m pdf default terminal choices?
In-Reply-To: <152987640169990211162329315010467704320-Webmail@me.com>
References: <150650070158267485735317469619294396129-Webmail@me.com>
	<152987640169990211162329315010467704320-Webmail@me.com>
Message-ID: <4A89AA20.3060802@gmx.net>

Ben Abbott wrote:
> On Monday, August 17, 2009, at 11:27AM, "Benjamin Lindner" <lindnerben at gmx.net> wrote:
>> Hello list,
>>
>> I wondered if it is possible to force print.m to use ghostscript for
>> printing to pdf even if gnuplot provides a pdfcairo terminal?
>>
>> I ask because the last available gnuplot for win32 does not include the
>> patch which fixes the spurious-pages-in-pdf-output bug.
>> So a command as
>>  plot(0:0.1:10, sin(0:0.1:10), "@-"); print -dpdf test.pdf
>> produces a three-page pdf.
>>
>> I don't know when there will be a new gnuplot release or snapshot
>> release but the do not happen very frequently.
>>
>> So for the mingw32 binaries I'd like to have print.m to use ps->pdf via
>> ghostscript for the moment.
>>
>> benjamin
> 
> I assume you are referring to Octave's latest sources, and that you are not running gnuplot's development sources (meaning your version of gnuplot is 4.2.x, or earlier)?

Actually I'm referring to the 3.2.x branch of octave and the latest 
version of gnuplot available is the 2008-11-21 4.3.0 cvs snapshot.

> If so then, what you're asking for should be the default. If it is not, then the check for ghostscript may be failing.
> 
> Does the code below indicate you have ghostscript installed?
> 
>     if (~isempty (getenv ("GSC")))
>       persistent ghostscript_binary = getenv ("GSC");
>     else
>       persistent ghostscript_binary = "gswin32c";
>     endif
>     [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1 ) else ( exit /B 0 )", ghostscript_binary));
>     have_ghostscript = (status == 0)
> 
> Ben
> 

thanks for the hint.

I have the environment variable GSC defined as

 > ghostscript_binary = getenv("GSC")
ghostscript_binary = C:\Programs\gs\gs8.62\bin\gswin32c.exe

and naturally this executable exists.
However, have_ghostscript evaluates to false.

This is strange.
Seems the exit code is not propagated into the variable status, as

 > [s,o]=system("exit 1")
s =  127
o =

but

 > system("exit 1")
ans =  1

I need to investigate this further.


benjamin

From highegg at gmail.com  Mon Aug 17 14:40:20 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 17 Aug 2009 21:40:20 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <19081.34869.778915.594647@segfault.lan>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
	<4A868317.10203@gmx.net> <19081.34869.778915.594647@segfault.lan>
Message-ID: <69d8d540908171240t32c859adg3e635f57aa639ad1@mail.gmail.com>

On Mon, Aug 17, 2009 at 6:41 PM, John W. Eaton<jwe at octave.org> wrote:
> On 15-Aug-2009, Benjamin Lindner wrote:
>
> | Now for the undefined reference linker errors:
>
> I checked in some additional changes. ?I will deal with the mkoctfile
> and octave-bug scripts/programs later, but is there anything that I
> missed for building libcruft, liboctave, liboctinterp, and the .oct
> files?
>

One possible gotcha is that building now fails if you have static
libraries, e.g suitesparse. The reason is that not all functions are
used from within liboctave, so not all are linked in (if using static
libs). Since SPARSE_LIBS are not specified again, you get undefined
references.

One possibility is to wrap the SPARSE_LIBS in -Wl,--whole-archive
-Wl, --no-whole-archive, or just switch to a shared library (which I'd
recommend anyway and I'm going to do it).

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


From ibf_c at web.de  Mon Aug 17 15:28:07 2009
From: ibf_c at web.de (Christian Fischer)
Date: Mon, 17 Aug 2009 22:28:07 +0200
Subject: de_min.m: global optimisation (differential evolution)
Message-ID: <1109634279@web.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Michael,

Thanks for the test script.

It has been a while. My first version I sent performed very well on
the simple rosenbrock function, outperforming SA by using much
less function evaluations.

I made a few adjustments which should make it easier to use.
I added a test, a demo and did a bit cleanup.

I attached the new version along with another very nasty test
function (rastrigin.m). I also made a cpp version if someone is
interested.

I think de_min.m is ready to be included in the optim package.

If there are people saying that they would benefit from a c++
implementation, I might do it. But for many real problems, the
function evaluation itself is the problem.

In order to make updates to this function, it might be a good idea
if have an svn account.

Comments and criticism welcome.

Best wishes
Christian

On Tue, 2009-07-21 at 10:00 +0200, Michael Creel wrote:
> Hi Christian,
> This function looks like it could find a home in the optim package
> (http://octave.sourceforge.net/optim/index.html). I have written
> simulated annealing code that is already part of the package.
> Following is a script that will use your code and the simulated
> annealing code to minimize a higher dimensional Rosenbrock function
> (also in optim).
> Best, Michael
> 
> dim = 10;
> ctl.XVmin = -2*ones(1, dim);
> ctl.XVmax = 2*ones(1, dim);
> tic;
> [x, obj_value, nfeval] = de_min (@rosenbrock, ctl);
> toc
> printf("solution: \n");
> disp(x);
> 
> # SA controls
> ub = 2*ones(dim,1);
> lb = -ub;
> nt = 20;
> ns = 5;
> rt = 0.75; # careful - this is too low for many problems
> maxevals = 1e10;
> neps = 5;
> functol = 1e-7;
> paramtol = 1e-5;
> verbosity = 1; # only final results. Inc
> minarg = 1;
> control = { lb, ub, nt, ns, rt, maxevals, neps, functol, paramtol,
> verbosity, 1};
> # do sa
> x = zeros(dim,1);
> tic;
> [theta, obj_value, convergence] = samin("rosenbrock", {x}, control);
> toc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.6)

iQIcBAEBCAAGBQJKibs1AAoJEJghsQQMM0PTKBAP+wdg2IKRAncRGyQmqjyqxDd2
79SQSc+JmFo5R79j8jIEYuyjCOQYhkQ/6T4Hv1JhC9AbQanXTwE6XH/VvMAHNlJN
bCGVHrtjIo57FATEkgqYZEX+02Jn3LZhes5ORSwkR+/g8PMiFc1KFd5WhuO5dOT8
B76DC1ovXLxyTx0LfPkSrdRNjp9szBJW4ekWkSXFosBLfuIZtjemiEwNFwhrR80X
V8HMltakHNQAbrniR1FASLWMnwWaGXM7vn9WKo/wphDVl59KllPhNNxBVhFng9AI
gOgs+mgsAPr4BgvIFjm2lu2zqCkkgBlulVGZtDP54+YHvTVcuenavZCjMeAdPDoG
8SYCw49Yo6ICMOh1LGa+y6vt60r8ZWVH1uM49YwoJ3yna+b27f3fbdwbAbyWXqxY
NOzErY+uc4zJ12Q1ZajtQSjQA0iBKyIIoDMEaXWzs3db1Ry9KJl+errpNQ3rtgrg
YGioRBdSiSkWiQFvinYkoatVlW8BTNnKBIWXZlNKWBcdGWiG/XGaDf0YN6/ZGKN8
rgJjq5zPa3+Sb+YWsPyQEQAE/tsoH7NtGRP2kyOh1UmREt7PGgQ8Mi32UotCspTz
YfKZO/0FDeF1wLBe+CNsg72ADzSkFw9Tp6tKhaLp+m50M7q4rG4h0rm3+/yl7JRn
iaILvZZHpXcCeo2upO+N
=scNm
-----END PGP SIGNATURE-----

______________________________________________________
GRATIS f?r alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: de_min.m
Type: application/octet-stream
Size: 18457 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090817/0c04d70a/attachment-0003.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rastrigin.m
Type: application/octet-stream
Size: 1221 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090817/0c04d70a/attachment-0004.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rastrigin_oct.cpp
Type: application/octet-stream
Size: 1067 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090817/0c04d70a/attachment-0005.obj 

From michael.goffioul at gmail.com  Mon Aug 17 17:02:47 2009
From: michael.goffioul at gmail.com (Michael Goffioul)
Date: Mon, 17 Aug 2009 23:02:47 +0100
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <19081.33789.710879.157942@segfault.lan>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
	<128f38bd0908151610o1cfe8efcsffabc0ad8089f1e7@mail.gmail.com>
	<19081.33789.710879.157942@segfault.lan>
Message-ID: <128f38bd0908171502p36870e7br5814786eceba8db2@mail.gmail.com>

On Mon, Aug 17, 2009 at 5:23 PM, John W. Eaton<jwe at octave.org> wrote:
> | This is what's needed to enable compilation under MSVC.
>
> I applied the changees for aclocal.m4 and src/Makefile.in. ?I'll fix
> the octave-bug script and c++ program with a change that adds all the
> new variables.

I just tried your changes and besides pending problems in octave-bug and
mkoctfile, it works fine with MSVC.

Michael.


From lindnerben at gmx.net  Tue Aug 18 03:18:06 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Tue, 18 Aug 2009 10:18:06 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <19081.34869.778915.594647@segfault.lan>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>	<19077.28862.827842.41629@segfault.lan>	<4A868317.10203@gmx.net>
	<19081.34869.778915.594647@segfault.lan>
Message-ID: <4A8A63BE.4090300@gmx.net>

John W. Eaton wrote:
> On 15-Aug-2009, Benjamin Lindner wrote:
> 
> | Now for the undefined reference linker errors:
> 
> I checked in some additional changes.  I will deal with the mkoctfile
> and octave-bug scripts/programs later, but is there anything that I
> missed for building libcruft, liboctave, liboctinterp, and the .oct
> files?
> 

Aside from the pending octave-bug.cc and mkoctfile.cc changes,
building and linking completes successfully for mingw32/gcc.

thanks
benjamin

From individ at acc.umu.se  Tue Aug 18 07:51:23 2009
From: individ at acc.umu.se (David Grundberg)
Date: Tue, 18 Aug 2009 14:51:23 +0200
Subject: [changeset] Fix --without-library
Message-ID: <4A8AA3CB.9090606@acc.umu.se>

Hi,

I had some troubles with the --without-library arguments (qhull, amd, 
etc). Make tries linking against -lno. Here's the changed I've done to 
aclocal.m4 in order to make it work correctly. Also fixed so that 
QHULL_LIBS is cleared on missing headers.

Best regards,
David
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fixcheck.changeset
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090818/df402bbc/attachment.ksh 

From jwe at octave.org  Tue Aug 18 10:06:46 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 18 Aug 2009 11:06:46 -0400
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A8A63BE.4090300@gmx.net>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
	<4A868317.10203@gmx.net> <19081.34869.778915.594647@segfault.lan>
	<4A8A63BE.4090300@gmx.net>
Message-ID: <19082.50054.994278.817764@segfault.lan>

On 18-Aug-2009, Benjamin Lindner wrote:

| John W. Eaton wrote:
| > On 15-Aug-2009, Benjamin Lindner wrote:
| > 
| > | Now for the undefined reference linker errors:
| > 
| > I checked in some additional changes.  I will deal with the mkoctfile
| > and octave-bug scripts/programs later, but is there anything that I
| > missed for building libcruft, liboctave, liboctinterp, and the .oct
| > files?
| > 
| 
| Aside from the pending octave-bug.cc and mkoctfile.cc changes,
| building and linking completes successfully for mingw32/gcc.

I checked in changes for octave-bug.cc.in and mkoctfile.cc.in so they
should build now.  Are there still problems?  BTW, this is why I think
we should eliminate the script versions of these files.  It would be
easier to ensure consistency if we didn't have both shell script and
C++ versions...

jwe

From jwe at octave.org  Tue Aug 18 10:23:51 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 18 Aug 2009 11:23:51 -0400
Subject: [changeset] Fix --without-library
In-Reply-To: <4A8AA3CB.9090606@acc.umu.se>
References: <4A8AA3CB.9090606@acc.umu.se>
Message-ID: <19082.51079.635775.104968@segfault.lan>

On 18-Aug-2009, David Grundberg wrote:

| I had some troubles with the --without-library arguments (qhull, amd, 
| etc). Make tries linking against -lno. Here's the changed I've done to 
| aclocal.m4 in order to make it work correctly. Also fixed so that 
| QHULL_LIBS is cleared on missing headers.

I applied it.

Thanks,

jwe

From jwe at octave.org  Tue Aug 18 11:14:39 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 18 Aug 2009 12:14:39 -0400
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A867B26.3030508@gmx.net>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
	<4A867B26.3030508@gmx.net>
Message-ID: <19082.54127.595607.366724@segfault.lan>

On 15-Aug-2009, Thomas Treichl wrote:

| John W. Eaton schrieb:
| > It would be helpful if people building Octave on Windows and OS X
| > systems could configure and build the latest Octave sources on and
| > send a list of symbols that are unresolved when creating the libcruft,
| > liboctave, liboctinterp shared libraries, when linking the Octave
| > executable file, and when building the .oct files.
| 
| Here are the results for OS X (currently I cannot tell you anything about the 
| CURL and GLPK dependencies - these libs are not found by ./configure at the 
| moment - seems because of missing -lz in the test procedure):

I checked in changes that should fix this.  Can you check?

|    libcruft.dylib, liboctave.dylib: no unresolved symbols
| 
|    liboctinterp.dylib: (cf. attached file liboctave_symbols.txt.gz)
|      for manual compilation I needed to add
| 
|      -L../libcruft -lcruft -lreadline -lfftw3 -lfftw3f -lexpat
| 
|    octave: (cf. attached file liboctave_symbols.txt.gz)
|      for manual compilation I needed to add
| 
|      -lz -lhdf5 -lreadline -lfreetype -lfontconfig -lfftw3 -lfftw3f -lexpat

Where is the requirement for -lexpat coming from?

Thanks,

jwe

From jwe at octave.org  Tue Aug 18 12:03:02 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 18 Aug 2009 13:03:02 -0400
Subject: FYI: subasgn argument optimization
In-Reply-To: <69d8d540908170435i7326996x3acebb197b702def@mail.gmail.com>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
	<69d8d540908130746k948365dn9cfc8daf80901e78@mail.gmail.com>
	<19077.34069.745516.227226@segfault.lan>
	<69d8d540908170435i7326996x3acebb197b702def@mail.gmail.com>
Message-ID: <19082.57030.28516.263188@segfault.lan>

On 17-Aug-2009, Jaroslav Hajek wrote:

| On Fri, Aug 14, 2009 at 5:39 PM, John W. Eaton<jwe at octave.org> wrote:
| > On 13-Aug-2009, Jaroslav Hajek wrote:
| >
| > | PS. This patch rebases octave_class on top of octave_struct.
| >
| > It seems that would be a good thing. ?I can no longer remember why
| > I didn't do it originally. ?I don't think I would have avoided
| > inheritance unless I had a reason, but then maybe I didn't realize how
| > similar classes were to structs.
| >
| 
| Maybe you had a reason; anyway, my implementation spanned a lot more
| problems with inheritance than it was worth, so I reverted the
| rebasing:
| http://hg.savannah.gnu.org/hgweb/octave/rev/8e5009334661
| and I just injected code from ov-struct.cc to optimize out a useless
| copy on nested assignment on fields:
| obj.x(1) = 1; // does copy x in 3.2.x if x is an object.
| 
| Of course, the injection is what I wanted to avoid by using
| inheritance, but right now I think it should be done without altering
| octave_struct or not done at all.
| Your implementation handles multidimensional objects, or inheritance,
| but not both (actually, even constructing such things fails):
| 
| @foo/foo.m
| function f = foo ()
|   a = struct ("x", {1 2 3 4});
|   f = class (a, "foo");
| end
| 
| @bar/bar.m
| function b = bar ()
|   a = struct ("y", {1 2 3 4});
|   b = class (a, "bar", foo());
| end
| 
| octave:1> a = foo
| octave:2> b = bar
| error: invalid structure assignment
| error: called from:
| error:   /home/hajek/devel/octave/patches/@bar/bar.m at line 3, column 5
| 
| the basic problem is (besides missing code support in the nested part
| of octave_class::subsasgn) that you can't store a single object inside
| a field of multidimensional Octave_map - all fields must be the same
| size.
| 
| Maybe a possible solution would be to not store parent objects as
| regular fields, but separately; you'd need to hack the field lookup
| for that and probably also plain () indexing and indexed assignment.
| But then I still wonder what obj.parent_class_name is supposed to do
| if obj is multidimensional (normally, you should get a cs-list).
| Apparently the old OOP model is documented only poorly from Matlab,
| and I don't have Matlab, so I should probably resist further playing
| with this part to avoid breaking something.

I wonder how important it is to have multidimensional objects?  Are
they really used in practice?  If so, what code uses them?

jwe


From octave at phaselockedsystems.com  Tue Aug 18 12:20:31 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Tue, 18 Aug 2009 10:20:31 -0700
Subject: FYI: subasgn argument optimization
In-Reply-To: <19082.57030.28516.263188@segfault.lan>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>	<69d8d540908130746k948365dn9cfc8daf80901e78@mail.gmail.com>	<19077.34069.745516.227226@segfault.lan>	<69d8d540908170435i7326996x3acebb197b702def@mail.gmail.com>
	<19082.57030.28516.263188@segfault.lan>
Message-ID: <4A8AE2DF.40501@phaselockedsystems.com>

John W. Eaton wrote:
> On 17-Aug-2009, Jaroslav Hajek wrote:
>
> | On Fri, Aug 14, 2009 at 5:39 PM, John W. Eaton<jwe at octave.org> wrote:
> | > On 13-Aug-2009, Jaroslav Hajek wrote:
> | >
> | > | PS. This patch rebases octave_class on top of octave_struct.
> | >
> | > It seems that would be a good thing.  I can no longer remember why
> | > I didn't do it originally.  I don't think I would have avoided
> | > inheritance unless I had a reason, but then maybe I didn't realize how
> | > similar classes were to structs.
> | >
> | 
> | Maybe you had a reason; anyway, my implementation spanned a lot more
> | problems with inheritance than it was worth, so I reverted the
> | rebasing:
> | http://hg.savannah.gnu.org/hgweb/octave/rev/8e5009334661
> | and I just injected code from ov-struct.cc to optimize out a useless
> | copy on nested assignment on fields:
> | obj.x(1) = 1; // does copy x in 3.2.x if x is an object.
> | 
> | Of course, the injection is what I wanted to avoid by using
> | inheritance, but right now I think it should be done without altering
> | octave_struct or not done at all.
> | Your implementation handles multidimensional objects, or inheritance,
> | but not both (actually, even constructing such things fails):
> | 
> | @foo/foo.m
> | function f = foo ()
> |   a = struct ("x", {1 2 3 4});
> |   f = class (a, "foo");
> | end
> | 
> | @bar/bar.m
> | function b = bar ()
> |   a = struct ("y", {1 2 3 4});
> |   b = class (a, "bar", foo());
> | end
> | 
> | octave:1> a = foo
> | octave:2> b = bar
> | error: invalid structure assignment
> | error: called from:
> | error:   /home/hajek/devel/octave/patches/@bar/bar.m at line 3, column 5
> | 
> | the basic problem is (besides missing code support in the nested part
> | of octave_class::subsasgn) that you can't store a single object inside
> | a field of multidimensional Octave_map - all fields must be the same
> | size.
> | 
> | Maybe a possible solution would be to not store parent objects as
> | regular fields, but separately; you'd need to hack the field lookup
> | for that and probably also plain () indexing and indexed assignment.
> | But then I still wonder what obj.parent_class_name is supposed to do
> | if obj is multidimensional (normally, you should get a cs-list).
> | Apparently the old OOP model is documented only poorly from Matlab,
> | and I don't have Matlab, so I should probably resist further playing
> | with this part to avoid breaking something.
>
> I wonder how important it is to have multidimensional objects?  Are
> they really used in practice?  If so, what code uses them?
>
> jwe
>
>
>
>   
I had never thought of such things but I can think of a couple of uses 
for them in my own work.

I have a couple of other non-octave things that need to be done before I 
get back to this, but I have added this to my long and growing "to do" 
list.  First, I will see what MATLAB does, then I will try to figure out 
how to go about doing it.  I would really like to put this legacy OOP 
stuff to bed so I can get the new stuff implemented, but we do what we can.

Bob
--
Robert T. Short, Ph.D.
PhaseLocked Systems

From Thomas.Treichl at gmx.net  Tue Aug 18 13:36:08 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Tue, 18 Aug 2009 20:36:08 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <19082.54127.595607.366724@segfault.lan>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>	<19077.28862.827842.41629@segfault.lan>	<4A867B26.3030508@gmx.net>
	<19082.54127.595607.366724@segfault.lan>
Message-ID: <4A8AF498.6000306@gmx.net>

John W. Eaton schrieb:
> On 15-Aug-2009, Thomas Treichl wrote:
> 
> | John W. Eaton schrieb:
> | > It would be helpful if people building Octave on Windows and OS X
> | > systems could configure and build the latest Octave sources on and
> | > send a list of symbols that are unresolved when creating the libcruft,
> | > liboctave, liboctinterp shared libraries, when linking the Octave
> | > executable file, and when building the .oct files.
> | 
> | Here are the results for OS X (currently I cannot tell you anything about the 
> | CURL and GLPK dependencies - these libs are not found by ./configure at the 
> | moment - seems because of missing -lz in the test procedure):
> 
> I checked in changes that should fix this.  Can you check?

I will John, but I think I need another day for doing that. Yesterday I changed 
src/Makefile.in for myself and was able to compile all of the Octave sources. 
This is just FYI, I've attached 9534.diff which is the "hg diff -r 9534 
src/Makefile.in >9534.diff".

BTW, thanks for taking such linking issues directly into Octave build scripts, 
even if they don't exist on all platforms. That definitely makes a packager's 
life much easier ;)

> |    libcruft.dylib, liboctave.dylib: no unresolved symbols
> | 
> |    liboctinterp.dylib: (cf. attached file liboctave_symbols.txt.gz)
> |      for manual compilation I needed to add
> | 
> |      -L../libcruft -lcruft -lreadline -lfftw3 -lfftw3f -lexpat
> | 
> |    octave: (cf. attached file liboctave_symbols.txt.gz)
> |      for manual compilation I needed to add
> | 
> |      -lz -lhdf5 -lreadline -lfreetype -lfontconfig -lfftw3 -lfftw3f -lexpat
> 
> Where is the requirement for -lexpat coming from?

-lexpat "or" -lxml2 is a dependency of -lfontconfig, I don't know if this in a 
general issue or if I need to fight such things for myself?

ME$ otool -L /Applications/Octave.app/Contents/Resources/lib/libfontconfig.dylib
/Applications/Octave.app/Contents/Resources/lib/libfontconfig.dylib:
        /tmp/deps-i386/lib/libfontconfig.1.dylib
        /usr/lib/libiconv.2.dylib
        /tmp/deps-i386/lib/libfreetype.6.dylib
        /tmp/deps-i386/lib/libz.1.dylib
        /usr/lib/libxml2.2.dylib
        /usr/lib/libSystem.B.dylib
        /tmp/deps-i386/lib/libexpat.1.dylib
        /usr/lib/libgcc_s.1.dylib

I'll be back again with results

   Thomas
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 9534.diff
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090818/03c31087/attachment.ksh 

From highegg at gmail.com  Tue Aug 18 14:17:08 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 18 Aug 2009 21:17:08 +0200
Subject: FYI: subasgn argument optimization
In-Reply-To: <19082.57030.28516.263188@segfault.lan>
References: <69d8d540908130741y2cadcc9bw6dd79e4b73dae671@mail.gmail.com>
	<69d8d540908130746k948365dn9cfc8daf80901e78@mail.gmail.com>
	<19077.34069.745516.227226@segfault.lan>
	<69d8d540908170435i7326996x3acebb197b702def@mail.gmail.com>
	<19082.57030.28516.263188@segfault.lan>
Message-ID: <69d8d540908181217h15db851esda67e433a47e1f2@mail.gmail.com>

On Tue, Aug 18, 2009 at 7:03 PM, John W. Eaton<jwe at octave.org> wrote:
> On 17-Aug-2009, Jaroslav Hajek wrote:
>
> | On Fri, Aug 14, 2009 at 5:39 PM, John W. Eaton<jwe at octave.org> wrote:
> | > On 13-Aug-2009, Jaroslav Hajek wrote:
> | >
> | > | PS. This patch rebases octave_class on top of octave_struct.
> | >
> | > It seems that would be a good thing. ?I can no longer remember why
> | > I didn't do it originally. ?I don't think I would have avoided
> | > inheritance unless I had a reason, but then maybe I didn't realize how
> | > similar classes were to structs.
> | >
> |
> | Maybe you had a reason; anyway, my implementation spanned a lot more
> | problems with inheritance than it was worth, so I reverted the
> | rebasing:
> | http://hg.savannah.gnu.org/hgweb/octave/rev/8e5009334661
> | and I just injected code from ov-struct.cc to optimize out a useless
> | copy on nested assignment on fields:
> | obj.x(1) = 1; // does copy x in 3.2.x if x is an object.
> |
> | Of course, the injection is what I wanted to avoid by using
> | inheritance, but right now I think it should be done without altering
> | octave_struct or not done at all.
> | Your implementation handles multidimensional objects, or inheritance,
> | but not both (actually, even constructing such things fails):
> |
> | @foo/foo.m
> | function f = foo ()
> | ? a = struct ("x", {1 2 3 4});
> | ? f = class (a, "foo");
> | end
> |
> | @bar/bar.m
> | function b = bar ()
> | ? a = struct ("y", {1 2 3 4});
> | ? b = class (a, "bar", foo());
> | end
> |
> | octave:1> a = foo
> | octave:2> b = bar
> | error: invalid structure assignment
> | error: called from:
> | error: ? /home/hajek/devel/octave/patches/@bar/bar.m at line 3, column 5
> |
> | the basic problem is (besides missing code support in the nested part
> | of octave_class::subsasgn) that you can't store a single object inside
> | a field of multidimensional Octave_map - all fields must be the same
> | size.
> |
> | Maybe a possible solution would be to not store parent objects as
> | regular fields, but separately; you'd need to hack the field lookup
> | for that and probably also plain () indexing and indexed assignment.
> | But then I still wonder what obj.parent_class_name is supposed to do
> | if obj is multidimensional (normally, you should get a cs-list).
> | Apparently the old OOP model is documented only poorly from Matlab,
> | and I don't have Matlab, so I should probably resist further playing
> | with this part to avoid breaking something.
>
> I wonder how important it is to have multidimensional objects? ?Are
> they really used in practice? ?If so, what code uses them?
>
> jwe
>

Scarcely at best, no doubt. Most often, you probably just have
multidimensional fields. And it should be emphasized that
multidimensional objects will work per se, just not together with
inheritance.


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


From bpabbott at mac.com  Tue Aug 18 18:36:22 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Tue, 18 Aug 2009 19:36:22 -0400
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A8AF498.6000306@gmx.net>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
	<4A867B26.3030508@gmx.net> <19082.54127.595607.366724@segfault.lan>
	<4A8AF498.6000306@gmx.net>
Message-ID: <030AB5F5-E4F5-4FB7-B776-2152E7973630@mac.com>

On Aug 18, 2009, at 2:36 PM, Thomas Treichl wrote:

> John W. Eaton schrieb:
>> On 15-Aug-2009, Thomas Treichl wrote:
>> | John W. Eaton schrieb:
>> | > It would be helpful if people building Octave on Windows and OS X
>> | > systems could configure and build the latest Octave sources on  
>> and
>> | > send a list of symbols that are unresolved when creating the  
>> libcruft,
>> | > liboctave, liboctinterp shared libraries, when linking the Octave
>> | > executable file, and when building the .oct files.
>> | | Here are the results for OS X (currently I cannot tell you  
>> anything about the | CURL and GLPK dependencies - these libs are  
>> not found by ./configure at the | moment - seems because of missing  
>> -lz in the test procedure):
>> I checked in changes that should fix this.  Can you check?
>
> I will John, but I think I need another day for doing that.  
> Yesterday I changed src/Makefile.in for myself and was able to  
> compile all of the Octave sources. This is just FYI, I've attached  
> 9534.diff which is the "hg diff -r 9534 src/Makefile.in >9534.diff".

Thought I'd mention that I've been attempting builds every day or two,  
with the tip below I'm able to build again.

changeset:   9537:592a959b68e5
tag:         tip
user:        John W. Eaton <jwe at octave.org>
date:        Mon Aug 17 17:24:21 2009 -0400
summary:     octave-bug.in, octave-bug.cc.in: update for recent  
configure changes



From lindnerben at gmx.net  Wed Aug 19 03:30:50 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Wed, 19 Aug 2009 10:30:50 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <19082.50054.994278.817764@segfault.lan>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>	<19077.28862.827842.41629@segfault.lan>	<4A868317.10203@gmx.net>	<19081.34869.778915.594647@segfault.lan>	<4A8A63BE.4090300@gmx.net>
	<19082.50054.994278.817764@segfault.lan>
Message-ID: <4A8BB83A.4060408@gmx.net>

John W. Eaton wrote:
> On 18-Aug-2009, Benjamin Lindner wrote:
> 
> | John W. Eaton wrote:
> | > On 15-Aug-2009, Benjamin Lindner wrote:
> | > 
> | > | Now for the undefined reference linker errors:
> | > 
> | > I checked in some additional changes.  I will deal with the mkoctfile
> | > and octave-bug scripts/programs later, but is there anything that I
> | > missed for building libcruft, liboctave, liboctinterp, and the .oct
> | > files?
> | > 
> | 
> | Aside from the pending octave-bug.cc and mkoctfile.cc changes,
> | building and linking completes successfully for mingw32/gcc.
> 
> I checked in changes for octave-bug.cc.in and mkoctfile.cc.in so they
> should build now.  Are there still problems?  BTW, this is why I think
> we should eliminate the script versions of these files.  It would be
> easier to ensure consistency if we didn't have both shell script and
> C++ versions...
> 
> jwe
> 

building from the following tip

changeset:   9545:8670e55078fd
tag:         tip
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Mon Aug 17 14:46:18 2009 +0200
summary:     allow constructing octave_value_list from size

build fails at build-octave.cc with the attached errors.
I guess all substitution variables should be prefixed with 
'OCTAVE_CONF_' as in the attached changeset.

Furthermore, there is a '|' character where it should be a '+' character 
in line 254 in mkoctfile.cc.in -> see changeset.


However, linking liboctinterp.dll now again fails with the following error
Creating library file: 
liboctinterp.dll.a../libcruft/blas-xtra/xerbla.o:xerbla.f:(.text+0x50): 
undefined reference to `_gfortran_st_write'
../libcruft/blas-xtra/xerbla.o:xerbla.f:(.text+0x67): undefined 
reference to `_gfortran_transfer_character'
../libcruft/blas-xtra/xerbla.o:xerbla.f:(.text+0x7e): undefined 
reference to `_gfortran_transfer_integer'
../libcruft/blas-xtra/xerbla.o:xerbla.f:(.text+0x86): undefined 
reference to `_gfortran_st_write_done'

Since xerbla.o is linked directly into liboctinterp.dll, $(FLIBS) is 
required in the link dependencies as

diff -r 87d36823eb0d src/Makefile.in
--- a/src/Makefile.in   Wed Aug 19 10:09:44 2009 +0200
+++ b/src/Makefile.in   Wed Aug 19 10:27:04 2009 +0200
@@ -331,7 +331,7 @@
    $(HDF5_LDFLAGS) $(HDF5_LIBS) $(Z_LDFLAGS) $(Z_LIBS) \
    $(OPENGL_LIBS) $(X11_LIBS) $(CARBON_LIBS) \
    $(READLINE_LIBS) \
-  $(LIBS)
+  $(FLIBS) $(LIBS)

  OCT_LINK_DEPS = $(RLD_FLAG) -L. $(LIBOCTINTERP) \
    -L../liboctave $(LIBOCTAVE) \


The rest builds & links fine.

benjamin






-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: octave-bug-mkoctfile-changes.changeset
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090819/6a3ff8a5/attachment-0001.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bug-octave-errors.txt
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090819/6a3ff8a5/attachment-0001.txt 

From Thomas.Treichl at gmx.net  Wed Aug 19 15:34:54 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Wed, 19 Aug 2009 22:34:54 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <030AB5F5-E4F5-4FB7-B776-2152E7973630@mac.com>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
	<4A867B26.3030508@gmx.net> <19082.54127.595607.366724@segfault.lan>
	<4A8AF498.6000306@gmx.net>
	<030AB5F5-E4F5-4FB7-B776-2152E7973630@mac.com>
Message-ID: <4A8C61EE.8040706@gmx.net>

Ben Abbott schrieb:
> On Aug 18, 2009, at 2:36 PM, Thomas Treichl wrote:
> 
>> John W. Eaton schrieb:
>>> On 15-Aug-2009, Thomas Treichl wrote:
>>> | John W. Eaton schrieb:
>>> | > It would be helpful if people building Octave on Windows and OS X
>>> | > systems could configure and build the latest Octave sources on and
>>> | > send a list of symbols that are unresolved when creating the 
>>> libcruft,
>>> | > liboctave, liboctinterp shared libraries, when linking the Octave
>>> | > executable file, and when building the .oct files.
>>> | | Here are the results for OS X (currently I cannot tell you 
>>> anything about the | CURL and GLPK dependencies - these libs are not 
>>> found by ./configure at the | moment - seems because of missing -lz 
>>> in the test procedure):
>>> I checked in changes that should fix this.  Can you check?
>>
>> I will John, but I think I need another day for doing that. Yesterday 
>> I changed src/Makefile.in for myself and was able to compile all of 
>> the Octave sources. This is just FYI, I've attached 9534.diff which is 
>> the "hg diff -r 9534 src/Makefile.in >9534.diff".
> 
> Thought I'd mention that I've been attempting builds every day or two, 
> with the tip below I'm able to build again.
> 
> changeset:   9537:592a959b68e5
> tag:         tip
> user:        John W. Eaton <jwe at octave.org>
> date:        Mon Aug 17 17:24:21 2009 -0400
> summary:     octave-bug.in, octave-bug.cc.in: update for recent 
> configure changes

Hi Ben, hello John,

this sounds good but I still have some problems: In the ./configure test 
libarpack is not found anymore because my libarpack is compiled against 
$(BLAS_LIBS) ?and? $(LAPACK_LIBS). I changed configure.in - like attached in 
configure.in.diff - now I successfully pass this configure test. BTW, I'm 
working with

   MacMini:~/Development/octave Me$ hg tip
   changeset:   9549:ed34b1da0e26
   tag:         tip
   user:        Jaroslav Hajek <highegg at gmail.com>
   date:        Wed Aug 19 16:24:33 2009 +0200
   summary:     zero matrix assignment fix

I was not able to fix that -lexpat problem but I can easily add -lexpat to 
LDFLAGS at the moment. With this flag I'm able to link liboctinterp.dylib and 
octave without any further modifications.

Linking *.oct files still doesn't work. I attached symbols.amd.txt which is the 
error output of linking amd.oct. To quickly solve that last problem I changed 
src/Makefile.in, cf. Makefile.in.diff. After this last change I was able to get 
through the build procedure.

Best regards

   Thomas
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: configure.in.diff
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090819/dcca0a3d/attachment.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: symbols.amd.txt
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090819/dcca0a3d/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Makefile.in.diff
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090819/dcca0a3d/attachment-0001.ksh 

From bpabbott at mac.com  Wed Aug 19 17:13:32 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Wed, 19 Aug 2009 18:13:32 -0400
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A8C61EE.8040706@gmx.net>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
	<4A867B26.3030508@gmx.net> <19082.54127.595607.366724@segfault.lan>
	<4A8AF498.6000306@gmx.net>
	<030AB5F5-E4F5-4FB7-B776-2152E7973630@mac.com>
	<4A8C61EE.8040706@gmx.net>
Message-ID: <96361AD8-3C95-451A-804E-30E1F1430F08@mac.com>


On Aug 19, 2009, at 4:34 PM, Thomas Treichl wrote:

> Ben Abbott schrieb:
>> On Aug 18, 2009, at 2:36 PM, Thomas Treichl wrote:
>>> John W. Eaton schrieb:
>>>> On 15-Aug-2009, Thomas Treichl wrote:
>>>> | John W. Eaton schrieb:
>>>> | > It would be helpful if people building Octave on Windows and  
>>>> OS X
>>>> | > systems could configure and build the latest Octave sources  
>>>> on and
>>>> | > send a list of symbols that are unresolved when creating the  
>>>> libcruft,
>>>> | > liboctave, liboctinterp shared libraries, when linking the  
>>>> Octave
>>>> | > executable file, and when building the .oct files.
>>>> | | Here are the results for OS X (currently I cannot tell you  
>>>> anything about the | CURL and GLPK dependencies - these libs are  
>>>> not found by ./configure at the | moment - seems because of  
>>>> missing -lz in the test procedure):
>>>> I checked in changes that should fix this.  Can you check?
>>>
>>> I will John, but I think I need another day for doing that.  
>>> Yesterday I changed src/Makefile.in for myself and was able to  
>>> compile all of the Octave sources. This is just FYI, I've attached  
>>> 9534.diff which is the "hg diff -r 9534 src/Makefile.in >9534.diff".
>> Thought I'd mention that I've been attempting builds every day or  
>> two, with the tip below I'm able to build again.
>> changeset:   9537:592a959b68e5
>> tag:         tip
>> user:        John W. Eaton <jwe at octave.org>
>> date:        Mon Aug 17 17:24:21 2009 -0400
>> summary:     octave-bug.in, octave-bug.cc.in: update for recent  
>> configure changes
>
> Hi Ben, hello John,
>
> this sounds good but I still have some problems: In the ./configure  
> test libarpack is not found anymore because my libarpack is compiled  
> against $(BLAS_LIBS) ?and? $(LAPACK_LIBS). I changed configure.in -  
> like attached in configure.in.diff - now I successfully pass this  
> configure test. BTW, I'm working with
>

I don't have much spare time for Octave at the moment, but ... my  
attempt to build from sources I pulled on the 17th failed while  
building liboctinterp.dylib

Undefined symbols:
  "__gfortran_st_write", referenced from:
      _xerbla_ in xerbla.o
  "__gfortran_transfer_character", referenced from:
      _xerbla_ in xerbla.o
  "__gfortran_st_write_done", referenced from:
      _xerbla_ in xerbla.o
  "__gfortran_transfer_integer", referenced from:
      _xerbla_ in xerbla.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [liboctinterp.dylib] Error 1
make[1]: *** [src] Error 2
make: *** [all] Error 2

$ hg tip
changeset:   9546:8670e55078fd
tag:         tip
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Mon Aug 17 14:46:18 2009 +0200
summary:     allow constructing octave_value_list from size

Ben


From thomas.weber.mail at gmail.com  Thu Aug 20 11:08:58 2009
From: thomas.weber.mail at gmail.com (Thomas Weber)
Date: Thu, 20 Aug 2009 18:08:58 +0200
Subject: Empty graphic file in 3.2.2 tarball
Message-ID: <20090820160858.GA29666@atlan>

Hi, 

the file 
	doc/interpreter/HTML/voronoi.png
in the tarball has size 0. 

I can't figure out why this was happening.

	Thomas

From octave at nomad.inbox5.com  Thu Aug 20 16:44:32 2009
From: octave at nomad.inbox5.com (Rik)
Date: Thu, 20 Aug 2009 14:44:32 -0700
Subject: linking liboctave fails
In-Reply-To: <mailman.3530.1250784514.29411.octave-maintainers@octave.org>
References: <mailman.3530.1250784514.29411.octave-maintainers@octave.org>
Message-ID: <MTAwMDAwMi5ub21hZA.1250804680@quikprotect>

8/20/09

Yet more issues with the configuration files and building.  I don't have
the development package for libcurl.  This is fine and the configuration
scripts give me the following message:
configure: WARNING: cURL library not found.  The urlread and urlwrite
functions will be disabled.

That is indeed what used to happen but now the build process ignores the
configure script and attempts to build urlwrite anyways which results in:

g++ -shared -o urlwrite.oct pic/urlwrite.o -Wl,-rpath
-Wl,/home/rik/downloads/movies/local/lib/octave-3.1.55 -L. -loctinterp
-L../liboctave -loctave -L../libcruft -lcruft  -lcurl
/usr/bin/ld: cannot find -lcurl
collect2: ld returned 1 exit status
make[2]: *** [urlwrite.oct] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/home/rik/wip/Projects_Mine/octave-dev/src'

I hope someone can restore the correct build behavior.

Cheers,
Rik

From highegg at gmail.com  Mon Aug 24 03:58:46 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 24 Aug 2009 10:58:46 +0200
Subject: 3.2.3 RC1
Message-ID: <69d8d540908240158v634b5d0aj71554f0505a78395@mail.gmail.com>

hi all,

I want to make 3.2.3 in the first half of September. The 1st release
candidate tarballs for 3.2.3 are available at:
http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/

changes since 3.2.2:

changeset:   9380:193174bc5107
user:        John W. Eaton <jwe at octave.org>
date:        Wed Jul 08 13:49:21 2009 -0400
summary:     dim-vector.h: dim vectors always have two dimensions

changeset:   9381:4290384284b7
user:        John W. Eaton <jwe at octave.org>
date:        Wed Jul 08 14:06:53 2009 -0400
summary:     pt-assign.cc (maybe_warn_former_built_in_variable): improve message

changeset:   9382:cd95695a0a89
user:        John W. Eaton <jwe at octave.org>
date:        Thu Jul 09 15:04:34 2009 -0400
summary:     configure.in: don't use system strftime on MinGW systems

changeset:   9383:941b8414b99e
user:        John W. Eaton <jwe at octave.org>
date:        Sat Jul 11 12:46:10 2009 -0400
summary:     file-ops.cc (file_ops::symlink, file_ops::readlink):
avoid incorrectly sized buffer

changeset:   9384:44300eb51817
user:        John W. Eaton <jwe at octave.org>
date:        Thu Jul 16 11:56:44 2009 -0400
summary:     graphics.cc (get_array_limits): require min_pos value to
be greater than zero

changeset:   9385:9aea00e4e000
user:        John W. Eaton <jwe at octave.org>
date:        Sat Jul 25 16:16:59 2009 +0200
summary:     Makeconf.in (MAGICK_LIBS): Don't pass --ldflags to $(MAGICK_CONFIG)

changeset:   9386:6ddb81224550
user:        John W. Eaton <jwe at octave.org>
date:        Sat Jul 25 16:17:27 2009 +0200
summary:     __go_draw_axes__.m: also use layer property for plot border

changeset:   9387:b308b2e12f04
user:        Benjamin Lindner <lindnerb at users.sourceforge.net>
date:        Sat Jul 25 16:20:05 2009 +0200
summary:     determine correct image bitwidth in __magick_read__.cc

changeset:   9388:a8a44f20ef3b
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Sat Jul 25 16:20:35 2009 +0200
summary:     fix signed integer shift

changeset:   9389:3602403af9b8
user:        Aleksej Saushev <asau at inbox.ru>
date:        Sat Jul 25 16:21:51 2009 +0200
summary:     initialize floating point values properly for NetBSD systems

changeset:   9390:83d604a4e803
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Sat Jul 25 16:22:40 2009 +0200
summary:     fix Cholesky updating with scalars

changeset:   9391:c4f89df90e43
user:        John W. Eaton <jwe at octave.org>
date:        Sat Jul 25 16:26:01 2009 +0200
summary:     avoid complex -> real conversion when constructing arrays with []

changeset:   9392:6a6779e895d4
user:        John W. Eaton <jwe at octave.org>
date:        Tue Aug 04 09:52:53 2009 +0200
summary:     correctly parse things like '@(){1 2}'

changeset:   9393:18b8a3aa034c
user:        John W. Eaton <jwe at octave.org>
date:        Tue Aug 04 09:55:38 2009 +0200
summary:     use complex function for acos mapper if arg is out of range [-1, 1]

changeset:   9394:f1dd244757cd
user:        Ben Abbott <bpabbott at mac.com>
date:        Thu Aug 06 07:18:53 2009 +0200
summary:     __go_draw_axes__.m: Fix ticklabels specified as 2D character array.

changeset:   9395:54a3fa5d4376
user:        Ben Abbott <bpabbott at mac.com>
date:        Thu Aug 06 07:30:34 2009 +0200
summary:     Avoid the flickering x11 window seen with rapid gnuplot updates.

changeset:   9396:9107c882f193
user:        Olli Saarela <olli.saarela at gmail.com>
date:        Thu Aug 06 07:31:45 2009 +0200
summary:     __gnuplot_get_var__: if read fails to return data, sleep
before trying again

changeset:   9397:16181105aeb6
user:        Pieter Eendebak <pieter.eendebak at gmail.com>
date:        Thu Aug 06 07:32:53 2009 +0200
summary:     support cellstrs in setxor

changeset:   9398:21038fd51788
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Fri Aug 07 08:11:49 2009 +0200
summary:     implant tree_index_expression::lvalue from development version

changeset:   9399:0014ff1747a6
user:        John W. Eaton <jwe at octave.org>
date:        Fri Aug 07 08:13:22 2009 +0200
summary:     use key list order for iterating through map with for loop

changeset:   9400:3db13615d39a
user:        John W. Eaton <jwe at octave.org>
date:        Fri Aug 07 08:15:27 2009 +0200
summary:     handle null matrix assignment for diagonal and permutation matrices

changeset:   9401:3a4da80f4adc
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Fri Aug 07 08:22:13 2009 +0200
summary:     complete change d5570d4b1116

changeset:   9402:1d5a487a01cf
user:        John W. Eaton <jwe at octave.org>
date:        Mon Aug 10 11:14:46 2009 +0200
summary:     parse.y (Fevalin): also return output from CATCH expression

changeset:   9403:a29f3eba78a2
user:        John W. Eaton <jwe at octave.org>
date:        Thu Aug 13 07:56:00 2009 +0200
summary:     new option, --no-window-system

changeset:   9404:1347fcb231bd
user:        John W. Eaton <jwe at octave.org>
date:        Sun Aug 23 11:09:17 2009 +0200
summary:     dlmread: perform tilde expansion to filename argument

changeset:   9405:3a65f1038bdb
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Sun Aug 23 11:10:05 2009 +0200
summary:     fix some functions help markup

changeset:   9406:4963bb455582
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Sun Aug 23 11:10:35 2009 +0200
summary:     fix typos in complex xgemm

changeset:   9407:1371eecefd99
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Sun Aug 23 11:11:27 2009 +0200
summary:     make single prec. matrix mutliply tests really single

changeset:   9408:9e66af7e1593
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Sun Aug 23 11:11:27 2009 +0200
summary:     more fixes & tests for matrix multiply

changeset:   9409:f0d18d74a519
user:        John W. Eaton <jwe at octave.org>
date:        Sun Aug 23 11:12:16 2009 +0200
summary:     acx_blas_f77_func.m4 (ACX_BLAS_F77_FUNC): Save and restore LIBS

changeset:   9410:c3d37d2a2b55
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Sun Aug 23 11:12:35 2009 +0200
summary:     zero matrix assignment fix

changeset:   9411:d208ae6e9d74
user:        David Bateman <dbateman at free.fr>
date:        Mon Aug 24 10:02:47 2009 +0200
summary:     Fix test for setting of datasource properties. Add the
edgecolor property to contours

changeset:   9412:8e69b1d41c03
tag:         qparent
user:        Jaroslav Hajek <highegg at gmail.com>
date:        Mon Aug 24 10:06:52 2009 +0200
summary:     fix typo in acx_blas_f77_func.m4

In case your favorite patch is missing, now would be a good time to mention it.

regards

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

From dbateman at free.fr  Mon Aug 24 04:13:17 2009
From: dbateman at free.fr (dbateman)
Date: Mon, 24 Aug 2009 02:13:17 -0700 (PDT)
Subject: 3.2.3 RC1
In-Reply-To: <69d8d540908240158v634b5d0aj71554f0505a78395@mail.gmail.com>
References: <69d8d540908240158v634b5d0aj71554f0505a78395@mail.gmail.com>
Message-ID: <25112855.post@talk.nabble.com>


Could we make a release with just 9406 immediately. Without this patch the
3.2.x release is really too buggy to use..

D.



Jaroslav Hajek-2 wrote:
> 
> hi all,
> 
> I want to make 3.2.3 in the first half of September. The 1st release
> candidate tarballs for 3.2.3 are available at:
> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> 
> changes since 3.2.2:
> 
> changeset:   9380:193174bc5107
> user:        John W. Eaton <jwe at octave.org>
> date:        Wed Jul 08 13:49:21 2009 -0400
> summary:     dim-vector.h: dim vectors always have two dimensions
> 
> changeset:   9381:4290384284b7
> user:        John W. Eaton <jwe at octave.org>
> date:        Wed Jul 08 14:06:53 2009 -0400
> summary:     pt-assign.cc (maybe_warn_former_built_in_variable): improve
> message
> 
> changeset:   9382:cd95695a0a89
> user:        John W. Eaton <jwe at octave.org>
> date:        Thu Jul 09 15:04:34 2009 -0400
> summary:     configure.in: don't use system strftime on MinGW systems
> 
> changeset:   9383:941b8414b99e
> user:        John W. Eaton <jwe at octave.org>
> date:        Sat Jul 11 12:46:10 2009 -0400
> summary:     file-ops.cc (file_ops::symlink, file_ops::readlink):
> avoid incorrectly sized buffer
> 
> changeset:   9384:44300eb51817
> user:        John W. Eaton <jwe at octave.org>
> date:        Thu Jul 16 11:56:44 2009 -0400
> summary:     graphics.cc (get_array_limits): require min_pos value to
> be greater than zero
> 
> changeset:   9385:9aea00e4e000
> user:        John W. Eaton <jwe at octave.org>
> date:        Sat Jul 25 16:16:59 2009 +0200
> summary:     Makeconf.in (MAGICK_LIBS): Don't pass --ldflags to
> $(MAGICK_CONFIG)
> 
> changeset:   9386:6ddb81224550
> user:        John W. Eaton <jwe at octave.org>
> date:        Sat Jul 25 16:17:27 2009 +0200
> summary:     __go_draw_axes__.m: also use layer property for plot border
> 
> changeset:   9387:b308b2e12f04
> user:        Benjamin Lindner <lindnerb at users.sourceforge.net>
> date:        Sat Jul 25 16:20:05 2009 +0200
> summary:     determine correct image bitwidth in __magick_read__.cc
> 
> changeset:   9388:a8a44f20ef3b
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Sat Jul 25 16:20:35 2009 +0200
> summary:     fix signed integer shift
> 
> changeset:   9389:3602403af9b8
> user:        Aleksej Saushev <asau at inbox.ru>
> date:        Sat Jul 25 16:21:51 2009 +0200
> summary:     initialize floating point values properly for NetBSD systems
> 
> changeset:   9390:83d604a4e803
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Sat Jul 25 16:22:40 2009 +0200
> summary:     fix Cholesky updating with scalars
> 
> changeset:   9391:c4f89df90e43
> user:        John W. Eaton <jwe at octave.org>
> date:        Sat Jul 25 16:26:01 2009 +0200
> summary:     avoid complex -> real conversion when constructing arrays
> with []
> 
> changeset:   9392:6a6779e895d4
> user:        John W. Eaton <jwe at octave.org>
> date:        Tue Aug 04 09:52:53 2009 +0200
> summary:     correctly parse things like '@(){1 2}'
> 
> changeset:   9393:18b8a3aa034c
> user:        John W. Eaton <jwe at octave.org>
> date:        Tue Aug 04 09:55:38 2009 +0200
> summary:     use complex function for acos mapper if arg is out of range
> [-1, 1]
> 
> changeset:   9394:f1dd244757cd
> user:        Ben Abbott <bpabbott at mac.com>
> date:        Thu Aug 06 07:18:53 2009 +0200
> summary:     __go_draw_axes__.m: Fix ticklabels specified as 2D character
> array.
> 
> changeset:   9395:54a3fa5d4376
> user:        Ben Abbott <bpabbott at mac.com>
> date:        Thu Aug 06 07:30:34 2009 +0200
> summary:     Avoid the flickering x11 window seen with rapid gnuplot
> updates.
> 
> changeset:   9396:9107c882f193
> user:        Olli Saarela <olli.saarela at gmail.com>
> date:        Thu Aug 06 07:31:45 2009 +0200
> summary:     __gnuplot_get_var__: if read fails to return data, sleep
> before trying again
> 
> changeset:   9397:16181105aeb6
> user:        Pieter Eendebak <pieter.eendebak at gmail.com>
> date:        Thu Aug 06 07:32:53 2009 +0200
> summary:     support cellstrs in setxor
> 
> changeset:   9398:21038fd51788
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Fri Aug 07 08:11:49 2009 +0200
> summary:     implant tree_index_expression::lvalue from development
> version
> 
> changeset:   9399:0014ff1747a6
> user:        John W. Eaton <jwe at octave.org>
> date:        Fri Aug 07 08:13:22 2009 +0200
> summary:     use key list order for iterating through map with for loop
> 
> changeset:   9400:3db13615d39a
> user:        John W. Eaton <jwe at octave.org>
> date:        Fri Aug 07 08:15:27 2009 +0200
> summary:     handle null matrix assignment for diagonal and permutation
> matrices
> 
> changeset:   9401:3a4da80f4adc
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Fri Aug 07 08:22:13 2009 +0200
> summary:     complete change d5570d4b1116
> 
> changeset:   9402:1d5a487a01cf
> user:        John W. Eaton <jwe at octave.org>
> date:        Mon Aug 10 11:14:46 2009 +0200
> summary:     parse.y (Fevalin): also return output from CATCH expression
> 
> changeset:   9403:a29f3eba78a2
> user:        John W. Eaton <jwe at octave.org>
> date:        Thu Aug 13 07:56:00 2009 +0200
> summary:     new option, --no-window-system
> 
> changeset:   9404:1347fcb231bd
> user:        John W. Eaton <jwe at octave.org>
> date:        Sun Aug 23 11:09:17 2009 +0200
> summary:     dlmread: perform tilde expansion to filename argument
> 
> changeset:   9405:3a65f1038bdb
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Sun Aug 23 11:10:05 2009 +0200
> summary:     fix some functions help markup
> 
> changeset:   9406:4963bb455582
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Sun Aug 23 11:10:35 2009 +0200
> summary:     fix typos in complex xgemm
> 
> changeset:   9407:1371eecefd99
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Sun Aug 23 11:11:27 2009 +0200
> summary:     make single prec. matrix mutliply tests really single
> 
> changeset:   9408:9e66af7e1593
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Sun Aug 23 11:11:27 2009 +0200
> summary:     more fixes & tests for matrix multiply
> 
> changeset:   9409:f0d18d74a519
> user:        John W. Eaton <jwe at octave.org>
> date:        Sun Aug 23 11:12:16 2009 +0200
> summary:     acx_blas_f77_func.m4 (ACX_BLAS_F77_FUNC): Save and restore
> LIBS
> 
> changeset:   9410:c3d37d2a2b55
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Sun Aug 23 11:12:35 2009 +0200
> summary:     zero matrix assignment fix
> 
> changeset:   9411:d208ae6e9d74
> user:        David Bateman <dbateman at free.fr>
> date:        Mon Aug 24 10:02:47 2009 +0200
> summary:     Fix test for setting of datasource properties. Add the
> edgecolor property to contours
> 
> changeset:   9412:8e69b1d41c03
> tag:         qparent
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Mon Aug 24 10:06:52 2009 +0200
> summary:     fix typo in acx_blas_f77_func.m4
> 
> In case your favorite patch is missing, now would be a good time to
> mention it.
> 
> regards
> 
> -- 
> RNDr. Jaroslav Hajek
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
> 
> 

-- 
View this message in context: http://www.nabble.com/3.2.3-RC1-tp25112724p25112855.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.


From tmacchant at yahoo.co.jp  Mon Aug 24 04:48:37 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Mon, 24 Aug 2009 18:48:37 +0900 (JST)
Subject: 3.2.3 RC1
In-Reply-To: <69d8d540908240158v634b5d0aj71554f0505a78395@mail.gmail.com>
Message-ID: <20090824094837.30977.qmail@web3802.mail.bbt.yahoo.co.jp>

Hello

make -f octMakefile all
make[1]: Entering directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
(cd ../../octave-3.2.3-RC1; autoconf --force)
/bin/autoconf-2.61: line 582: /usr/local/bin/autom4te-2.61: No such file or directory
/bin/autoconf-2.61: line 582: exec: /usr/local/bin/autom4te-2.61: cannot execute: No such file or
directory
make[1]: *** [configure] Error 126
make[1]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
make: *** [all] Error 2

/bin/autoconf-2.61 ??

Had not the issue of autoconf-2.6  been discussed and resolved ?

Regards

Tatsuro 

--- Jaroslav Hajek <highegg at gmail.com> wrote:

> hi all,
> 
> I want to make 3.2.3 in the first half of September. The 1st release
> candidate tarballs for 3.2.3 are available at:
> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> 
> changes since 3.2.2:
> 
> changeset:   9380:193174bc5107
> user:        John W. Eaton <jwe at octave.org>
> date:        Wed Jul 08 13:49:21 2009 -0400
> summary:     dim-vector.h: dim vectors always have two dimensions
> 
> changeset:   9381:4290384284b7
> user:        John W. Eaton <jwe at octave.org>
> date:        Wed Jul 08 14:06:53 2009 -0400
> summary:     pt-assign.cc (maybe_warn_former_built_in_variable): improve message
> 
> changeset:   9382:cd95695a0a89
> user:        John W. Eaton <jwe at octave.org>
> date:        Thu Jul 09 15:04:34 2009 -0400
> summary:     configure.in: don't use system strftime on MinGW systems
> 
> changeset:   9383:941b8414b99e
> user:        John W. Eaton <jwe at octave.org>
> date:        Sat Jul 11 12:46:10 2009 -0400
> summary:     file-ops.cc (file_ops::symlink, file_ops::readlink):
> avoid incorrectly sized buffer
> 
> changeset:   9384:44300eb51817
> user:        John W. Eaton <jwe at octave.org>
> date:        Thu Jul 16 11:56:44 2009 -0400
> summary:     graphics.cc (get_array_limits): require min_pos value to
> be greater than zero
> 
> changeset:   9385:9aea00e4e000
> user:        John W. Eaton <jwe at octave.org>
> date:        Sat Jul 25 16:16:59 2009 +0200
> summary:     Makeconf.in (MAGICK_LIBS): Don't pass --ldflags to $(MAGICK_CONFIG)
> 
> changeset:   9386:6ddb81224550
> user:        John W. Eaton <jwe at octave.org>
> date:        Sat Jul 25 16:17:27 2009 +0200
> summary:     __go_draw_axes__.m: also use layer property for plot border
> 
> changeset:   9387:b308b2e12f04
> user:        Benjamin Lindner <lindnerb at users.sourceforge.net>
> date:        Sat Jul 25 16:20:05 2009 +0200
> summary:     determine correct image bitwidth in __magick_read__.cc
> 
> changeset:   9388:a8a44f20ef3b
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Sat Jul 25 16:20:35 2009 +0200
> summary:     fix signed integer shift
> 
> changeset:   9389:3602403af9b8
> user:        Aleksej Saushev <asau at inbox.ru>
> date:        Sat Jul 25 16:21:51 2009 +0200
> summary:     initialize floating point values properly for NetBSD systems
> 
> changeset:   9390:83d604a4e803
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Sat Jul 25 16:22:40 2009 +0200
> summary:     fix Cholesky updating with scalars
> 
> changeset:   9391:c4f89df90e43
> user:        John W. Eaton <jwe at octave.org>
> date:        Sat Jul 25 16:26:01 2009 +0200
> summary:     avoid complex -> real conversion when constructing arrays with []
> 
> changeset:   9392:6a6779e895d4
> user:        John W. Eaton <jwe at octave.org>
> date:        Tue Aug 04 09:52:53 2009 +0200
> summary:     correctly parse things like '@(){1 2}'
> 
> changeset:   9393:18b8a3aa034c
> user:        John W. Eaton <jwe at octave.org>
> date:        Tue Aug 04 09:55:38 2009 +0200
> summary:     use complex function for acos mapper if arg is out of range [-1, 1]
> 
> changeset:   9394:f1dd244757cd
> user:        Ben Abbott <bpabbott at mac.com>
> date:        Thu Aug 06 07:18:53 2009 +0200
> summary:     __go_draw_axes__.m: Fix ticklabels specified as 2D character array.
> 
> changeset:   9395:54a3fa5d4376
> user:        Ben Abbott <bpabbott at mac.com>
> date:        Thu Aug 06 07:30:34 2009 +0200
> summary:     Avoid the flickering x11 window seen with rapid gnuplot updates.
> 
> changeset:   9396:9107c882f193
> user:        Olli Saarela <olli.saarela at gmail.com>
> date:        Thu Aug 06 07:31:45 2009 +0200
> summary:     __gnuplot_get_var__: if read fails to return data, sleep
> before trying again
> 
> changeset:   9397:16181105aeb6
> user:        Pieter Eendebak <pieter.eendebak at gmail.com>
> date:        Thu Aug 06 07:32:53 2009 +0200
> summary:     support cellstrs in setxor
> 
> changeset:   9398:21038fd51788
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Fri Aug 07 08:11:49 2009 +0200
> summary:     implant tree_index_expression::lvalue from development version
> 
> changeset:   9399:0014ff1747a6
> user:        John W. Eaton <jwe at octave.org>
> date:        Fri Aug 07 08:13:22 2009 +0200
> summary:     use key list order for iterating through map with for loop
> 
> changeset:   9400:3db13615d39a
> user:        John W. Eaton <jwe at octave.org>
> date:        Fri Aug 07 08:15:27 2009 +0200
> summary:     handle null matrix assignment for diagonal and permutation matrices
> 
> changeset:   9401:3a4da80f4adc
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Fri Aug 07 08:22:13 2009 +0200
> summary:     complete change d5570d4b1116
> 
> changeset:   9402:1d5a487a01cf
> user:        John W. Eaton <jwe at octave.org>
> date:        Mon Aug 10 11:14:46 2009 +0200
> summary:     parse.y (Fevalin): also return output from CATCH expression
> 
> changeset:   9403:a29f3eba78a2
> user:        John W. Eaton <jwe at octave.org>
> date:        Thu Aug 13 07:56:00 2009 +0200
> summary:     new option, --no-window-system
> 
> changeset:   9404:1347fcb231bd
> user:        John W. Eaton <jwe at octave.org>
> date:        Sun Aug 23 11:09:17 2009 +0200
> summary:     dlmread: perform tilde expansion to filename argument
> 
> changeset:   9405:3a65f1038bdb
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Sun Aug 23 11:10:05 2009 +0200
> summary:     fix some functions help markup
> 
> changeset:   9406:4963bb455582
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Sun Aug 23 11:10:35 2009 +0200
> summary:     fix typos in complex xgemm
> 
> changeset:   9407:1371eecefd99
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Sun Aug 23 11:11:27 2009 +0200
> summary:     make single prec. matrix mutliply tests really single
> 
> changeset:   9408:9e66af7e1593
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Sun Aug 23 11:11:27 2009 +0200
> summary:     more fixes & tests for matrix multiply
> 
> changeset:   9409:f0d18d74a519
> user:        John W. Eaton <jwe at octave.org>
> date:        Sun Aug 23 11:12:16 2009 +0200
> summary:     acx_blas_f77_func.m4 (ACX_BLAS_F77_FUNC): Save and restore LIBS
> 
> changeset:   9410:c3d37d2a2b55
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Sun Aug 23 11:12:35 2009 +0200
> summary:     zero matrix assignment fix
> 
> changeset:   9411:d208ae6e9d74
> user:        David Bateman <dbateman at free.fr>
> date:        Mon Aug 24 10:02:47 2009 +0200
> summary:     Fix test for setting of datasource properties. Add the
> edgecolor property to contours
> 
> changeset:   9412:8e69b1d41c03
> tag:         qparent
> user:        Jaroslav Hajek <highegg at gmail.com>
> date:        Mon Aug 24 10:06:52 2009 +0200
> summary:     fix typo in acx_blas_f77_func.m4
> 
> In case your favorite patch is missing, now would be a good time to mention it.
> 
> regards
> 
> -- 
> RNDr. Jaroslav Hajek
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
> 


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

From tmacchant at yahoo.co.jp  Mon Aug 24 05:17:37 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Mon, 24 Aug 2009 19:17:37 +0900 (JST)
Subject: 3.2.3 RC1
In-Reply-To: <20090824094837.30977.qmail@web3802.mail.bbt.yahoo.co.jp>
Message-ID: <20090824101737.56593.qmail@web3808.mail.bbt.yahoo.co.jp>

Hello

Sorry I have misunderstood the matter.
That was autoconf-2.64.

I have met the same error on the latest repository source (24 Aug 2009 10:06:52 +0200).

I have not met this error at 23 Aug 2009 11:12:35 +0200.

Is this a bug of autoconf-2.61 of msys?

/usr/local/bin/autom4te-2.61
is the problem

I have struggle them for a while.

Regards

Tatsuro
--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> make -f octMakefile all
> make[1]: Entering directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> (cd ../../octave-3.2.3-RC1; autoconf --force)
> /bin/autoconf-2.61: line 582: /usr/local/bin/autom4te-2.61: No such file or directory
> /bin/autoconf-2.61: line 582: exec: /usr/local/bin/autom4te-2.61: cannot execute: No such file
> or
> directory
> make[1]: *** [configure] Error 126
> make[1]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> make: *** [all] Error 2
> 
> /bin/autoconf-2.61 ??
> 
> Had not the issue of autoconf-2.6  been discussed and resolved ?
> 
> Regards
> 
> Tatsuro 
> 
> --- Jaroslav Hajek <highegg at gmail.com> wrote:
> 
> > hi all,
> > 
> > I want to make 3.2.3 in the first half of September. The 1st release
> > candidate tarballs for 3.2.3 are available at:
> > http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> > 
> > changes since 3.2.2:
> > 
> > changeset:   9380:193174bc5107
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Wed Jul 08 13:49:21 2009 -0400
> > summary:     dim-vector.h: dim vectors always have two dimensions
> > 
> > changeset:   9381:4290384284b7
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Wed Jul 08 14:06:53 2009 -0400
> > summary:     pt-assign.cc (maybe_warn_former_built_in_variable): improve message
> > 
> > changeset:   9382:cd95695a0a89
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Thu Jul 09 15:04:34 2009 -0400
> > summary:     configure.in: don't use system strftime on MinGW systems
> > 
> > changeset:   9383:941b8414b99e
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Sat Jul 11 12:46:10 2009 -0400
> > summary:     file-ops.cc (file_ops::symlink, file_ops::readlink):
> > avoid incorrectly sized buffer
> > 
> > changeset:   9384:44300eb51817
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Thu Jul 16 11:56:44 2009 -0400
> > summary:     graphics.cc (get_array_limits): require min_pos value to
> > be greater than zero
> > 
> > changeset:   9385:9aea00e4e000
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Sat Jul 25 16:16:59 2009 +0200
> > summary:     Makeconf.in (MAGICK_LIBS): Don't pass --ldflags to $(MAGICK_CONFIG)
> > 
> > changeset:   9386:6ddb81224550
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Sat Jul 25 16:17:27 2009 +0200
> > summary:     __go_draw_axes__.m: also use layer property for plot border
> > 
> > changeset:   9387:b308b2e12f04
> > user:        Benjamin Lindner <lindnerb at users.sourceforge.net>
> > date:        Sat Jul 25 16:20:05 2009 +0200
> > summary:     determine correct image bitwidth in __magick_read__.cc
> > 
> > changeset:   9388:a8a44f20ef3b
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Sat Jul 25 16:20:35 2009 +0200
> > summary:     fix signed integer shift
> > 
> > changeset:   9389:3602403af9b8
> > user:        Aleksej Saushev <asau at inbox.ru>
> > date:        Sat Jul 25 16:21:51 2009 +0200
> > summary:     initialize floating point values properly for NetBSD systems
> > 
> > changeset:   9390:83d604a4e803
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Sat Jul 25 16:22:40 2009 +0200
> > summary:     fix Cholesky updating with scalars
> > 
> > changeset:   9391:c4f89df90e43
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Sat Jul 25 16:26:01 2009 +0200
> > summary:     avoid complex -> real conversion when constructing arrays with []
> > 
> > changeset:   9392:6a6779e895d4
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Tue Aug 04 09:52:53 2009 +0200
> > summary:     correctly parse things like '@(){1 2}'
> > 
> > changeset:   9393:18b8a3aa034c
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Tue Aug 04 09:55:38 2009 +0200
> > summary:     use complex function for acos mapper if arg is out of range [-1, 1]
> > 
> > changeset:   9394:f1dd244757cd
> > user:        Ben Abbott <bpabbott at mac.com>
> > date:        Thu Aug 06 07:18:53 2009 +0200
> > summary:     __go_draw_axes__.m: Fix ticklabels specified as 2D character array.
> > 
> > changeset:   9395:54a3fa5d4376
> > user:        Ben Abbott <bpabbott at mac.com>
> > date:        Thu Aug 06 07:30:34 2009 +0200
> > summary:     Avoid the flickering x11 window seen with rapid gnuplot updates.
> > 
> > changeset:   9396:9107c882f193
> > user:        Olli Saarela <olli.saarela at gmail.com>
> > date:        Thu Aug 06 07:31:45 2009 +0200
> > summary:     __gnuplot_get_var__: if read fails to return data, sleep
> > before trying again
> > 
> > changeset:   9397:16181105aeb6
> > user:        Pieter Eendebak <pieter.eendebak at gmail.com>
> > date:        Thu Aug 06 07:32:53 2009 +0200
> > summary:     support cellstrs in setxor
> > 
> > changeset:   9398:21038fd51788
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Fri Aug 07 08:11:49 2009 +0200
> > summary:     implant tree_index_expression::lvalue from development version
> > 
> > changeset:   9399:0014ff1747a6
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Fri Aug 07 08:13:22 2009 +0200
> > summary:     use key list order for iterating through map with for loop
> > 
> > changeset:   9400:3db13615d39a
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Fri Aug 07 08:15:27 2009 +0200
> > summary:     handle null matrix assignment for diagonal and permutation matrices
> > 
> > changeset:   9401:3a4da80f4adc
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Fri Aug 07 08:22:13 2009 +0200
> > summary:     complete change d5570d4b1116
> > 
> > changeset:   9402:1d5a487a01cf
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Mon Aug 10 11:14:46 2009 +0200
> > summary:     parse.y (Fevalin): also return output from CATCH expression
> > 
> > changeset:   9403:a29f3eba78a2
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Thu Aug 13 07:56:00 2009 +0200
> > summary:     new option, --no-window-system
> > 
> > changeset:   9404:1347fcb231bd
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Sun Aug 23 11:09:17 2009 +0200
> > summary:     dlmread: perform tilde expansion to filename argument
> > 
> > changeset:   9405:3a65f1038bdb
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Sun Aug 23 11:10:05 2009 +0200
> > summary:     fix some functions help markup
> > 
> > changeset:   9406:4963bb455582
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Sun Aug 23 11:10:35 2009 +0200
> > summary:     fix typos in complex xgemm
> > 
> > changeset:   9407:1371eecefd99
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Sun Aug 23 11:11:27 2009 +0200
> > summary:     make single prec. matrix mutliply tests really single
> > 
> > changeset:   9408:9e66af7e1593
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Sun Aug 23 11:11:27 2009 +0200
> > summary:     more fixes & tests for matrix multiply
> > 
> > changeset:   9409:f0d18d74a519
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Sun Aug 23 11:12:16 2009 +0200
> > summary:     acx_blas_f77_func.m4 (ACX_BLAS_F77_FUNC): Save and restore LIBS
> > 
> > changeset:   9410:c3d37d2a2b55
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Sun Aug 23 11:12:35 2009 +0200
> > summary:     zero matrix assignment fix
> > 
> > changeset:   9411:d208ae6e9d74
> > user:        David Bateman <dbateman at free.fr>
> > date:        Mon Aug 24 10:02:47 2009 +0200
> > summary:     Fix test for setting of datasource properties. Add the
> > edgecolor property to contours
> > 
> > changeset:   9412:8e69b1d41c03
> > tag:         qparent
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Mon Aug 24 10:06:52 2009 +0200
> > summary:     fix typo in acx_blas_f77_func.m4
> > 
> > In case your favorite patch is missing, now would be a good time to mention it.
> > 
> > regards
> > 
> > -- 
> > RNDr. Jaroslav Hajek
> > computing expert & GNU Octave developer
> > Aeronautical Research and Test Institute (VZLU)
> > Prague, Czech Republic
> > url: www.highegg.matfyz.cz
> > 
> 
> 
> --------------------------------------
> 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/

From highegg at gmail.com  Mon Aug 24 05:34:01 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 24 Aug 2009 12:34:01 +0200
Subject: 3.2.3 RC1
In-Reply-To: <20090824094837.30977.qmail@web3802.mail.bbt.yahoo.co.jp>
References: <69d8d540908240158v634b5d0aj71554f0505a78395@mail.gmail.com>
	<20090824094837.30977.qmail@web3802.mail.bbt.yahoo.co.jp>
Message-ID: <69d8d540908240334k4ad61699v9d1cdb6686899de9@mail.gmail.com>

2009/8/24 Tatsuro MATSUOKA <tmacchant at yahoo.co.jp>:
> Hello
>
> make -f octMakefile all
> make[1]: Entering directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> (cd ../../octave-3.2.3-RC1; autoconf --force)
> /bin/autoconf-2.61: line 582: /usr/local/bin/autom4te-2.61: No such file or directory
> /bin/autoconf-2.61: line 582: exec: /usr/local/bin/autom4te-2.61: cannot execute: No such file or
> directory
> make[1]: *** [configure] Error 126
> make[1]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> make: *** [all] Error 2
>
> /bin/autoconf-2.61 ??
>
> Had not the issue of autoconf-2.6 ?been discussed and resolved ?
>
> Regards
>
> Tatsuro
>

I don't see this problem. Further, there appears to be no trace of the
strings "autoconf-2.61" or "autom4te-2.61" anywhere in the tarball, so
I guess something is wrong on your side.

hth

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


From highegg at gmail.com  Mon Aug 24 05:46:34 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Mon, 24 Aug 2009 12:46:34 +0200
Subject: 3.2.3 RC1
In-Reply-To: <25112855.post@talk.nabble.com>
References: <69d8d540908240158v634b5d0aj71554f0505a78395@mail.gmail.com>
	<25112855.post@talk.nabble.com>
Message-ID: <69d8d540908240346q16db89c2q10c53597e4ff3aa4@mail.gmail.com>

On Mon, Aug 24, 2009 at 11:13 AM, dbateman<dbateman at free.fr> wrote:
>
> Could we make a release with just 9406 immediately. Without this patch the
> 3.2.x release is really too buggy to use..
>
> D.
>

Yet, in spite of it being too buggy to use, I (and apparently not just
I) have been happily using the development version with this bug for
more than a year :)
Now seriously - I don't think an emergency release is needed. Does
anyone else (besides David?).

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

From tmacchant at yahoo.co.jp  Mon Aug 24 06:02:38 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Mon, 24 Aug 2009 20:02:38 +0900 (JST)
Subject: 3.2.3 RC1
In-Reply-To: <20090824094837.30977.qmail@web3802.mail.bbt.yahoo.co.jp>
Message-ID: <20090824110238.8477.qmail@web3812.mail.bbt.yahoo.co.jp>

Hello

Perhaps the problem relies on msys autoconf ???.

I have copied the autom4te-2.61 to /usr/local/bin from /usr/bin


make[1]: Entering directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
(cd ../../octave-3.2.3-RC1; autoconf --force)
Can't locate Autom4te/C4che.pm in @INC (@INC contains: /usr/local/share/autoconf
/usr/lib/perl5/5.6/msys /usr/lib/perl5/
5.6 /usr/lib/perl5/site_perl/5.6/msys /usr/lib/perl5/site_perl/5.6 /usr/lib/perl5/site_perl/5.6/msys
/usr/lib/perl5/site
_perl/5.6 /usr/lib/perl5/vendor_perl/5.6/msys /usr/lib/perl5/vendor_perl/5.6
/usr/lib/perl5/vendor_perl/5.6/msys /usr/li
b/perl5/vendor_perl/5.6 .) at /usr/local/bin/autom4te-2.61 line 39.
BEGIN failed--compilation aborted at /usr/local/bin/autom4te-2.61 line 39.
make[1]: *** [configure] Error 2
make[1]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
make: *** [all] Error 2

Hello Benjamin

Can you confirm this?
Or no problem for yours ?

Regards

Tatsuro

--- Tatsuro MATSUOKA wrote:

> Hello
> 
> make -f octMakefile all
> make[1]: Entering directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> (cd ../../octave-3.2.3-RC1; autoconf --force)
> /bin/autoconf-2.61: line 582: /usr/local/bin/autom4te-2.61: No such file or directory
> /bin/autoconf-2.61: line 582: exec: /usr/local/bin/autom4te-2.61: cannot execute: No such file
> or
> directory
> make[1]: *** [configure] Error 126
> make[1]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> make: *** [all] Error 2
> 
> /bin/autoconf-2.61 ??
> 
> Had not the issue of autoconf-2.6  been discussed and resolved ?
> 
> Regards
> 
> Tatsuro 
> 
> --- Jaroslav Hajek <highegg at gmail.com> wrote:
> 
> > hi all,
> > 
> > I want to make 3.2.3 in the first half of September. The 1st release
> > candidate tarballs for 3.2.3 are available at:
> > http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> > 
> > changes since 3.2.2:
> > 
> > changeset:   9380:193174bc5107
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Wed Jul 08 13:49:21 2009 -0400
> > summary:     dim-vector.h: dim vectors always have two dimensions
> > 
> > changeset:   9381:4290384284b7
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Wed Jul 08 14:06:53 2009 -0400
> > summary:     pt-assign.cc (maybe_warn_former_built_in_variable): improve message
> > 
> > changeset:   9382:cd95695a0a89
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Thu Jul 09 15:04:34 2009 -0400
> > summary:     configure.in: don't use system strftime on MinGW systems
> > 
> > changeset:   9383:941b8414b99e
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Sat Jul 11 12:46:10 2009 -0400
> > summary:     file-ops.cc (file_ops::symlink, file_ops::readlink):
> > avoid incorrectly sized buffer
> > 
> > changeset:   9384:44300eb51817
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Thu Jul 16 11:56:44 2009 -0400
> > summary:     graphics.cc (get_array_limits): require min_pos value to
> > be greater than zero
> > 
> > changeset:   9385:9aea00e4e000
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Sat Jul 25 16:16:59 2009 +0200
> > summary:     Makeconf.in (MAGICK_LIBS): Don't pass --ldflags to $(MAGICK_CONFIG)
> > 
> > changeset:   9386:6ddb81224550
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Sat Jul 25 16:17:27 2009 +0200
> > summary:     __go_draw_axes__.m: also use layer property for plot border
> > 
> > changeset:   9387:b308b2e12f04
> > user:        Benjamin Lindner <lindnerb at users.sourceforge.net>
> > date:        Sat Jul 25 16:20:05 2009 +0200
> > summary:     determine correct image bitwidth in __magick_read__.cc
> > 
> > changeset:   9388:a8a44f20ef3b
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Sat Jul 25 16:20:35 2009 +0200
> > summary:     fix signed integer shift
> > 
> > changeset:   9389:3602403af9b8
> > user:        Aleksej Saushev <asau at inbox.ru>
> > date:        Sat Jul 25 16:21:51 2009 +0200
> > summary:     initialize floating point values properly for NetBSD systems
> > 
> > changeset:   9390:83d604a4e803
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Sat Jul 25 16:22:40 2009 +0200
> > summary:     fix Cholesky updating with scalars
> > 
> > changeset:   9391:c4f89df90e43
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Sat Jul 25 16:26:01 2009 +0200
> > summary:     avoid complex -> real conversion when constructing arrays with []
> > 
> > changeset:   9392:6a6779e895d4
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Tue Aug 04 09:52:53 2009 +0200
> > summary:     correctly parse things like '@(){1 2}'
> > 
> > changeset:   9393:18b8a3aa034c
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Tue Aug 04 09:55:38 2009 +0200
> > summary:     use complex function for acos mapper if arg is out of range [-1, 1]
> > 
> > changeset:   9394:f1dd244757cd
> > user:        Ben Abbott <bpabbott at mac.com>
> > date:        Thu Aug 06 07:18:53 2009 +0200
> > summary:     __go_draw_axes__.m: Fix ticklabels specified as 2D character array.
> > 
> > changeset:   9395:54a3fa5d4376
> > user:        Ben Abbott <bpabbott at mac.com>
> > date:        Thu Aug 06 07:30:34 2009 +0200
> > summary:     Avoid the flickering x11 window seen with rapid gnuplot updates.
> > 
> > changeset:   9396:9107c882f193
> > user:        Olli Saarela <olli.saarela at gmail.com>
> > date:        Thu Aug 06 07:31:45 2009 +0200
> > summary:     __gnuplot_get_var__: if read fails to return data, sleep
> > before trying again
> > 
> > changeset:   9397:16181105aeb6
> > user:        Pieter Eendebak <pieter.eendebak at gmail.com>
> > date:        Thu Aug 06 07:32:53 2009 +0200
> > summary:     support cellstrs in setxor
> > 
> > changeset:   9398:21038fd51788
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Fri Aug 07 08:11:49 2009 +0200
> > summary:     implant tree_index_expression::lvalue from development version
> > 
> > changeset:   9399:0014ff1747a6
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Fri Aug 07 08:13:22 2009 +0200
> > summary:     use key list order for iterating through map with for loop
> > 
> > changeset:   9400:3db13615d39a
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Fri Aug 07 08:15:27 2009 +0200
> > summary:     handle null matrix assignment for diagonal and permutation matrices
> > 
> > changeset:   9401:3a4da80f4adc
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Fri Aug 07 08:22:13 2009 +0200
> > summary:     complete change d5570d4b1116
> > 
> > changeset:   9402:1d5a487a01cf
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Mon Aug 10 11:14:46 2009 +0200
> > summary:     parse.y (Fevalin): also return output from CATCH expression
> > 
> > changeset:   9403:a29f3eba78a2
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Thu Aug 13 07:56:00 2009 +0200
> > summary:     new option, --no-window-system
> > 
> > changeset:   9404:1347fcb231bd
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Sun Aug 23 11:09:17 2009 +0200
> > summary:     dlmread: perform tilde expansion to filename argument
> > 
> > changeset:   9405:3a65f1038bdb
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Sun Aug 23 11:10:05 2009 +0200
> > summary:     fix some functions help markup
> > 
> > changeset:   9406:4963bb455582
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Sun Aug 23 11:10:35 2009 +0200
> > summary:     fix typos in complex xgemm
> > 
> > changeset:   9407:1371eecefd99
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Sun Aug 23 11:11:27 2009 +0200
> > summary:     make single prec. matrix mutliply tests really single
> > 
> > changeset:   9408:9e66af7e1593
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Sun Aug 23 11:11:27 2009 +0200
> > summary:     more fixes & tests for matrix multiply
> > 
> > changeset:   9409:f0d18d74a519
> > user:        John W. Eaton <jwe at octave.org>
> > date:        Sun Aug 23 11:12:16 2009 +0200
> > summary:     acx_blas_f77_func.m4 (ACX_BLAS_F77_FUNC): Save and restore LIBS
> > 
> > changeset:   9410:c3d37d2a2b55
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Sun Aug 23 11:12:35 2009 +0200
> > summary:     zero matrix assignment fix
> > 
> > changeset:   9411:d208ae6e9d74
> > user:        David Bateman <dbateman at free.fr>
> > date:        Mon Aug 24 10:02:47 2009 +0200
> > summary:     Fix test for setting of datasource properties. Add the
> > edgecolor property to contours
> > 
> > changeset:   9412:8e69b1d41c03
> > tag:         qparent
> > user:        Jaroslav Hajek <highegg at gmail.com>
> > date:        Mon Aug 24 10:06:52 2009 +0200
> > summary:     fix typo in acx_blas_f77_func.m4
> > 
> > In case your favorite patch is missing, now would be a good time to mention it.
> > 
> > regards
> > 
> > -- 
> > RNDr. Jaroslav Hajek
> > computing expert & GNU Octave developer
> > Aeronautical Research and Test Institute (VZLU)
> > Prague, Czech Republic
> > url: www.highegg.matfyz.cz
> > 
> 
> 
> --------------------------------------
> 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/

From marco_atzeri at yahoo.it  Mon Aug 24 08:06:06 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Mon, 24 Aug 2009 13:06:06 +0000 (GMT)
Subject: R: 3.2.3 RC1
In-Reply-To: <69d8d540908240158v634b5d0aj71554f0505a78395@mail.gmail.com>
Message-ID: <396697.65506.qm@web25506.mail.ukl.yahoo.com>

--- Lun 24/8/09, Jaroslav Hajek <highegg at gmail.com> ha scritto:

> Da: Jaroslav Hajek <highegg at gmail.com>
> Oggetto: 3.2.3 RC1
> A: "octave maintainers list" <maintainers at octave.org>
> Data: Luned? 24 agosto 2009, 10:58
> hi all,
> 
> I want to make 3.2.3 in the first half of September. The
> 1st release
> candidate tarballs for 3.2.3 are available at:
> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> 
[cut]
> 
> In case your favorite patch is missing, now would be a good
> time to mention it.
> 
> regards
> 
> -- 
> RNDr. Jaroslav Hajek
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
> 

Hi Jaroslav,
it builds fine and pass the usual tests on cygwin

Regards
Marco



      



From jwleblan at gmail.com  Mon Aug 24 10:08:06 2009
From: jwleblan at gmail.com (Joel LeBlanc)
Date: Mon, 24 Aug 2009 11:08:06 -0400
Subject: Unreliable OSX Builds
Message-ID: <34716c2e0908240808l6c5cac49ldf4f02f9f176d51d@mail.gmail.com>

I have been building (or trying to build) octave on OSX for some time now.
 It didn't work, then I fixed a few things and it did for a couple of weeks,
now it won't build again.  Surely I am doing something wrong.  I can't
understand how the build process can be so fragile.  There also don't seem
to be clear instructions on how to build, and from what I've read in the
archives its far from autogen->configure->make.
For example here is what I'm doing:
__________________________________________________________
#! /bin/sh -ev

./autogen.sh

# Apple's vecLib:
export
blas='--with-lapack=-Wl,-framework,Accelerate,-dylib_file,/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib:/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
--with-blas=-Wl,-framework,Accelerate,-dylib_file,/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib:/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib'


# Similar to Fink's configure
./configure --prefix=/sw FLIBS=/sw/lib/gcc4.4/lib/libgfortran.dylib
F77=/sw/bin/gfortran FC=/sw/bin/gfortran CC=gcc-4 CPP=cpp-4 CXX=g++-4
--infodir='${prefix}/share/info' --mandir='${prefix}/share/man'
--libexecdir='${prefix}/lib' -enable-shared -enable-dl --disable-static
--without-mpi --with-hdf5 --with-fftw CPPFLAGS="-g -I/sw/include
-I/sw/include/freetype2 -I/sw/lib/flex/include" FFLAGS="-g -ff2c"
LDFLAGS="-L/sw/lib/fltk-aqua/lib -L/sw/lib/flex/lib -L/sw/lib -lfltk_gl
-lfltk -lpthread" $blas

make clean
make all
__________________________________________________________

And the results:

g++-4 -dynamiclib -single_module -L/sw/lib/fltk-aqua/lib -L/sw/lib/flex/lib
-L/sw/lib -lfltk_gl -lfltk -lpthread -L/sw/lib/fltk-aqua/lib
-L/sw/lib/flex/lib -L/sw/lib -lfltk_gl -lfltk -lpthread -install_name
/sw/lib/octave-3.1.55/liboctinterp.dylib -o liboctinterp.dylib pic/Cell.o
pic/bitfcns.o pic/c-file-ptr-stream.o pic/comment-list.o pic/cutils.o
pic/data.o pic/debug.o pic/defaults.o pic/defun.o pic/dirfns.o pic/display.o
pic/dynamic-ld.o pic/error.o pic/file-io.o pic/gl-render.o pic/graphics.o
pic/gripes.o pic/help.o pic/input.o pic/lex.o pic/load-path.o
pic/load-save.o pic/ls-hdf5.o pic/ls-mat-ascii.o pic/ls-mat4.o pic/ls-mat5.o
pic/ls-oct-ascii.o pic/ls-ascii-helper.o pic/ls-oct-binary.o pic/ls-utils.o
pic/main.o pic/mappers.o pic/matherr.o pic/mex.o pic/oct-fstrm.o
pic/oct-hist.o pic/oct-iostrm.o pic/oct-map.o pic/oct-obj.o
pic/oct-prcstrm.o pic/oct-procbuf.o pic/oct-stream.o pic/octave.o
pic/zfstream.o pic/oct-strstrm.o pic/oct-lvalue.o pic/pager.o pic/parse.o
pic/pr-output.o pic/procstream.o pic/sighandlers.o pic/siglist.o
pic/sparse-xdiv.o pic/sparse-xpow.o pic/strfns.o pic/syscalls.o pic/symtab.o
pic/sysdep.o pic/token.o pic/toplev.o pic/txt-eng-ft.o pic/unwind-prot.o
pic/utils.o pic/variables.o pic/xdiv.o pic/xnorm.o pic/xpow.o pic/ov-base.o
pic/ov-ch-mat.o pic/ov-cs-list.o pic/ov-list.o pic/ov-re-mat.o
pic/ov-cx-mat.o pic/ov-range.o pic/ov-scalar.o pic/ov-complex.o
pic/ov-str-mat.o pic/ov-struct.o pic/ov-colon.o pic/ov-bool-mat.o
pic/ov-bool.o pic/ov-null-mat.o pic/ov-cell.o pic/ov.o pic/ov-fcn.o
pic/ov-builtin.o pic/ov-dld-fcn.o pic/ov-mex-fcn.o pic/ov-usr-fcn.o
pic/ov-fcn-handle.o pic/ov-fcn-inline.o pic/ov-class.o pic/ov-typeinfo.o
pic/ov-flt-re-mat.o pic/ov-flt-cx-mat.o pic/ov-float.o pic/ov-flt-complex.o
pic/ov-re-diag.o pic/ov-flt-re-diag.o pic/ov-cx-diag.o pic/ov-flt-cx-diag.o
pic/ov-perm.o pic/ov-int8.o pic/ov-int16.o pic/ov-int32.o pic/ov-int64.o
pic/ov-uint8.o pic/ov-uint16.o pic/ov-uint32.o pic/ov-uint64.o
pic/ov-base-sparse.o pic/ov-bool-sparse.o pic/ov-cx-sparse.o
pic/ov-re-sparse.o pic/pt.o pic/pt-arg-list.o pic/pt-assign.o pic/pt-bp.o
pic/pt-binop.o pic/pt-cbinop.o pic/pt-cell.o pic/pt-check.o pic/pt-cmd.o
pic/pt-colon.o pic/pt-const.o pic/pt-decl.o pic/pt-eval.o pic/pt-except.o
pic/pt-exp.o pic/pt-fcn-handle.o pic/pt-id.o pic/pt-idx.o pic/pt-jump.o
pic/pt-loop.o pic/pt-mat.o pic/pt-misc.o pic/pt-pr-code.o pic/pt-select.o
pic/pt-stmt.o pic/pt-unop.o pic/op-b-b.o pic/op-b-bm.o pic/op-bm-b.o
pic/op-bm-bm.o pic/op-cell.o pic/op-chm.o pic/op-class.o pic/op-list.o
pic/op-range.o pic/op-str-m.o pic/op-str-s.o pic/op-str-str.o
pic/op-struct.o pic/op-double-conv.o pic/op-cm-cm.o pic/op-cm-cs.o
pic/op-cm-m.o pic/op-cm-s.o pic/op-cs-cm.o pic/op-cs-cs.o pic/op-cs-m.o
pic/op-cs-s.o pic/op-m-cm.o pic/op-m-cs.o pic/op-m-m.o pic/op-m-s.o
pic/op-s-cm.o pic/op-s-cs.o pic/op-s-m.o pic/op-s-s.o pic/op-float-conv.o
pic/op-fcm-fcm.o pic/op-fcm-fcs.o pic/op-fcm-fm.o pic/op-fcm-fs.o
pic/op-fcs-fcm.o pic/op-fcs-fcs.o pic/op-fcs-fm.o pic/op-fcs-fs.o
pic/op-fm-fcm.o pic/op-fm-fcs.o pic/op-fm-fm.o pic/op-fm-fs.o
pic/op-fs-fcm.o pic/op-fs-fcs.o pic/op-fs-fm.o pic/op-fs-fs.o
pic/op-int-concat.o pic/op-int-conv.o pic/op-i8-i8.o pic/op-i16-i16.o
pic/op-i32-i32.o pic/op-i64-i64.o pic/op-ui8-ui8.o pic/op-ui16-ui16.o
pic/op-ui32-ui32.o pic/op-ui64-ui64.o pic/op-bm-sbm.o pic/op-b-sbm.o
pic/op-cm-scm.o pic/op-cm-sm.o pic/op-cs-scm.o pic/op-cs-sm.o pic/op-m-scm.o
pic/op-m-sm.o pic/op-sbm-b.o pic/op-sbm-bm.o pic/op-sbm-sbm.o
pic/op-scm-cm.o pic/op-scm-cs.o pic/op-scm-m.o pic/op-scm-s.o
pic/op-scm-scm.o pic/op-scm-sm.o pic/op-sm-cm.o pic/op-sm-cs.o pic/op-sm-m.o
pic/op-sm-s.o pic/op-sm-scm.o pic/op-sm-sm.o pic/op-s-scm.o pic/op-s-sm.o
pic/op-cdm-cdm.o pic/op-cdm-cm.o pic/op-cdm-cs.o pic/op-cdm-dm.o
pic/op-cdm-m.o pic/op-cdm-s.o pic/op-cm-cdm.o pic/op-cm-dm.o pic/op-dm-cdm.o
pic/op-dm-cm.o pic/op-dm-cs.o pic/op-dm-dm.o pic/op-dm-m.o pic/op-dm-s.o
pic/op-m-cdm.o pic/op-m-dm.o pic/op-dm-sm.o pic/op-dm-scm.o
pic/op-fcdm-fcdm.o pic/op-fcdm-fcm.o pic/op-fcdm-fcs.o pic/op-fcdm-fdm.o
pic/op-fcdm-fm.o pic/op-fcdm-fs.o pic/op-fcm-fcdm.o pic/op-fcm-fdm.o
pic/op-fdm-fcdm.o pic/op-fdm-fcm.o pic/op-fdm-fcs.o pic/op-fdm-fdm.o
pic/op-fdm-fm.o pic/op-fdm-fs.o pic/op-fm-fcdm.o pic/op-fm-fdm.o
pic/op-cm-pm.o pic/op-fcm-pm.o pic/op-fm-pm.o pic/op-pm-fcm.o pic/op-pm-fm.o
pic/op-m-pm.o pic/op-pm-cm.o pic/op-pm-m.o pic/op-pm-pm.o pic/op-pm-sm.o
pic/op-pm-scm.o pic/Array-os.o pic/Array-tc.o pic/oct-errno.o pic/builtins.o
pic/ops.o ../libcruft/blas-xtra/pic/xerbla.o  -L../liboctave -loctave
-L../libcruft -lcruft  -lfftw3 -lfftw3f  -lhdf5  -lz -L/usr/X11/lib
-lfontconfig -lftgl -L/sw/lib -lfreetype -lz -Wl,-framework,CoreServices
-Wl,-framework,ApplicationServices -Wl,-framework -Wl,OpenGL -L/usr/X11/lib
-lX11 -Wl,-framework -Wl,Carbon -lreadline -lm
Undefined symbols:
  "__gfortran_st_write", referenced from:
      _xerbla_ in xerbla.o
  "__gfortran_st_write_done", referenced from:
      _xerbla_ in xerbla.o
  "__gfortran_transfer_character", referenced from:
      _xerbla_ in xerbla.o
  "__gfortran_transfer_integer", referenced from:
      _xerbla_ in xerbla.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [liboctinterp.dylib] Error 1
make[1]: *** [src] Error 2
make: *** [all] Error 2
miys02-leblanpb2:octave leblanc$


Is there a reliable way to get things built?  Do any of the developers work
on OSX, or is there a procedure that SHOULD result in a successful build?
 How do I get to the current stable code (I'm assuming the HEAD is the
"testing/devepment" code).

I apologize in advance for my ignorance,

~Joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090824/42fb4a61/attachment-0001.html 

From storrsjm at email.uc.edu  Mon Aug 24 11:38:34 2009
From: storrsjm at email.uc.edu (Judd Storrs)
Date: Mon, 24 Aug 2009 12:38:34 -0400
Subject: R: 3.2.3 RC1
In-Reply-To: <396697.65506.qm@web25506.mail.ukl.yahoo.com>
References: <69d8d540908240158v634b5d0aj71554f0505a78395@mail.gmail.com>
	<396697.65506.qm@web25506.mail.ukl.yahoo.com>
Message-ID: <a0daad600908240938k674f3dedkffd5ecc56a823706@mail.gmail.com>

3.2.3-rc1 builds without problem on Ubuntu 9.04 amd64 (autoconf-2.63) and
passes all checks.

--judd


Octave is now configured for x86_64-unknown-linux-gnu

  Source directory:     .
  Installation prefix:  /usr/local/stow/octave-3.2.3-rc1
  C compiler:           gcc   -Wall -W -Wshadow -Wformat -g -O2
  C++ compiler:         g++  -I/usr/include/freetype2  -Wall -W -Wshadow
-Wold-style-cast -Wformat -g -O2
  Fortran compiler:     gfortran -O
  Fortran libraries:     -L/usr/lib/gcc/x86_64-linux-gnu/4.3.3
-L/usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../li
b -L/lib/../lib -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../.. -lhdf5 -lz -lgfortranbegin
-lgfort
ran -lm
  BLAS libraries:       -llapack -lblas
  FFTW libraries:       -lfftw3 -lfftw3f
  GLPK libraries:       -lglpk
  UMFPACK libraries:    -lumfpack
  AMD libraries:        -lamd
  CAMD libraries:       -lcamd
  COLAMD libraries:     -lcolamd
  CCOLAMD libraries:    -lccolamd
  CHOLMOD libraries:    -lcholmod
  CXSPARSE libraries:   -lcxsparse
  ARPACK libraries:     -larpack
  QRUPDATE libraries:    -lqrupdate
  HDF5 libraries:       -lhdf5
  CURL libraries:       -lcurl
  REGEX libraries:      -L/usr/lib -lpcre
  QHULL libraries:    -lqhull
  OPENGL libraries:     -lftgl -lfreetype -lz -L/usr/X11R6/lib -lGL -lGLU
  FLTK backend libs:    -Wl,-Bsymbolic-functions -lfltk_gl -lfltk
  X11 include flags:
  X11 libraries:        -lX11
  CARBON libraries:
  LIBS:                 -lreadline  -lncurses -ldl -lhdf5 -lz -lm
  Default pager:        less
  gnuplot:              gnuplot
  Magick config:        GraphicsMagick++-config

  Do internal array bounds checking:  false
  Build static libraries:             false
  Build shared libraries:             true
  Dynamic Linking:                    true (dlopen)
  Include support for GNU readline:   true
  64-bit array dims and indexing:     false



Summary:

  PASS   5765
  FAIL      0

There were 2 expected failures (see fntests.log for details).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090824/31d64e01/attachment.html 

From bpabbott at mac.com  Mon Aug 24 11:54:00 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Mon, 24 Aug 2009 12:54:00 -0400
Subject: Unreliable OSX Builds
In-Reply-To: <34716c2e0908240808l6c5cac49ldf4f02f9f176d51d@mail.gmail.com>
References: <34716c2e0908240808l6c5cac49ldf4f02f9f176d51d@mail.gmail.com>
Message-ID: <B0D2BE93-AEC4-48F1-BBC9-CC1C64A7428E@mac.com>

On Aug 24, 2009, at 11:08 AM, Joel LeBlanc <jwleblan at gmail.com> wrote:

> I have been building (or trying to build) octave on OSX for some  
> time now.  It didn't work, then I fixed a few things and it did for  
> a couple of weeks, now it won't build again.  Surely I am doing  
> something wrong.  I can't understand how the build process can be so  
> fragile.  There also don't seem to be clear instructions on how to  
> build, and from what I've read in the archives its far from autogen- 
> >configure->make.
>
> For example here is what I'm doing:
> __________________________________________________________
> #! /bin/sh -ev
>
> ./autogen.sh
>
> # Apple's vecLib:
> export blas='--with-lapack=-Wl,-framework,Accelerate,-dylib_file,/ 
> System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ 
> vecLib.framework/Versions/A/libLAPACK.dylib:/System/Library/ 
> Frameworks/Accelerate.framework/Versions/A/Frameworks/ 
> vecLib.framework/Versions/A/libLAPACK.dylib --with-blas=-Wl,- 
> framework,Accelerate,-dylib_file,/System/Library/Frameworks/ 
> Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/ 
> A/libBLAS.dylib:/System/Library/Frameworks/Accelerate.framework/ 
> Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib'
>
>
> # Similar to Fink's configure
> ./configure --prefix=/sw FLIBS=/sw/lib/gcc4.4/lib/libgfortran.dylib  
> F77=/sw/bin/gfortran FC=/sw/bin/gfortran CC=gcc-4 CPP=cpp-4 CXX=g+ 
> +-4 --infodir='${prefix}/share/info' --mandir='${prefix}/share/man'  
> --libexecdir='${prefix}/lib' -enable-shared -enable-dl --disable- 
> static --without-mpi --with-hdf5 --with-fftw CPPFLAGS="-g -I/sw/ 
> include -I/sw/include/freetype2 -I/sw/lib/flex/include" FFLAGS="-g - 
> ff2c" LDFLAGS="-L/sw/lib/fltk-aqua/lib -L/sw/lib/flex/lib -L/sw/lib - 
> lfltk_gl -lfltk -lpthread" $blas
>
> make clean
> make all
> __________________________________________________________
>
> And the results:
>
> g++-4 -dynamiclib -single_module -L/sw/lib/fltk-aqua/lib -L/sw/lib/ 
> flex/lib -L/sw/lib -lfltk_gl -lfltk -lpthread -L/sw/lib/fltk-aqua/ 
> lib -L/sw/lib/flex/lib -L/sw/lib -lfltk_gl -lfltk -lpthread - 
> install_name /sw/lib/octave-3.1.55/liboctinterp.dylib -o  
> liboctinterp.dylib pic/Cell.o pic/bitfcns.o pic/c-file-ptr-stream.o  
> pic/comment-list.o pic/cutils.o pic/data.o pic/debug.o pic/ 
> defaults.o pic/defun.o pic/dirfns.o pic/display.o pic/dynamic-ld.o  
> pic/error.o pic/file-io.o pic/gl-render.o pic/graphics.o pic/ 
> gripes.o pic/help.o pic/input.o pic/lex.o pic/load-path.o pic/load- 
> save.o pic/ls-hdf5.o pic/ls-mat-ascii.o pic/ls-mat4.o pic/ls-mat5.o  
> pic/ls-oct-ascii.o pic/ls-ascii-helper.o pic/ls-oct-binary.o pic/ls- 
> utils.o pic/main.o pic/mappers.o pic/matherr.o pic/mex.o pic/oct- 
> fstrm.o pic/oct-hist.o pic/oct-iostrm.o pic/oct-map.o pic/oct-obj.o  
> pic/oct-prcstrm.o pic/oct-procbuf.o pic/oct-stream.o pic/octave.o  
> pic/zfstream.o pic/oct-strstrm.o pic/oct-lvalue.o pic/pager.o pic/ 
> parse.o pic/pr-output.o pic/procstream.o pic/sighandlers.o pic/ 
> siglist.o pic/sparse-xdiv.o pic/sparse-xpow.o pic/strfns.o pic/ 
> syscalls.o pic/symtab.o pic/sysdep.o pic/token.o pic/toplev.o pic/ 
> txt-eng-ft.o pic/unwind-prot.o pic/utils.o pic/variables.o pic/ 
> xdiv.o pic/xnorm.o pic/xpow.o pic/ov-base.o pic/ov-ch-mat.o pic/ov- 
> cs-list.o pic/ov-list.o pic/ov-re-mat.o pic/ov-cx-mat.o pic/ov- 
> range.o pic/ov-scalar.o pic/ov-complex.o pic/ov-str-mat.o pic/ov- 
> struct.o pic/ov-colon.o pic/ov-bool-mat.o pic/ov-bool.o pic/ov-null- 
> mat.o pic/ov-cell.o pic/ov.o pic/ov-fcn.o pic/ov-builtin.o pic/ov- 
> dld-fcn.o pic/ov-mex-fcn.o pic/ov-usr-fcn.o pic/ov-fcn-handle.o pic/ 
> ov-fcn-inline.o pic/ov-class.o pic/ov-typeinfo.o pic/ov-flt-re-mat.o  
> pic/ov-flt-cx-mat.o pic/ov-float.o pic/ov-flt-complex.o pic/ov-re- 
> diag.o pic/ov-flt-re-diag.o pic/ov-cx-diag.o pic/ov-flt-cx-diag.o  
> pic/ov-perm.o pic/ov-int8.o pic/ov-int16.o pic/ov-int32.o pic/ov- 
> int64.o pic/ov-uint8.o pic/ov-uint16.o pic/ov-uint32.o pic/ov- 
> uint64.o pic/ov-base-sparse.o pic/ov-bool-sparse.o pic/ov-cx- 
> sparse.o pic/ov-re-sparse.o pic/pt.o pic/pt-arg-list.o pic/pt- 
> assign.o pic/pt-bp.o pic/pt-binop.o pic/pt-cbinop.o pic/pt-cell.o  
> pic/pt-check.o pic/pt-cmd.o pic/pt-colon.o pic/pt-const.o pic/pt- 
> decl.o pic/pt-eval.o pic/pt-except.o pic/pt-exp.o pic/pt-fcn- 
> handle.o pic/pt-id.o pic/pt-idx.o pic/pt-jump.o pic/pt-loop.o pic/pt- 
> mat.o pic/pt-misc.o pic/pt-pr-code.o pic/pt-select.o pic/pt-stmt.o  
> pic/pt-unop.o pic/op-b-b.o pic/op-b-bm.o pic/op-bm-b.o pic/op-bm- 
> bm.o pic/op-cell.o pic/op-chm.o pic/op-class.o pic/op-list.o pic/op- 
> range.o pic/op-str-m.o pic/op-str-s.o pic/op-str-str.o pic/op- 
> struct.o pic/op-double-conv.o pic/op-cm-cm.o pic/op-cm-cs.o pic/op- 
> cm-m.o pic/op-cm-s.o pic/op-cs-cm.o pic/op-cs-cs.o pic/op-cs-m.o pic/ 
> op-cs-s.o pic/op-m-cm.o pic/op-m-cs.o pic/op-m-m.o pic/op-m-s.o pic/ 
> op-s-cm.o pic/op-s-cs.o pic/op-s-m.o pic/op-s-s.o pic/op-float- 
> conv.o pic/op-fcm-fcm.o pic/op-fcm-fcs.o pic/op-fcm-fm.o pic/op-fcm- 
> fs.o pic/op-fcs-fcm.o pic/op-fcs-fcs.o pic/op-fcs-fm.o pic/op-fcs- 
> fs.o pic/op-fm-fcm.o pic/op-fm-fcs.o pic/op-fm-fm.o pic/op-fm-fs.o  
> pic/op-fs-fcm.o pic/op-fs-fcs.o pic/op-fs-fm.o pic/op-fs-fs.o pic/op- 
> int-concat.o pic/op-int-conv.o pic/op-i8-i8.o pic/op-i16-i16.o pic/ 
> op-i32-i32.o pic/op-i64-i64.o pic/op-ui8-ui8.o pic/op-ui16-ui16.o  
> pic/op-ui32-ui32.o pic/op-ui64-ui64.o pic/op-bm-sbm.o pic/op-b-sbm.o  
> pic/op-cm-scm.o pic/op-cm-sm.o pic/op-cs-scm.o pic/op-cs-sm.o pic/op- 
> m-scm.o pic/op-m-sm.o pic/op-sbm-b.o pic/op-sbm-bm.o pic/op-sbm- 
> sbm.o pic/op-scm-cm.o pic/op-scm-cs.o pic/op-scm-m.o pic/op-scm-s.o  
> pic/op-scm-scm.o pic/op-scm-sm.o pic/op-sm-cm.o pic/op-sm-cs.o pic/ 
> op-sm-m.o pic/op-sm-s.o pic/op-sm-scm.o pic/op-sm-sm.o pic/op-s- 
> scm.o pic/op-s-sm.o pic/op-cdm-cdm.o pic/op-cdm-cm.o pic/op-cdm-cs.o  
> pic/op-cdm-dm.o pic/op-cdm-m.o pic/op-cdm-s.o pic/op-cm-cdm.o pic/op- 
> cm-dm.o pic/op-dm-cdm.o pic/op-dm-cm.o pic/op-dm-cs.o pic/op-dm-dm.o  
> pic/op-dm-m.o pic/op-dm-s.o pic/op-m-cdm.o pic/op-m-dm.o pic/op-dm- 
> sm.o pic/op-dm-scm.o pic/op-fcdm-fcdm.o pic/op-fcdm-fcm.o pic/op- 
> fcdm-fcs.o pic/op-fcdm-fdm.o pic/op-fcdm-fm.o pic/op-fcdm-fs.o pic/ 
> op-fcm-fcdm.o pic/op-fcm-fdm.o pic/op-fdm-fcdm.o pic/op-fdm-fcm.o  
> pic/op-fdm-fcs.o pic/op-fdm-fdm.o pic/op-fdm-fm.o pic/op-fdm-fs.o  
> pic/op-fm-fcdm.o pic/op-fm-fdm.o pic/op-cm-pm.o pic/op-fcm-pm.o pic/ 
> op-fm-pm.o pic/op-pm-fcm.o pic/op-pm-fm.o pic/op-m-pm.o pic/op-pm- 
> cm.o pic/op-pm-m.o pic/op-pm-pm.o pic/op-pm-sm.o pic/op-pm-scm.o pic/ 
> Array-os.o pic/Array-tc.o pic/oct-errno.o pic/builtins.o pic/ 
> ops.o ../libcruft/blas-xtra/pic/xerbla.o  -L../liboctave -loctave - 
> L../libcruft -lcruft  -lfftw3 -lfftw3f  -lhdf5  -lz -L/usr/X11/lib - 
> lfontconfig -lftgl -L/sw/lib -lfreetype -lz -Wl,- 
> framework,CoreServices -Wl,-framework,ApplicationServices -Wl,- 
> framework -Wl,OpenGL -L/usr/X11/lib -lX11 -Wl,-framework -Wl,Carbon - 
> lreadline -lm
> Undefined symbols:
>   "__gfortran_st_write", referenced from:
>       _xerbla_ in xerbla.o
>   "__gfortran_st_write_done", referenced from:
>       _xerbla_ in xerbla.o
>   "__gfortran_transfer_character", referenced from:
>       _xerbla_ in xerbla.o
>   "__gfortran_transfer_integer", referenced from:
>       _xerbla_ in xerbla.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[2]: *** [liboctinterp.dylib] Error 1
> make[1]: *** [src] Error 2
> make: *** [all] Error 2
> miys02-leblanpb2:octave leblanc$
>
>
> Is there a reliable way to get things built?  Do any of the  
> developers work on OSX, or is there a procedure that SHOULD result  
> in a successful build? How do I get to the current stable code (I'm  
> assuming the HEAD is the "testing/devepment" code).
>
> I apologize in advance for my ignorance,
>
> ~Joel

I have the same problem. I'm able to build liboctinterp.dylib if I  
manually include $FLIBS.

I don't know how to fix the compile proceedure.

Ben

From Thomas.Treichl at gmx.net  Mon Aug 24 13:38:53 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Mon, 24 Aug 2009 20:38:53 +0200
Subject: Unreliable OSX Builds
In-Reply-To: <34716c2e0908240808l6c5cac49ldf4f02f9f176d51d@mail.gmail.com>
References: <34716c2e0908240808l6c5cac49ldf4f02f9f176d51d@mail.gmail.com>
Message-ID: <4A92DE3D.7060009@gmx.net>

Joel LeBlanc schrieb:
> I have been building (or trying to build) octave on OSX for some time 
> now.  It didn't work, then I fixed a few things and it did for a couple 
> of weeks, now it won't build again.  Surely I am doing something wrong. 
>  I can't understand how the build process can be so fragile.  There also 
> don't seem to be clear instructions on how to build, and from what I've 
> read in the archives its far from autogen->configure->make.
> 
> Is there a reliable way to get things built?  Do any of the developers 
> work on OSX, or is there a procedure that SHOULD result in a successful 
> build?  How do I get to the current stable code (I'm assuming the HEAD 
> is the "testing/devepment" code).
> 
> I apologize in advance for my ignorance,
> 
> ~Joel

Hi Joel,

I would say that we currently have some problems to compile the current Octave 
sources on MacOSX - work is currently done too to fix them. BTW, we are always 
interested in, like you say "I fixed a few things", what you fixed exactly. The 
number of people compiling Octave for themselves on MacOSX is small and maybe we 
do the same thing - so it might be an idea of proposing a patch to fix things 
for all Macs?

Best regards,

   Thomas

From jwleblan at gmail.com  Mon Aug 24 14:11:53 2009
From: jwleblan at gmail.com (Joel LeBlanc)
Date: Mon, 24 Aug 2009 15:11:53 -0400
Subject: Unreliable OSX Builds
In-Reply-To: <4A92DE3D.7060009@gmx.net>
References: <34716c2e0908240808l6c5cac49ldf4f02f9f176d51d@mail.gmail.com>
	<4A92DE3D.7060009@gmx.net>
Message-ID: <34716c2e0908241211o30fe1645v2f89199e959b186e@mail.gmail.com>

I'm not nearly talented enough to get this thing built with any confidence.
 For a while, I "fixed" something by adding "-L/sw/lib/fltk-aqua/lib
-L/sw/lib/flex/lib -L/sw/lib -lfltk_gl -lfltk" to the configure statement
(see my original post).
It seems that autoconf is completely unaware that port and fink produce /opt
and /sw folders that are highly likely to contain the libraries your gonna
need.  I'd try to help, but seriously, my ineptitude in such matters is
staggering ; )

What worries me is that it won't build... regularly.  It released without
being able to be built.  How can this thing possibly be passing testing, and
get to a released, if it won't even build?

It's too bad.  I'd really like to contribute to testing (I'm a power Matlab
user), but I'm basically being left out.  Imagine the average Matlab user,
they're not going to tweak configure flags.  As a result, they'll never even
have a chance to give feedback because it'll never build.

I guess bringing it up in the forums (is this really a forum?), is the best
way to start moving toward a fix.

Thanks for the feedback guys!

~Joel


On Mon, Aug 24, 2009 at 2:38 PM, Thomas Treichl <Thomas.Treichl at gmx.net>wrote:

> Joel LeBlanc schrieb:
>
>> I have been building (or trying to build) octave on OSX for some time now.
>>  It didn't work, then I fixed a few things and it did for a couple of weeks,
>> now it won't build again.  Surely I am doing something wrong.  I can't
>> understand how the build process can be so fragile.  There also don't seem
>> to be clear instructions on how to build, and from what I've read in the
>> archives its far from autogen->configure->make.
>>
>> Is there a reliable way to get things built?  Do any of the developers
>> work on OSX, or is there a procedure that SHOULD result in a successful
>> build?  How do I get to the current stable code (I'm assuming the HEAD is
>> the "testing/devepment" code).
>>
>> I apologize in advance for my ignorance,
>>
>> ~Joel
>>
>
> Hi Joel,
>
> I would say that we currently have some problems to compile the current
> Octave sources on MacOSX - work is currently done too to fix them. BTW, we
> are always interested in, like you say "I fixed a few things", what you
> fixed exactly. The number of people compiling Octave for themselves on
> MacOSX is small and maybe we do the same thing - so it might be an idea of
> proposing a patch to fix things for all Macs?
>
> Best regards,
>
>  Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090824/76b7ea80/attachment.html 

From lindnerben at gmx.net  Mon Aug 24 14:32:56 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Mon, 24 Aug 2009 21:32:56 +0200
Subject: 3.2.3 RC1
In-Reply-To: <20090824110238.8477.qmail@web3812.mail.bbt.yahoo.co.jp>
References: <20090824110238.8477.qmail@web3812.mail.bbt.yahoo.co.jp>
Message-ID: <4A92EAE8.7020206@gmx.net>

Tatsuro MATSUOKA wrote:
> Hello
> 
> Perhaps the problem relies on msys autoconf ???.
> 
> I have copied the autom4te-2.61 to /usr/local/bin from /usr/bin
> 
> 
> make[1]: Entering directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> (cd ../../octave-3.2.3-RC1; autoconf --force)
> Can't locate Autom4te/C4che.pm in @INC (@INC contains: /usr/local/share/autoconf
> /usr/lib/perl5/5.6/msys /usr/lib/perl5/
> 5.6 /usr/lib/perl5/site_perl/5.6/msys /usr/lib/perl5/site_perl/5.6 /usr/lib/perl5/site_perl/5.6/msys
> /usr/lib/perl5/site
> _perl/5.6 /usr/lib/perl5/vendor_perl/5.6/msys /usr/lib/perl5/vendor_perl/5.6
> /usr/lib/perl5/vendor_perl/5.6/msys /usr/li
> b/perl5/vendor_perl/5.6 .) at /usr/local/bin/autom4te-2.61 line 39.
> BEGIN failed--compilation aborted at /usr/local/bin/autom4te-2.61 line 39.
> make[1]: *** [configure] Error 2
> make[1]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> make: *** [all] Error 2
> 
> Hello Benjamin
> 
> Can you confirm this?
> Or no problem for yours ?

No I don't see a problem configuring. I am using the same setup as for 
3.2.2.
Sorry I can't really help here.

Did you extract into a clean (i.e. empty) directory ?

benjamin


From lindnerben at gmx.net  Mon Aug 24 14:37:00 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Mon, 24 Aug 2009 21:37:00 +0200
Subject: Unreliable OSX Builds
In-Reply-To: <34716c2e0908240808l6c5cac49ldf4f02f9f176d51d@mail.gmail.com>
References: <34716c2e0908240808l6c5cac49ldf4f02f9f176d51d@mail.gmail.com>
Message-ID: <4A92EBDC.3060909@gmx.net>

Joel LeBlanc wrote:
> I have been building (or trying to build) octave on OSX for some time 
> now.  It didn't work, then I fixed a few things and it did for a couple 
> of weeks, now it won't build again.  Surely I am doing something wrong. 
>  I can't understand how the build process can be so fragile.  There also 
> don't seem to be clear instructions on how to build, and from what I've 
> read in the archives its far from autogen->configure->make.
> 
> For example here is what I'm doing:
> __________________________________________________________
> #! /bin/sh -ev
> 
> ./autogen.sh
> 
> # Apple's vecLib:
> export 
> blas='--with-lapack=-Wl,-framework,Accelerate,-dylib_file,/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib:/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 
> --with-blas=-Wl,-framework,Accelerate,-dylib_file,/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib:/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib'
> 
> 
> # Similar to Fink's configure
> ./configure --prefix=/sw FLIBS=/sw/lib/gcc4.4/lib/libgfortran.dylib 
> F77=/sw/bin/gfortran FC=/sw/bin/gfortran CC=gcc-4 CPP=cpp-4 CXX=g++-4 
> --infodir='${prefix}/share/info' --mandir='${prefix}/share/man' 
> --libexecdir='${prefix}/lib' -enable-shared -enable-dl --disable-static 
> --without-mpi --with-hdf5 --with-fftw CPPFLAGS="-g -I/sw/include 
> -I/sw/include/freetype2 -I/sw/lib/flex/include" FFLAGS="-g -ff2c" 
> LDFLAGS="-L/sw/lib/fltk-aqua/lib -L/sw/lib/flex/lib -L/sw/lib -lfltk_gl 
> -lfltk -lpthread" $blas
> 
> make clean
> make all
> __________________________________________________________
> 
> And the results:
> 
> g++-4 -dynamiclib -single_module -L/sw/lib/fltk-aqua/lib 
> -L/sw/lib/flex/lib -L/sw/lib -lfltk_gl -lfltk -lpthread 
> -L/sw/lib/fltk-aqua/lib -L/sw/lib/flex/lib -L/sw/lib -lfltk_gl -lfltk 
> -lpthread -install_name /sw/lib/octave-3.1.55/liboctinterp.dylib -o 
> liboctinterp.dylib pic/Cell.o pic/bitfcns.o pic/c-file-ptr-stream.o 
> pic/comment-list.o pic/cutils.o pic/data.o pic/debug.o pic/defaults.o 
> pic/defun.o pic/dirfns.o pic/display.o pic/dynamic-ld.o pic/error.o 
> pic/file-io.o pic/gl-render.o pic/graphics.o pic/gripes.o pic/help.o 
> pic/input.o pic/lex.o pic/load-path.o pic/load-save.o pic/ls-hdf5.o 
> pic/ls-mat-ascii.o pic/ls-mat4.o pic/ls-mat5.o pic/ls-oct-ascii.o 
> pic/ls-ascii-helper.o pic/ls-oct-binary.o pic/ls-utils.o pic/main.o 
> pic/mappers.o pic/matherr.o pic/mex.o pic/oct-fstrm.o pic/oct-hist.o 
> pic/oct-iostrm.o pic/oct-map.o pic/oct-obj.o pic/oct-prcstrm.o 
> pic/oct-procbuf.o pic/oct-stream.o pic/octave.o pic/zfstream.o 
> pic/oct-strstrm.o pic/oct-lvalue.o pic/pager.o pic/parse.o 
> pic/pr-output.o pic/procstream.o pic/sighandlers.o pic/siglist.o 
> pic/sparse-xdiv.o pic/sparse-xpow.o pic/strfns.o pic/syscalls.o 
> pic/symtab.o pic/sysdep.o pic/token.o pic/toplev.o pic/txt-eng-ft.o 
> pic/unwind-prot.o pic/utils.o pic/variables.o pic/xdiv.o pic/xnorm.o 
> pic/xpow.o pic/ov-base.o pic/ov-ch-mat.o pic/ov-cs-list.o pic/ov-list.o 
> pic/ov-re-mat.o pic/ov-cx-mat.o pic/ov-range.o pic/ov-scalar.o 
> pic/ov-complex.o pic/ov-str-mat.o pic/ov-struct.o pic/ov-colon.o 
> pic/ov-bool-mat.o pic/ov-bool.o pic/ov-null-mat.o pic/ov-cell.o pic/ov.o 
> pic/ov-fcn.o pic/ov-builtin.o pic/ov-dld-fcn.o pic/ov-mex-fcn.o 
> pic/ov-usr-fcn.o pic/ov-fcn-handle.o pic/ov-fcn-inline.o pic/ov-class.o 
> pic/ov-typeinfo.o pic/ov-flt-re-mat.o pic/ov-flt-cx-mat.o pic/ov-float.o 
> pic/ov-flt-complex.o pic/ov-re-diag.o pic/ov-flt-re-diag.o 
> pic/ov-cx-diag.o pic/ov-flt-cx-diag.o pic/ov-perm.o pic/ov-int8.o 
> pic/ov-int16.o pic/ov-int32.o pic/ov-int64.o pic/ov-uint8.o 
> pic/ov-uint16.o pic/ov-uint32.o pic/ov-uint64.o pic/ov-base-sparse.o 
> pic/ov-bool-sparse.o pic/ov-cx-sparse.o pic/ov-re-sparse.o pic/pt.o 
> pic/pt-arg-list.o pic/pt-assign.o pic/pt-bp.o pic/pt-binop.o 
> pic/pt-cbinop.o pic/pt-cell.o pic/pt-check.o pic/pt-cmd.o pic/pt-colon.o 
> pic/pt-const.o pic/pt-decl.o pic/pt-eval.o pic/pt-except.o pic/pt-exp.o 
> pic/pt-fcn-handle.o pic/pt-id.o pic/pt-idx.o pic/pt-jump.o pic/pt-loop.o 
> pic/pt-mat.o pic/pt-misc.o pic/pt-pr-code.o pic/pt-select.o 
> pic/pt-stmt.o pic/pt-unop.o pic/op-b-b.o pic/op-b-bm.o pic/op-bm-b.o 
> pic/op-bm-bm.o pic/op-cell.o pic/op-chm.o pic/op-class.o pic/op-list.o 
> pic/op-range.o pic/op-str-m.o pic/op-str-s.o pic/op-str-str.o 
> pic/op-struct.o pic/op-double-conv.o pic/op-cm-cm.o pic/op-cm-cs.o 
> pic/op-cm-m.o pic/op-cm-s.o pic/op-cs-cm.o pic/op-cs-cs.o pic/op-cs-m.o 
> pic/op-cs-s.o pic/op-m-cm.o pic/op-m-cs.o pic/op-m-m.o pic/op-m-s.o 
> pic/op-s-cm.o pic/op-s-cs.o pic/op-s-m.o pic/op-s-s.o 
> pic/op-float-conv.o pic/op-fcm-fcm.o pic/op-fcm-fcs.o pic/op-fcm-fm.o 
> pic/op-fcm-fs.o pic/op-fcs-fcm.o pic/op-fcs-fcs.o pic/op-fcs-fm.o 
> pic/op-fcs-fs.o pic/op-fm-fcm.o pic/op-fm-fcs.o pic/op-fm-fm.o 
> pic/op-fm-fs.o pic/op-fs-fcm.o pic/op-fs-fcs.o pic/op-fs-fm.o 
> pic/op-fs-fs.o pic/op-int-concat.o pic/op-int-conv.o pic/op-i8-i8.o 
> pic/op-i16-i16.o pic/op-i32-i32.o pic/op-i64-i64.o pic/op-ui8-ui8.o 
> pic/op-ui16-ui16.o pic/op-ui32-ui32.o pic/op-ui64-ui64.o pic/op-bm-sbm.o 
> pic/op-b-sbm.o pic/op-cm-scm.o pic/op-cm-sm.o pic/op-cs-scm.o 
> pic/op-cs-sm.o pic/op-m-scm.o pic/op-m-sm.o pic/op-sbm-b.o 
> pic/op-sbm-bm.o pic/op-sbm-sbm.o pic/op-scm-cm.o pic/op-scm-cs.o 
> pic/op-scm-m.o pic/op-scm-s.o pic/op-scm-scm.o pic/op-scm-sm.o 
> pic/op-sm-cm.o pic/op-sm-cs.o pic/op-sm-m.o pic/op-sm-s.o 
> pic/op-sm-scm.o pic/op-sm-sm.o pic/op-s-scm.o pic/op-s-sm.o 
> pic/op-cdm-cdm.o pic/op-cdm-cm.o pic/op-cdm-cs.o pic/op-cdm-dm.o 
> pic/op-cdm-m.o pic/op-cdm-s.o pic/op-cm-cdm.o pic/op-cm-dm.o 
> pic/op-dm-cdm.o pic/op-dm-cm.o pic/op-dm-cs.o pic/op-dm-dm.o 
> pic/op-dm-m.o pic/op-dm-s.o pic/op-m-cdm.o pic/op-m-dm.o pic/op-dm-sm.o 
> pic/op-dm-scm.o pic/op-fcdm-fcdm.o pic/op-fcdm-fcm.o pic/op-fcdm-fcs.o 
> pic/op-fcdm-fdm.o pic/op-fcdm-fm.o pic/op-fcdm-fs.o pic/op-fcm-fcdm.o 
> pic/op-fcm-fdm.o pic/op-fdm-fcdm.o pic/op-fdm-fcm.o pic/op-fdm-fcs.o 
> pic/op-fdm-fdm.o pic/op-fdm-fm.o pic/op-fdm-fs.o pic/op-fm-fcdm.o 
> pic/op-fm-fdm.o pic/op-cm-pm.o pic/op-fcm-pm.o pic/op-fm-pm.o 
> pic/op-pm-fcm.o pic/op-pm-fm.o pic/op-m-pm.o pic/op-pm-cm.o 
> pic/op-pm-m.o pic/op-pm-pm.o pic/op-pm-sm.o pic/op-pm-scm.o 
> pic/Array-os.o pic/Array-tc.o pic/oct-errno.o pic/builtins.o pic/ops.o 
> ../libcruft/blas-xtra/pic/xerbla.o  -L../liboctave -loctave 
> -L../libcruft -lcruft  -lfftw3 -lfftw3f  -lhdf5  -lz -L/usr/X11/lib 
> -lfontconfig -lftgl -L/sw/lib -lfreetype -lz -Wl,-framework,CoreServices 
> -Wl,-framework,ApplicationServices -Wl,-framework -Wl,OpenGL 
> -L/usr/X11/lib -lX11 -Wl,-framework -Wl,Carbon -lreadline -lm 
> Undefined symbols:
>   "__gfortran_st_write", referenced from:
>       _xerbla_ in xerbla.o
>   "__gfortran_st_write_done", referenced from:
>       _xerbla_ in xerbla.o
>   "__gfortran_transfer_character", referenced from:
>       _xerbla_ in xerbla.o
>   "__gfortran_transfer_integer", referenced from:
>       _xerbla_ in xerbla.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[2]: *** [liboctinterp.dylib] Error 1
> make[1]: *** [src] Error 2
> make: *** [all] Error 2
> miys02-leblanpb2:octave leblanc$
> 
> 
> Is there a reliable way to get things built?  Do any of the developers 
> work on OSX, or is there a procedure that SHOULD result in a successful 
> build?  How do I get to the current stable code (I'm assuming the HEAD 
> is the "testing/devepment" code).
> 
> I apologize in advance for my ignorance,
> 

The same error currently prevents the development sources build on 
mingw32 gcc.
There have been changes in the compile&link code in the makefiles and 
it's apparently not fully fixed yet.

See also the thread at 
http://www.nabble.com/linking-liboctave-fails-%28lapack-missing-%29-td24958887.html

benjamin

From lindnerben at gmx.net  Mon Aug 24 14:49:24 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Mon, 24 Aug 2009 21:49:24 +0200
Subject: 3.2.3 RC1
In-Reply-To: <69d8d540908240158v634b5d0aj71554f0505a78395@mail.gmail.com>
References: <69d8d540908240158v634b5d0aj71554f0505a78395@mail.gmail.com>
Message-ID: <4A92EEC4.9080609@gmx.net>

Jaroslav Hajek wrote:
> hi all,
> 
> I want to make 3.2.3 in the first half of September. The 1st release
> candidate tarballs for 3.2.3 are available at:
> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/

Building on mingw32 tdm-gcc-4.3.0-3 completes fine.
Make check also OK with the already known failures.

Summary:

   PASS   5744
   FAIL     10

benjamin

From lindnerben at gmx.net  Mon Aug 24 15:01:29 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Mon, 24 Aug 2009 22:01:29 +0200
Subject: overriding print.m pdf default terminal choices?
In-Reply-To: <4A89AA20.3060802@gmx.net>
References: <150650070158267485735317469619294396129-Webmail@me.com>	<152987640169990211162329315010467704320-Webmail@me.com>
	<4A89AA20.3060802@gmx.net>
Message-ID: <4A92F199.3090305@gmx.net>

Benjamin Lindner wrote:
> Ben Abbott wrote:
>> On Monday, August 17, 2009, at 11:27AM, "Benjamin Lindner" 
>> <lindnerben at gmx.net> wrote:
>>> Hello list,
>>>
>>> I wondered if it is possible to force print.m to use ghostscript for
>>> printing to pdf even if gnuplot provides a pdfcairo terminal?
>>>
>>> I ask because the last available gnuplot for win32 does not include the
>>> patch which fixes the spurious-pages-in-pdf-output bug.
>>> So a command as
>>>  plot(0:0.1:10, sin(0:0.1:10), "@-"); print -dpdf test.pdf
>>> produces a three-page pdf.
>>>
>>> I don't know when there will be a new gnuplot release or snapshot
>>> release but the do not happen very frequently.
>>>
>>> So for the mingw32 binaries I'd like to have print.m to use ps->pdf via
>>> ghostscript for the moment.
>>>
>>> benjamin
>>
>> I assume you are referring to Octave's latest sources, and that you 
>> are not running gnuplot's development sources (meaning your version of 
>> gnuplot is 4.2.x, or earlier)?
> 
> Actually I'm referring to the 3.2.x branch of octave and the latest 
> version of gnuplot available is the 2008-11-21 4.3.0 cvs snapshot.
> 
>> If so then, what you're asking for should be the default. If it is 
>> not, then the check for ghostscript may be failing.
>>
>> Does the code below indicate you have ghostscript installed?
>>
>>     if (~isempty (getenv ("GSC")))
>>       persistent ghostscript_binary = getenv ("GSC");
>>     else
>>       persistent ghostscript_binary = "gswin32c";
>>     endif
>>     [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1 ) 
>> else ( exit /B 0 )", ghostscript_binary));
>>     have_ghostscript = (status == 0)
>>
>> Ben
>>
> 
> thanks for the hint.
> 
> I have the environment variable GSC defined as
> 
>  > ghostscript_binary = getenv("GSC")
> ghostscript_binary = C:\Programs\gs\gs8.62\bin\gswin32c.exe
> 
> and naturally this executable exists.
> However, have_ghostscript evaluates to false.
> 
> This is strange.
> Seems the exit code is not propagated into the variable status, as
> 
>  > [s,o]=system("exit 1")
> s =  127
> o =
> 
> but
> 
>  > system("exit 1")
> ans =  1
> 
> I need to investigate this further.
> 

Ben, I think your code snippet above is out of date.
In both 3.2.3 and current development tip I have

elseif (ispc ())
       [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1 
) else ( exit /B 0 )", ghostscript_binary));
       have_ghostscript = (status ~= 0);
endif

The fact that calling system with two outputs does not return the 
correct exit code on windows aside, I end up with have_ghostscript = 1.
I use the 4.3.0-cvs snapshot of 2008-11-21 (from the gnuplot homepage) 
and built with support for the pdfcairo terminal.

The result being that print uses the pdfcairo terminal, because it is 
preferred over an available ghostscript.

And I'm back again at my first question: Is there an easy way to make 
print.m prefer the ghostscript way?
Or do I need to provide a 4.3.0 version of gnuplot without the cairo 
terminals?

benjamin

From rob at utk.edu  Mon Aug 24 16:04:08 2009
From: rob at utk.edu (Rob Mahurin)
Date: Mon, 24 Aug 2009 17:04:08 -0400
Subject: 3.2.3 RC1
In-Reply-To: <69d8d540908240158v634b5d0aj71554f0505a78395@mail.gmail.com>
References: <69d8d540908240158v634b5d0aj71554f0505a78395@mail.gmail.com>
Message-ID: <9AEEE545-038A-4301-9476-5FD493567B03@utk.edu>

On Aug 24, 2009, at 4:58 AM, Jaroslav Hajek wrote:
> I want to make 3.2.3 in the first half of September. The 1st release
> candidate tarballs for 3.2.3 are available at:
> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/

I can build and run on Mac OSX 10.4.11, powerpc/G4, dependencies via  
MacPorts, with the configure line

./configure LDFLAGS=-L/opt/local/lib LIBS=-lmetis CPPFLAGS=-I/opt/ 
local/include FFLAGS=-ff2c

I get a segfault when "make check" processes src/data.cc.

Running "test data" within octave gives and error, but no crash:

Mon 16:43 $ nice ./run-octave -q
octave:1> test data
   ***** assert (hypot (single(1:10), single(1:10)), single(sqrt(2) *  
[1:10]));
!!!!! test failed
assert (hypot (single (1:10), single (1:10)),single (sqrt (2) *  
[1:10])) expected
octave:3> (hypot (single (1:10), single (1:10))-single (sqrt (2) *  
[1:10]))./eps('single')
ans =

    0   0   0   0   0   0   0   0  -8   0

Running under the debugger with
  ../run-octave -g  --norc --silent --no-history ./fntests.m .

gives an 83-level backtrace I've pasted into an attachment.  Advice?

Rob

-- 
Rob Mahurin
University of Manitoba, Dept. of Physics & Astronomy
at:	Oak Ridge National Laboratory	865 207 2594
	Oak Ridge, Tennessee		rob at utk.edu



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: backtrace.txt
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090824/e330ad0c/attachment.txt 

From bpabbott at mac.com  Mon Aug 24 17:43:14 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Mon, 24 Aug 2009 18:43:14 -0400
Subject: overriding print.m pdf default terminal choices?
In-Reply-To: <4A92F199.3090305@gmx.net>
References: <150650070158267485735317469619294396129-Webmail@me.com>
	<152987640169990211162329315010467704320-Webmail@me.com>
	<4A89AA20.3060802@gmx.net> <4A92F199.3090305@gmx.net>
Message-ID: <40068F1C-C18D-48A6-8B9E-AC0BFC2AF27C@mac.com>

On Aug 24, 2009, at 4:01 PM, Benjamin Lindner wrote:

> Benjamin Lindner wrote:
>> Ben Abbott wrote:
>>> On Monday, August 17, 2009, at 11:27AM, "Benjamin Lindner" <lindnerben at gmx.net 
>>> > wrote:
>>>> Hello list,
>>>>
>>>> I wondered if it is possible to force print.m to use ghostscript  
>>>> for
>>>> printing to pdf even if gnuplot provides a pdfcairo terminal?
>>>>
>>>> I ask because the last available gnuplot for win32 does not  
>>>> include the
>>>> patch which fixes the spurious-pages-in-pdf-output bug.
>>>> So a command as
>>>> plot(0:0.1:10, sin(0:0.1:10), "@-"); print -dpdf test.pdf
>>>> produces a three-page pdf.
>>>>
>>>> I don't know when there will be a new gnuplot release or snapshot
>>>> release but the do not happen very frequently.
>>>>
>>>> So for the mingw32 binaries I'd like to have print.m to use ps- 
>>>> >pdf via
>>>> ghostscript for the moment.
>>>>
>>>> benjamin
>>>
>>> I assume you are referring to Octave's latest sources, and that  
>>> you are not running gnuplot's development sources (meaning your  
>>> version of gnuplot is 4.2.x, or earlier)?
>> Actually I'm referring to the 3.2.x branch of octave and the latest  
>> version of gnuplot available is the 2008-11-21 4.3.0 cvs snapshot.
>>> If so then, what you're asking for should be the default. If it is  
>>> not, then the check for ghostscript may be failing.
>>>
>>> Does the code below indicate you have ghostscript installed?
>>>
>>>    if (~isempty (getenv ("GSC")))
>>>      persistent ghostscript_binary = getenv ("GSC");
>>>    else
>>>      persistent ghostscript_binary = "gswin32c";
>>>    endif
>>>    [status, output] = system (sprintf ("if exist \"%s\" ( exit /B  
>>> 1 ) else ( exit /B 0 )", ghostscript_binary));
>>>    have_ghostscript = (status == 0)
>>>
>>> Ben
>>>
>> thanks for the hint.
>> I have the environment variable GSC defined as
>> > ghostscript_binary = getenv("GSC")
>> ghostscript_binary = C:\Programs\gs\gs8.62\bin\gswin32c.exe
>> and naturally this executable exists.
>> However, have_ghostscript evaluates to false.
>> This is strange.
>> Seems the exit code is not propagated into the variable status, as
>> > [s,o]=system("exit 1")
>> s =  127
>> o =
>> but
>> > system("exit 1")
>> ans =  1
>> I need to investigate this further.
>
> Ben, I think your code snippet above is out of date.
> In both 3.2.3 and current development tip I have
>
> elseif (ispc ())
>      [status, output] = system (sprintf ("if exist \"%s\" ( exit /B  
> 1 ) else ( exit /B 0 )", ghostscript_binary));
>      have_ghostscript = (status ~= 0);
> endif
>
> The fact that calling system with two outputs does not return the  
> correct exit code on windows aside, I end up with have_ghostscript =  
> 1.
> I use the 4.3.0-cvs snapshot of 2008-11-21 (from the gnuplot  
> homepage) and built with support for the pdfcairo terminal.
>
> The result being that print uses the pdfcairo terminal, because it  
> is preferred over an available ghostscript.
>
> And I'm back again at my first question: Is there an easy way to  
> make print.m prefer the ghostscript way?
> Or do I need to provide a 4.3.0 version of gnuplot without the cairo  
> terminals?
>
> benjamin

You are correct. Thanks for catching my error.

Although others have expressed a preference for the cairo terminals, I  
have no objection the changing the preferred default to use  
Ghostscript. There is one feature of the postscript terminal that  
concerns me. The ghostcript terminal explicitly sets the BBOX to be  
50pts inside the edge of the page. This often results in text being  
clipped with printed.

Perhaps print() should be rewritten to crop ps output at the BBOX? If  
so a 50pt border added to the pagesize and then clipped by  
ghostscript. Once that is done, we could also produce eps output by  
converting a postscript file. This would be nice as gnuplot's eps  
terminal scales down the size of the fonts.

The only problem with that is we currently don't have ghostscript as a  
run time dependency. Should that be changed?

In any event, I'm presently not able to build octave, am weary of  
producing any changesets until I can.

Ben



From tmacchant at yahoo.co.jp  Mon Aug 24 20:46:25 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Tue, 25 Aug 2009 10:46:25 +0900 (JST)
Subject: 3.2.3 RC1
In-Reply-To: <20090824110238.8477.qmail@web3812.mail.bbt.yahoo.co.jp>
Message-ID: <20090825014625.54619.qmail@web3802.mail.bbt.yahoo.co.jp>

Hello

Sorry!
The error comes from two origin.
The patch
http://hg.savannah.gnu.org/hgweb/octave/rev/69d05d1a63b9
--- a/configure.in	Fri Jun 26 21:12:09 2009 +0100
+++ b/configure.in	Thu Jul 09 15:04:34 2009 -0400
@@ -1654,8 +1654,8 @@
 esac
 
 case "$canonical_host_type" in
-  *-*-msdosmsvc)
-    ## The %T format specifier for strftime is reportedly broken,
+  *-*-msdosmsvc | *-*-mingw*)
+    ## The %T and %e format specifiers for strftime are not implemented
     ## so use our version.  We could use an actual configure test
     ## for this.
   ;;
The reversing this patch is necesarry for my case.

causes error at the link.
So I rewrote  the configure.in.  Therefore autoconf was executed.


In addition, autoconf for my msys seemed to be broken.
I have update the latest Msys-1.0.11 (Sat Jul 18 2009 ).

The updating msys seemed to work fine. The make process is now proceeding.

Thanks!!

Tatsuro 


--- Tatsuro MATSUOKA wrote:

> Hello
> 
> Perhaps the problem relies on msys autoconf ???.
> 
> I have copied the autom4te-2.61 to /usr/local/bin from /usr/bin
> 
> 
> make[1]: Entering directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> (cd ../../octave-3.2.3-RC1; autoconf --force)
> Can't locate Autom4te/C4che.pm in @INC (@INC contains: /usr/local/share/autoconf
> /usr/lib/perl5/5.6/msys /usr/lib/perl5/
> 5.6 /usr/lib/perl5/site_perl/5.6/msys /usr/lib/perl5/site_perl/5.6
> /usr/lib/perl5/site_perl/5.6/msys
> /usr/lib/perl5/site
> _perl/5.6 /usr/lib/perl5/vendor_perl/5.6/msys /usr/lib/perl5/vendor_perl/5.6
> /usr/lib/perl5/vendor_perl/5.6/msys /usr/li
> b/perl5/vendor_perl/5.6 .) at /usr/local/bin/autom4te-2.61 line 39.
> BEGIN failed--compilation aborted at /usr/local/bin/autom4te-2.61 line 39.
> make[1]: *** [configure] Error 2
> make[1]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> make: *** [all] Error 2
> 
> Hello Benjamin
> 
> Can you confirm this?
> Or no problem for yours ?
> 
> Regards
> 
> Tatsuro
> 
> --- Tatsuro MATSUOKA wrote:
> 
> > Hello
> > 
> > make -f octMakefile all
> > make[1]: Entering directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> > (cd ../../octave-3.2.3-RC1; autoconf --force)
> > /bin/autoconf-2.61: line 582: /usr/local/bin/autom4te-2.61: No such file or directory
> > /bin/autoconf-2.61: line 582: exec: /usr/local/bin/autom4te-2.61: cannot execute: No such file
> > or
> > directory
> > make[1]: *** [configure] Error 126
> > make[1]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> > make: *** [all] Error 2
> > 
> > /bin/autoconf-2.61 ??
> > 
> > Had not the issue of autoconf-2.6  been discussed and resolved ?
> > 
> > Regards
> > 
> > Tatsuro 
> > 
> > --- Jaroslav Hajek <highegg at gmail.com> wrote:
> > 
> > > hi all,
> > > 
> > > I want to make 3.2.3 in the first half of September. The 1st release
> > > candidate tarballs for 3.2.3 are available at:
> > > http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> > > 
> > > changes since 3.2.2:
> > > 
> > > changeset:   9380:193174bc5107
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Wed Jul 08 13:49:21 2009 -0400
> > > summary:     dim-vector.h: dim vectors always have two dimensions
> > > 
> > > changeset:   9381:4290384284b7
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Wed Jul 08 14:06:53 2009 -0400
> > > summary:     pt-assign.cc (maybe_warn_former_built_in_variable): improve message
> > > 
> > > changeset:   9382:cd95695a0a89
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Thu Jul 09 15:04:34 2009 -0400
> > > summary:     configure.in: don't use system strftime on MinGW systems
> > > 
> > > changeset:   9383:941b8414b99e
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Sat Jul 11 12:46:10 2009 -0400
> > > summary:     file-ops.cc (file_ops::symlink, file_ops::readlink):
> > > avoid incorrectly sized buffer
> > > 
> > > changeset:   9384:44300eb51817
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Thu Jul 16 11:56:44 2009 -0400
> > > summary:     graphics.cc (get_array_limits): require min_pos value to
> > > be greater than zero
> > > 
> > > changeset:   9385:9aea00e4e000
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Sat Jul 25 16:16:59 2009 +0200
> > > summary:     Makeconf.in (MAGICK_LIBS): Don't pass --ldflags to $(MAGICK_CONFIG)
> > > 
> > > changeset:   9386:6ddb81224550
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Sat Jul 25 16:17:27 2009 +0200
> > > summary:     __go_draw_axes__.m: also use layer property for plot border
> > > 
> > > changeset:   9387:b308b2e12f04
> > > user:        Benjamin Lindner <lindnerb at users.sourceforge.net>
> > > date:        Sat Jul 25 16:20:05 2009 +0200
> > > summary:     determine correct image bitwidth in __magick_read__.cc
> > > 
> > > changeset:   9388:a8a44f20ef3b
> > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > date:        Sat Jul 25 16:20:35 2009 +0200
> > > summary:     fix signed integer shift
> > > 
> > > changeset:   9389:3602403af9b8
> > > user:        Aleksej Saushev <asau at inbox.ru>
> > > date:        Sat Jul 25 16:21:51 2009 +0200
> > > summary:     initialize floating point values properly for NetBSD systems
> > > 
> > > changeset:   9390:83d604a4e803
> > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > date:        Sat Jul 25 16:22:40 2009 +0200
> > > summary:     fix Cholesky updating with scalars
> > > 
> > > changeset:   9391:c4f89df90e43
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Sat Jul 25 16:26:01 2009 +0200
> > > summary:     avoid complex -> real conversion when constructing arrays with []
> > > 
> > > changeset:   9392:6a6779e895d4
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Tue Aug 04 09:52:53 2009 +0200
> > > summary:     correctly parse things like '@(){1 2}'
> > > 
> > > changeset:   9393:18b8a3aa034c
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Tue Aug 04 09:55:38 2009 +0200
> > > summary:     use complex function for acos mapper if arg is out of range [-1, 1]
> > > 
> > > changeset:   9394:f1dd244757cd
> > > user:        Ben Abbott <bpabbott at mac.com>
> > > date:        Thu Aug 06 07:18:53 2009 +0200
> > > summary:     __go_draw_axes__.m: Fix ticklabels specified as 2D character array.
> > > 
> > > changeset:   9395:54a3fa5d4376
> > > user:        Ben Abbott <bpabbott at mac.com>
> > > date:        Thu Aug 06 07:30:34 2009 +0200
> > > summary:     Avoid the flickering x11 window seen with rapid gnuplot updates.
> > > 
> > > changeset:   9396:9107c882f193
> > > user:        Olli Saarela <olli.saarela at gmail.com>
> > > date:        Thu Aug 06 07:31:45 2009 +0200
> > > summary:     __gnuplot_get_var__: if read fails to return data, sleep
> > > before trying again
> > > 
> > > changeset:   9397:16181105aeb6
> > > user:        Pieter Eendebak <pieter.eendebak at gmail.com>
> > > date:        Thu Aug 06 07:32:53 2009 +0200
> > > summary:     support cellstrs in setxor
> > > 
> > > changeset:   9398:21038fd51788
> > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > date:        Fri Aug 07 08:11:49 2009 +0200
> > > summary:     implant tree_index_expression::lvalue from development version
> > > 
> > > changeset:   9399:0014ff1747a6
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Fri Aug 07 08:13:22 2009 +0200
> > > summary:     use key list order for iterating through map with for loop
> > > 
> > > changeset:   9400:3db13615d39a
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Fri Aug 07 08:15:27 2009 +0200
> > > summary:     handle null matrix assignment for diagonal and permutation matrices
> > > 
> > > changeset:   9401:3a4da80f4adc
> > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > date:        Fri Aug 07 08:22:13 2009 +0200
> > > summary:     complete change d5570d4b1116
> > > 
> > > changeset:   9402:1d5a487a01cf
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Mon Aug 10 11:14:46 2009 +0200
> > > summary:     parse.y (Fevalin): also return output from CATCH expression
> > > 
> > > changeset:   9403:a29f3eba78a2
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Thu Aug 13 07:56:00 2009 +0200
> > > summary:     new option, --no-window-system
> > > 
> > > changeset:   9404:1347fcb231bd
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Sun Aug 23 11:09:17 2009 +0200
> > > summary:     dlmread: perform tilde expansion to filename argument
> > > 
> > > changeset:   9405:3a65f1038bdb
> > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > date:        Sun Aug 23 11:10:05 2009 +0200
> > > summary:     fix some functions help markup
> > > 
> > > changeset:   9406:4963bb455582
> > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > date:        Sun Aug 23 11:10:35 2009 +0200
> > > summary:     fix typos in complex xgemm
> > > 
> > > changeset:   9407:1371eecefd99
> > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > date:        Sun Aug 23 11:11:27 2009 +0200
> > > summary:     make single prec. matrix mutliply tests really single
> > > 
> > > changeset:   9408:9e66af7e1593
> > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > date:        Sun Aug 23 11:11:27 2009 +0200
> > > summary:     more fixes & tests for matrix multiply
> > > 
> > > changeset:   9409:f0d18d74a519
> > > user:        John W. Eaton <jwe at octave.org>
> > > date:        Sun Aug 23 11:12:16 2009 +0200
> > > summary:     acx_blas_f77_func.m4 (ACX_BLAS_F77_FUNC): Save and restore LIBS
> > > 
> > > changeset:   9410:c3d37d2a2b55
> > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > date:        Sun Aug 23 11:12:35 2009 +0200
> > > summary:     zero matrix assignment fix
> > > 
> > > changeset:   9411:d208ae6e9d74
> > > user:        David Bateman <dbateman at free.fr>
> > > date:        Mon Aug 24 10:02:47 2009 +0200
> > > summary:     Fix test for setting of datasource properties. Add the
> > > edgecolor property to contours
> > > 
> > > changeset:   9412:8e69b1d41c03
> > > tag:         qparent
> > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > date:        Mon Aug 24 10:06:52 2009 +0200
> > > summary:     fix typo in acx_blas_f77_func.m4
> > > 
> > > In case your favorite patch is missing, now would be a good time to mention it.
> > > 
> > > regards
> > > 
> > > -- 
> > > RNDr. Jaroslav Hajek
> > > computing expert & GNU Octave developer
> > > Aeronautical Research and Test Institute (VZLU)
> > > Prague, Czech Republic
> > > url: www.highegg.matfyz.cz
> > > 
> > 
> > 
> > --------------------------------------
> > 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/

From lindnerben at gmx.net  Mon Aug 24 23:51:05 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Tue, 25 Aug 2009 06:51:05 +0200
Subject: 3.2.3 RC1
In-Reply-To: <4A92EEC4.9080609@gmx.net>
References: <69d8d540908240158v634b5d0aj71554f0505a78395@mail.gmail.com>
	<4A92EEC4.9080609@gmx.net>
Message-ID: <4A936DB9.8060801@gmx.net>

Benjamin Lindner wrote:
> Jaroslav Hajek wrote:
>> hi all,
>>
>> I want to make 3.2.3 in the first half of September. The 1st release
>> candidate tarballs for 3.2.3 are available at:
>> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> 
> Building on mingw32 tdm-gcc-4.3.0-3 completes fine.
> Make check also OK with the already known failures.
> 
> Summary:
> 
>   PASS   5744
>   FAIL     10
> 
> benjamin
> 

I forgot to mention that I require the fix at the end of the thread
http://www.nabble.com/%22dir%22-crashing-oactve-3.2.0-mingw32-td24234760.html
to successfully link.

benjamin

From lindnerben at gmx.net  Mon Aug 24 23:51:48 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Tue, 25 Aug 2009 06:51:48 +0200
Subject: 3.2.3 RC1
In-Reply-To: <20090825014625.54619.qmail@web3802.mail.bbt.yahoo.co.jp>
References: <20090825014625.54619.qmail@web3802.mail.bbt.yahoo.co.jp>
Message-ID: <4A936DE4.5050803@gmx.net>

Tatsuro MATSUOKA wrote:
> Hello
> 
> Sorry!
> The error comes from two origin.
> The patch
> http://hg.savannah.gnu.org/hgweb/octave/rev/69d05d1a63b9
> --- a/configure.in	Fri Jun 26 21:12:09 2009 +0100
> +++ b/configure.in	Thu Jul 09 15:04:34 2009 -0400
> @@ -1654,8 +1654,8 @@
>  esac
>  
>  case "$canonical_host_type" in
> -  *-*-msdosmsvc)
> -    ## The %T format specifier for strftime is reportedly broken,
> +  *-*-msdosmsvc | *-*-mingw*)
> +    ## The %T and %e format specifiers for strftime are not implemented
>      ## so use our version.  We could use an actual configure test
>      ## for this.
>    ;;
> The reversing this patch is necesarry for my case.

But then calls to strftime might segfault, as numerous bugs have been 
reported on this.

See the thread at 
http://www.nabble.com/%22dir%22-crashing-oactve-3.2.0-mingw32-td24234760.html
for a fix for the link error.


> causes error at the link.
> So I rewrote  the configure.in.  Therefore autoconf was executed.
> 
> In addition, autoconf for my msys seemed to be broken.
> I have update the latest Msys-1.0.11 (Sat Jul 18 2009 ).

I also ran into some issues with the newly relased packages. I tried to 
cirumvent it by *not* using the "mingw32" versions, rather than the 
"msys" versions.
This is not what's suggested, but it worked for me, at least up to now.

benjamin



From thomas.weber.mail at gmail.com  Tue Aug 25 00:55:36 2009
From: thomas.weber.mail at gmail.com (Thomas Weber)
Date: Tue, 25 Aug 2009 07:55:36 +0200
Subject: [changeset] GraphicsMagick++ configuration
In-Reply-To: <20090816210909.GA15975@atlan>
References: <4A7AEEF4.2070101@acc.umu.se>
	<19066.62968.137520.390478@segfault.lan>
	<4A7B3868.9020001@acc.umu.se>
	<19067.14844.220747.257229@segfault.lan>
	<20090816210909.GA15975@atlan>
Message-ID: <20090825055536.GA7737@atlan>

On Sun, Aug 16, 2009 at 11:09:09PM +0200, Thomas Weber wrote:
> On Thu, Aug 06, 2009 at 04:15:56PM -0400, John W. Eaton wrote:
> > On  6-Aug-2009, David Grundberg wrote:
> > 
> > | John W. Eaton skrev:
> > | > On  6-Aug-2009, David Grundberg wrote:
> > | >
> > | > | I've rearranged the GraphicsMagick++ configuration. I had some trouble 
> > | > | since I'm running a custom GraphicsMagick installation. The Octave build 
> > | > | system was running GraphicsMagick++-config during make. It was missing 
> > | > | ldflags and using only the basename of the config executable (as opposed 
> > | > | to a full path).
> > | > | 
> > | > | I've changed it so that GraphicsMagick++-config is only run in the 
> > | > | configure script. Also introduced MAGICK_CONFIG as a precious variable.
> > | >
> > | > I removed --ldflags to fix the following mysterious problem on my
> > | > system:
> > | >
> > | >   https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-July/012879.html
> > | >
> > | > So I don't think I can put it back without breaking __magick_read__
> > | > again, at least for me and other Debian users.
> > | >
> > | > What are -Wl,-z,relro and -pie doing in the ldflags anyway?  Are those
> > | > arguments not present on your system?  Maybe they are present on mine
> > | > because of the way Debian builds the graphics magick library package?
> > | > Perhaps these flags make sense for creating the graphics magick
> > | > library itself, but I can't see any reason for them to be required to
> > | > link the graphics magick library with __magick_read__.oct.
> > | >
> > | > jwe
> > | >   
> > | So that's why --ldflags was taken away! I don't have that problem. This 
> > | is the output from my config (where I'm building):
> > | 
> > | $ 
> > | octave-patching/dependencies/graphicsmagick-install/bin/GraphicsMagick++-config 
> > | --ldflags --libs
> > | -L/Home/staff/davidg/octave-patching/dependencies/graphicsmagick-install/lib 
> > | -L/usr/lib -L/usr/lib
> > | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper 
> > | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm 
> > | -lgomp -lpthread
> > | 
> > | My ubuntu 9.04 box says this about the managed package (haven't tried 
> > | building against it):
> > | david at lack:~$ GraphicsMagick++-config --ldflags --libs
> > | -L/usr/lib -Wl,-Bsymbolic-functions -L/usr/lib/X11 -L/usr/lib -L/usr/lib
> > | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper 
> > | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm 
> > | -lpthread
> > 
> > So what should we do about this?  
> 
> These are different versions. The Ubuntu version is 1.1.11-something,
> your Debian versions is 1.3.5-something.
> 
> > around it by filtering out everything except -L options from the
> > --ldflags output, but I'd rather see it fixed in graphics magick.
> > What should graphics magick really be storing in the config script
> > for --ldflags?  Should options like -pie and -Wl,-z,relro really
> > appear there?  Or is this just a Debian packaging problem?
> 
> The Debian packaging adds the -pie and -Wl options when building
> GraphicsMagick to the LDFLAGS. GraphicsMagick then copies LDFLAGS into its
> --ldflags output. Looking at Ubuntu's build logs, the same is already
> happening with newer versions of graphicsmagick.
> 
> I'll ask the Debian maintainer of GraphicsMagick about it.

Okay, his answer is below. Short version: we should go we with
pkg-config.

============================================================================
Historically, the output of the *Magick*config scripts has been documented as
the list of compiler/linker options *Magick was built with. This makes sense
when build additional modules, but it's rather nonsensical for anything that
just wants to link the C or C++ bindings. I recommend to use pkg-config for
these kinds of applications instead. The hardening options aren't included
there.
============================================================================

	Thomas

From lindnerben at gmx.net  Tue Aug 25 01:12:51 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Tue, 25 Aug 2009 08:12:51 +0200
Subject: 3.2.3 RC1
Message-ID: <20090825061251.205040@gmx.net>

Hello,

The imread/imfinfo issue as reported in
http://www.nabble.com/imgwrite-imfinfo-fail-in-octave-3.2.x-td25004136.html
should also be fixed before releasing a new 3.2.x version.

Unfortunately there is no test of the imread/imwrite/imfinfo scripts in the 3.2.x branch, thus it does not show in "make check", so I missed it at first...

benjamin
-- 
GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

From highegg at gmail.com  Tue Aug 25 02:11:48 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 25 Aug 2009 09:11:48 +0200
Subject: Unreliable OSX Builds
In-Reply-To: <34716c2e0908241211o30fe1645v2f89199e959b186e@mail.gmail.com>
References: <34716c2e0908240808l6c5cac49ldf4f02f9f176d51d@mail.gmail.com>
	<4A92DE3D.7060009@gmx.net>
	<34716c2e0908241211o30fe1645v2f89199e959b186e@mail.gmail.com>
Message-ID: <69d8d540908250011s7c0d6021i1eaacbf553e0c037@mail.gmail.com>

On Mon, Aug 24, 2009 at 9:11 PM, Joel LeBlanc<jwleblan at gmail.com> wrote:
> I'm not nearly talented enough to get this thing built with any confidence.
> ?For a while, I "fixed" something by adding "-L/sw/lib/fltk-aqua/lib
> -L/sw/lib/flex/lib -L/sw/lib -lfltk_gl -lfltk" to the configure statement
> (see my original post).
> It seems that autoconf is completely unaware that port and fink produce /opt
> and /sw folders that are highly likely to contain the libraries your gonna
> need. ?I'd try to help, but seriously, my ineptitude in such matters is
> staggering ; )



> What worries me is that it won't build... regularly.

In the past few weeks, a lot of us experienced build problems, because
John was making major changes to the configuration part. I think it's
mostly settled, but if things still don't work for you, more tweaks
are probably needed. I hope you understand, though, that without OSX
users actually participating in development there's not much chance to
ensure flawless builds on OSX.

> It released without being able to be built. ?How can this thing possibly be passing testing, and
> get to a released, if it won't even build?

Believe it or not, the release did build for a lot of people - in
fact, nobody reported a build failure, so that's why it was released.
Had you participated in the testing, you could have made a difference.

> It's too bad. ?I'd really like to contribute to testing (I'm a power Matlab
> user), but I'm basically being left out. ?Imagine the average Matlab user,
> they're not going to tweak configure flags.

So what?

> As a result, they'll never even
> have a chance to give feedback because it'll never build.
> I guess bringing it up in the forums (is this really a forum?), is the best
> way to start moving toward a fix.

Well, yes, but it's like "going out of your door is the best way to
start hiking". Someone needs to find out what's wrong, work out a fix,
make a patch and then apply it. I (and not just I) will gladly do the
last bit for you and possibly even assist you in the third one.

> Thanks for the feedback guys!
> ~Joel
>



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


From tmacchant at yahoo.co.jp  Tue Aug 25 02:49:09 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Tue, 25 Aug 2009 16:49:09 +0900 (JST)
Subject: 3.2.3 RC1
In-Reply-To: <20090825014625.54619.qmail@web3802.mail.bbt.yahoo.co.jp>
Message-ID: <20090825074909.44617.qmail@web3802.mail.bbt.yahoo.co.jp>

Hello

The 'make' stopped at

g++ -shared-libgcc -shared -Wl,--export-all-symbols -Wl,--enable-auto-import
-Wl,--enable-runtime-pseudo-reloc -o __magick_read__.oct __magick_read__.o -L../libcruft -lcruft
-L../liboctave -loctave -L. -loctinterp -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse
-Lc:/Programs/OctaveBuild/lib -lblas.dll -llapack.dll -lfftw3 -lfftw3f -lqrupdate -
larpack -lreadline  -ltermcap -liberty -lhdf5 -lz -lm -lgfortran.dll -lgdi32 -lws2_32 -luser32
-lkernel32 -Lc:/Programs/OctaveBuild/lib -L:/Programs/WinDevTools/lib -Lc:/Programs/GnuWin32/lib
-Lc:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0 -Lc:/programs/mingw/bin/../lib/gcc
-Lc:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/lib
-Lc:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0/../../.. -lhdf5 -lz -lm -lgfortran.dll
-lgfortranbegin -lgfortran -lmingw32 -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32
-lshell32 -lGraphicsMagick++ -lGraphicsMagick -ltiff -lfreetype -ljpeg -lpng -lwmflite -lz -lgdi32
-lmc:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe: cannot find
-lfreetype
collect2: ld returned 1 exit status


--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> Sorry!
> The error comes from two origin.
> The patch
> http://hg.savannah.gnu.org/hgweb/octave/rev/69d05d1a63b9
> --- a/configure.in	Fri Jun 26 21:12:09 2009 +0100
> +++ b/configure.in	Thu Jul 09 15:04:34 2009 -0400
> @@ -1654,8 +1654,8 @@
>  esac
>  
>  case "$canonical_host_type" in
> -  *-*-msdosmsvc)
> -    ## The %T format specifier for strftime is reportedly broken,
> +  *-*-msdosmsvc | *-*-mingw*)
> +    ## The %T and %e format specifiers for strftime are not implemented
>      ## so use our version.  We could use an actual configure test
>      ## for this.
>    ;;
> The reversing this patch is necesarry for my case.
> 
> causes error at the link.
> So I rewrote  the configure.in.  Therefore autoconf was executed.
> 
> 
> In addition, autoconf for my msys seemed to be broken.
> I have update the latest Msys-1.0.11 (Sat Jul 18 2009 ).
> 
> The updating msys seemed to work fine. The make process is now proceeding.
> 
> Thanks!!
> 
> Tatsuro 
> 
> 
> --- Tatsuro MATSUOKA wrote:
> 
> > Hello
> > 
> > Perhaps the problem relies on msys autoconf ???.
> > 
> > I have copied the autom4te-2.61 to /usr/local/bin from /usr/bin
> > 
> > 
> > make[1]: Entering directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> > (cd ../../octave-3.2.3-RC1; autoconf --force)
> > Can't locate Autom4te/C4che.pm in @INC (@INC contains: /usr/local/share/autoconf
> > /usr/lib/perl5/5.6/msys /usr/lib/perl5/
> > 5.6 /usr/lib/perl5/site_perl/5.6/msys /usr/lib/perl5/site_perl/5.6
> > /usr/lib/perl5/site_perl/5.6/msys
> > /usr/lib/perl5/site
> > _perl/5.6 /usr/lib/perl5/vendor_perl/5.6/msys /usr/lib/perl5/vendor_perl/5.6
> > /usr/lib/perl5/vendor_perl/5.6/msys /usr/li
> > b/perl5/vendor_perl/5.6 .) at /usr/local/bin/autom4te-2.61 line 39.
> > BEGIN failed--compilation aborted at /usr/local/bin/autom4te-2.61 line 39.
> > make[1]: *** [configure] Error 2
> > make[1]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> > make: *** [all] Error 2
> > 
> > Hello Benjamin
> > 
> > Can you confirm this?
> > Or no problem for yours ?
> > 
> > Regards
> > 
> > Tatsuro
> > 
> > --- Tatsuro MATSUOKA wrote:
> > 
> > > Hello
> > > 
> > > make -f octMakefile all
> > > make[1]: Entering directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> > > (cd ../../octave-3.2.3-RC1; autoconf --force)
> > > /bin/autoconf-2.61: line 582: /usr/local/bin/autom4te-2.61: No such file or directory
> > > /bin/autoconf-2.61: line 582: exec: /usr/local/bin/autom4te-2.61: cannot execute: No such
> file
> > > or
> > > directory
> > > make[1]: *** [configure] Error 126
> > > make[1]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> > > make: *** [all] Error 2
> > > 
> > > /bin/autoconf-2.61 ??
> > > 
> > > Had not the issue of autoconf-2.6  been discussed and resolved ?
> > > 
> > > Regards
> > > 
> > > Tatsuro 
> > > 
> > > --- Jaroslav Hajek <highegg at gmail.com> wrote:
> > > 
> > > > hi all,
> > > > 
> > > > I want to make 3.2.3 in the first half of September. The 1st release
> > > > candidate tarballs for 3.2.3 are available at:
> > > > http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> > > > 
> > > > changes since 3.2.2:
> > > > 
> > > > changeset:   9380:193174bc5107
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Wed Jul 08 13:49:21 2009 -0400
> > > > summary:     dim-vector.h: dim vectors always have two dimensions
> > > > 
> > > > changeset:   9381:4290384284b7
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Wed Jul 08 14:06:53 2009 -0400
> > > > summary:     pt-assign.cc (maybe_warn_former_built_in_variable): improve message
> > > > 
> > > > changeset:   9382:cd95695a0a89
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Thu Jul 09 15:04:34 2009 -0400
> > > > summary:     configure.in: don't use system strftime on MinGW systems
> > > > 
> > > > changeset:   9383:941b8414b99e
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Sat Jul 11 12:46:10 2009 -0400
> > > > summary:     file-ops.cc (file_ops::symlink, file_ops::readlink):
> > > > avoid incorrectly sized buffer
> > > > 
> > > > changeset:   9384:44300eb51817
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Thu Jul 16 11:56:44 2009 -0400
> > > > summary:     graphics.cc (get_array_limits): require min_pos value to
> > > > be greater than zero
> > > > 
> > > > changeset:   9385:9aea00e4e000
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Sat Jul 25 16:16:59 2009 +0200
> > > > summary:     Makeconf.in (MAGICK_LIBS): Don't pass --ldflags to $(MAGICK_CONFIG)
> > > > 
> > > > changeset:   9386:6ddb81224550
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Sat Jul 25 16:17:27 2009 +0200
> > > > summary:     __go_draw_axes__.m: also use layer property for plot border
> > > > 
> > > > changeset:   9387:b308b2e12f04
> > > > user:        Benjamin Lindner <lindnerb at users.sourceforge.net>
> > > > date:        Sat Jul 25 16:20:05 2009 +0200
> > > > summary:     determine correct image bitwidth in __magick_read__.cc
> > > > 
> > > > changeset:   9388:a8a44f20ef3b
> > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > date:        Sat Jul 25 16:20:35 2009 +0200
> > > > summary:     fix signed integer shift
> > > > 
> > > > changeset:   9389:3602403af9b8
> > > > user:        Aleksej Saushev <asau at inbox.ru>
> > > > date:        Sat Jul 25 16:21:51 2009 +0200
> > > > summary:     initialize floating point values properly for NetBSD systems
> > > > 
> > > > changeset:   9390:83d604a4e803
> > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > date:        Sat Jul 25 16:22:40 2009 +0200
> > > > summary:     fix Cholesky updating with scalars
> > > > 
> > > > changeset:   9391:c4f89df90e43
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Sat Jul 25 16:26:01 2009 +0200
> > > > summary:     avoid complex -> real conversion when constructing arrays with []
> > > > 
> > > > changeset:   9392:6a6779e895d4
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Tue Aug 04 09:52:53 2009 +0200
> > > > summary:     correctly parse things like '@(){1 2}'
> > > > 
> > > > changeset:   9393:18b8a3aa034c
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Tue Aug 04 09:55:38 2009 +0200
> > > > summary:     use complex function for acos mapper if arg is out of range [-1, 1]
> > > > 
> > > > changeset:   9394:f1dd244757cd
> > > > user:        Ben Abbott <bpabbott at mac.com>
> > > > date:        Thu Aug 06 07:18:53 2009 +0200
> > > > summary:     __go_draw_axes__.m: Fix ticklabels specified as 2D character array.
> > > > 
> > > > changeset:   9395:54a3fa5d4376
> > > > user:        Ben Abbott <bpabbott at mac.com>
> > > > date:        Thu Aug 06 07:30:34 2009 +0200
> > > > summary:     Avoid the flickering x11 window seen with rapid gnuplot updates.
> > > > 
> > > > changeset:   9396:9107c882f193
> > > > user:        Olli Saarela <olli.saarela at gmail.com>
> > > > date:        Thu Aug 06 07:31:45 2009 +0200
> > > > summary:     __gnuplot_get_var__: if read fails to return data, sleep
> > > > before trying again
> > > > 
> > > > changeset:   9397:16181105aeb6
> > > > user:        Pieter Eendebak <pieter.eendebak at gmail.com>
> > > > date:        Thu Aug 06 07:32:53 2009 +0200
> > > > summary:     support cellstrs in setxor
> > > > 
> > > > changeset:   9398:21038fd51788
> > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > date:        Fri Aug 07 08:11:49 2009 +0200
> > > > summary:     implant tree_index_expression::lvalue from development version
> > > > 
> > > > changeset:   9399:0014ff1747a6
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Fri Aug 07 08:13:22 2009 +0200
> > > > summary:     use key list order for iterating through map with for loop
> > > > 
> > > > changeset:   9400:3db13615d39a
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Fri Aug 07 08:15:27 2009 +0200
> > > > summary:     handle null matrix assignment for diagonal and permutation matrices
> > > > 
> > > > changeset:   9401:3a4da80f4adc
> > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > date:        Fri Aug 07 08:22:13 2009 +0200
> > > > summary:     complete change d5570d4b1116
> > > > 
> > > > changeset:   9402:1d5a487a01cf
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Mon Aug 10 11:14:46 2009 +0200
> > > > summary:     parse.y (Fevalin): also return output from CATCH expression
> > > > 
> > > > changeset:   9403:a29f3eba78a2
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Thu Aug 13 07:56:00 2009 +0200
> > > > summary:     new option, --no-window-system
> > > > 
> > > > changeset:   9404:1347fcb231bd
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Sun Aug 23 11:09:17 2009 +0200
> > > > summary:     dlmread: perform tilde expansion to filename argument
> > > > 
> > > > changeset:   9405:3a65f1038bdb
> > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > date:        Sun Aug 23 11:10:05 2009 +0200
> > > > summary:     fix some functions help markup
> > > > 
> > > > changeset:   9406:4963bb455582
> > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > date:        Sun Aug 23 11:10:35 2009 +0200
> > > > summary:     fix typos in complex xgemm
> > > > 
> > > > changeset:   9407:1371eecefd99
> > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > date:        Sun Aug 23 11:11:27 2009 +0200
> > > > summary:     make single prec. matrix mutliply tests really single
> > > > 
> > > > changeset:   9408:9e66af7e1593
> > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > date:        Sun Aug 23 11:11:27 2009 +0200
> > > > summary:     more fixes & tests for matrix multiply
> > > > 
> > > > changeset:   9409:f0d18d74a519
> > > > user:        John W. Eaton <jwe at octave.org>
> > > > date:        Sun Aug 23 11:12:16 2009 +0200
> > > > summary:     acx_blas_f77_func.m4 (ACX_BLAS_F77_FUNC): Save and restore LIBS
> > > > 
> > > > changeset:   9410:c3d37d2a2b55
> > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > date:        Sun Aug 23 11:12:35 2009 +0200
> > > > summary:     zero matrix assignment fix
> > > > 
> > > > changeset:   9411:d208ae6e9d74
> > > > user:        David Bateman <dbateman at free.fr>
> > > > date:        Mon Aug 24 10:02:47 2009 +0200
> > > > summary:     Fix test for setting of datasource properties. Add the
> > > > edgecolor property to contours
> > > > 
> > > > changeset:   9412:8e69b1d41c03
> > > > tag:         qparent
> > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > date:        Mon Aug 24 10:06:52 2009 +0200
> > > > summary:     fix typo in acx_blas_f77_func.m4
> > > > 
> > > > In case your favorite patch is missing, now would be a good time to mention it.
> > > > 
> > > > regards
> > > > 
> > > > -- 
> > > > RNDr. Jaroslav Hajek
> > > > computing expert & GNU Octave developer
> > > > Aeronautical Research and Test Institute (VZLU)
> > > > Prague, Czech Republic
> > > > url: www.highegg.matfyz.cz
> > > > 
> > > 
> > > 
> > > --------------------------------------
> > > 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/
> 


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

From tmacchant at yahoo.co.jp  Tue Aug 25 02:50:10 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Tue, 25 Aug 2009 16:50:10 +0900 (JST)
Subject: 3.2.3 RC1
In-Reply-To: <20090825074909.44617.qmail@web3802.mail.bbt.yahoo.co.jp>
Message-ID: <20090825075010.8780.qmail@web3814.mail.bbt.yahoo.co.jp>

Hello

Sorry this mail should be ignored.

Tatsuro

--- Tatsuro MATSUOKA wrote:

> Hello
> 
> The 'make' stopped at
> 
> g++ -shared-libgcc -shared -Wl,--export-all-symbols -Wl,--enable-auto-import
> -Wl,--enable-runtime-pseudo-reloc -o __magick_read__.oct __magick_read__.o -L../libcruft -lcruft
> -L../liboctave -loctave -L. -loctinterp -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd
> -lcxsparse
> -Lc:/Programs/OctaveBuild/lib -lblas.dll -llapack.dll -lfftw3 -lfftw3f -lqrupdate -
> larpack -lreadline  -ltermcap -liberty -lhdf5 -lz -lm -lgfortran.dll -lgdi32 -lws2_32 -luser32
> -lkernel32 -Lc:/Programs/OctaveBuild/lib -L:/Programs/WinDevTools/lib -Lc:/Programs/GnuWin32/lib
> -Lc:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0 -Lc:/programs/mingw/bin/../lib/gcc
> -Lc:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/lib
> -Lc:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0/../../.. -lhdf5 -lz -lm -lgfortran.dll
> -lgfortranbegin -lgfortran -lmingw32 -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32
> -ladvapi32
> -lshell32 -lGraphicsMagick++ -lGraphicsMagick -ltiff -lfreetype -ljpeg -lpng -lwmflite -lz
> -lgdi32
> -lmc:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe: cannot find
> -lfreetype
> collect2: ld returned 1 exit status
> 
> 
> --- Tatsuro MATSUOKA  wrote:
> 
> > Hello
> > 
> > Sorry!
> > The error comes from two origin.
> > The patch
> > http://hg.savannah.gnu.org/hgweb/octave/rev/69d05d1a63b9
> > --- a/configure.in	Fri Jun 26 21:12:09 2009 +0100
> > +++ b/configure.in	Thu Jul 09 15:04:34 2009 -0400
> > @@ -1654,8 +1654,8 @@
> >  esac
> >  
> >  case "$canonical_host_type" in
> > -  *-*-msdosmsvc)
> > -    ## The %T format specifier for strftime is reportedly broken,
> > +  *-*-msdosmsvc | *-*-mingw*)
> > +    ## The %T and %e format specifiers for strftime are not implemented
> >      ## so use our version.  We could use an actual configure test
> >      ## for this.
> >    ;;
> > The reversing this patch is necesarry for my case.
> > 
> > causes error at the link.
> > So I rewrote  the configure.in.  Therefore autoconf was executed.
> > 
> > 
> > In addition, autoconf for my msys seemed to be broken.
> > I have update the latest Msys-1.0.11 (Sat Jul 18 2009 ).
> > 
> > The updating msys seemed to work fine. The make process is now proceeding.
> > 
> > Thanks!!
> > 
> > Tatsuro 
> > 
> > 
> > --- Tatsuro MATSUOKA wrote:
> > 
> > > Hello
> > > 
> > > Perhaps the problem relies on msys autoconf ???.
> > > 
> > > I have copied the autom4te-2.61 to /usr/local/bin from /usr/bin
> > > 
> > > 
> > > make[1]: Entering directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> > > (cd ../../octave-3.2.3-RC1; autoconf --force)
> > > Can't locate Autom4te/C4che.pm in @INC (@INC contains: /usr/local/share/autoconf
> > > /usr/lib/perl5/5.6/msys /usr/lib/perl5/
> > > 5.6 /usr/lib/perl5/site_perl/5.6/msys /usr/lib/perl5/site_perl/5.6
> > > /usr/lib/perl5/site_perl/5.6/msys
> > > /usr/lib/perl5/site
> > > _perl/5.6 /usr/lib/perl5/vendor_perl/5.6/msys /usr/lib/perl5/vendor_perl/5.6
> > > /usr/lib/perl5/vendor_perl/5.6/msys /usr/li
> > > b/perl5/vendor_perl/5.6 .) at /usr/local/bin/autom4te-2.61 line 39.
> > > BEGIN failed--compilation aborted at /usr/local/bin/autom4te-2.61 line 39.
> > > make[1]: *** [configure] Error 2
> > > make[1]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> > > make: *** [all] Error 2
> > > 
> > > Hello Benjamin
> > > 
> > > Can you confirm this?
> > > Or no problem for yours ?
> > > 
> > > Regards
> > > 
> > > Tatsuro
> > > 
> > > --- Tatsuro MATSUOKA wrote:
> > > 
> > > > Hello
> > > > 
> > > > make -f octMakefile all
> > > > make[1]: Entering directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> > > > (cd ../../octave-3.2.3-RC1; autoconf --force)
> > > > /bin/autoconf-2.61: line 582: /usr/local/bin/autom4te-2.61: No such file or directory
> > > > /bin/autoconf-2.61: line 582: exec: /usr/local/bin/autom4te-2.61: cannot execute: No such
> > file
> > > > or
> > > > directory
> > > > make[1]: *** [configure] Error 126
> > > > make[1]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-RC1'
> > > > make: *** [all] Error 2
> > > > 
> > > > /bin/autoconf-2.61 ??
> > > > 
> > > > Had not the issue of autoconf-2.6  been discussed and resolved ?
> > > > 
> > > > Regards
> > > > 
> > > > Tatsuro 
> > > > 
> > > > --- Jaroslav Hajek <highegg at gmail.com> wrote:
> > > > 
> > > > > hi all,
> > > > > 
> > > > > I want to make 3.2.3 in the first half of September. The 1st release
> > > > > candidate tarballs for 3.2.3 are available at:
> > > > > http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> > > > > 
> > > > > changes since 3.2.2:
> > > > > 
> > > > > changeset:   9380:193174bc5107
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Wed Jul 08 13:49:21 2009 -0400
> > > > > summary:     dim-vector.h: dim vectors always have two dimensions
> > > > > 
> > > > > changeset:   9381:4290384284b7
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Wed Jul 08 14:06:53 2009 -0400
> > > > > summary:     pt-assign.cc (maybe_warn_former_built_in_variable): improve message
> > > > > 
> > > > > changeset:   9382:cd95695a0a89
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Thu Jul 09 15:04:34 2009 -0400
> > > > > summary:     configure.in: don't use system strftime on MinGW systems
> > > > > 
> > > > > changeset:   9383:941b8414b99e
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Sat Jul 11 12:46:10 2009 -0400
> > > > > summary:     file-ops.cc (file_ops::symlink, file_ops::readlink):
> > > > > avoid incorrectly sized buffer
> > > > > 
> > > > > changeset:   9384:44300eb51817
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Thu Jul 16 11:56:44 2009 -0400
> > > > > summary:     graphics.cc (get_array_limits): require min_pos value to
> > > > > be greater than zero
> > > > > 
> > > > > changeset:   9385:9aea00e4e000
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Sat Jul 25 16:16:59 2009 +0200
> > > > > summary:     Makeconf.in (MAGICK_LIBS): Don't pass --ldflags to $(MAGICK_CONFIG)
> > > > > 
> > > > > changeset:   9386:6ddb81224550
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Sat Jul 25 16:17:27 2009 +0200
> > > > > summary:     __go_draw_axes__.m: also use layer property for plot border
> > > > > 
> > > > > changeset:   9387:b308b2e12f04
> > > > > user:        Benjamin Lindner <lindnerb at users.sourceforge.net>
> > > > > date:        Sat Jul 25 16:20:05 2009 +0200
> > > > > summary:     determine correct image bitwidth in __magick_read__.cc
> > > > > 
> > > > > changeset:   9388:a8a44f20ef3b
> > > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > > date:        Sat Jul 25 16:20:35 2009 +0200
> > > > > summary:     fix signed integer shift
> > > > > 
> > > > > changeset:   9389:3602403af9b8
> > > > > user:        Aleksej Saushev <asau at inbox.ru>
> > > > > date:        Sat Jul 25 16:21:51 2009 +0200
> > > > > summary:     initialize floating point values properly for NetBSD systems
> > > > > 
> > > > > changeset:   9390:83d604a4e803
> > > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > > date:        Sat Jul 25 16:22:40 2009 +0200
> > > > > summary:     fix Cholesky updating with scalars
> > > > > 
> > > > > changeset:   9391:c4f89df90e43
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Sat Jul 25 16:26:01 2009 +0200
> > > > > summary:     avoid complex -> real conversion when constructing arrays with []
> > > > > 
> > > > > changeset:   9392:6a6779e895d4
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Tue Aug 04 09:52:53 2009 +0200
> > > > > summary:     correctly parse things like '@(){1 2}'
> > > > > 
> > > > > changeset:   9393:18b8a3aa034c
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Tue Aug 04 09:55:38 2009 +0200
> > > > > summary:     use complex function for acos mapper if arg is out of range [-1, 1]
> > > > > 
> > > > > changeset:   9394:f1dd244757cd
> > > > > user:        Ben Abbott <bpabbott at mac.com>
> > > > > date:        Thu Aug 06 07:18:53 2009 +0200
> > > > > summary:     __go_draw_axes__.m: Fix ticklabels specified as 2D character array.
> > > > > 
> > > > > changeset:   9395:54a3fa5d4376
> > > > > user:        Ben Abbott <bpabbott at mac.com>
> > > > > date:        Thu Aug 06 07:30:34 2009 +0200
> > > > > summary:     Avoid the flickering x11 window seen with rapid gnuplot updates.
> > > > > 
> > > > > changeset:   9396:9107c882f193
> > > > > user:        Olli Saarela <olli.saarela at gmail.com>
> > > > > date:        Thu Aug 06 07:31:45 2009 +0200
> > > > > summary:     __gnuplot_get_var__: if read fails to return data, sleep
> > > > > before trying again
> > > > > 
> > > > > changeset:   9397:16181105aeb6
> > > > > user:        Pieter Eendebak <pieter.eendebak at gmail.com>
> > > > > date:        Thu Aug 06 07:32:53 2009 +0200
> > > > > summary:     support cellstrs in setxor
> > > > > 
> > > > > changeset:   9398:21038fd51788
> > > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > > date:        Fri Aug 07 08:11:49 2009 +0200
> > > > > summary:     implant tree_index_expression::lvalue from development version
> > > > > 
> > > > > changeset:   9399:0014ff1747a6
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Fri Aug 07 08:13:22 2009 +0200
> > > > > summary:     use key list order for iterating through map with for loop
> > > > > 
> > > > > changeset:   9400:3db13615d39a
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Fri Aug 07 08:15:27 2009 +0200
> > > > > summary:     handle null matrix assignment for diagonal and permutation matrices
> > > > > 
> > > > > changeset:   9401:3a4da80f4adc
> > > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > > date:        Fri Aug 07 08:22:13 2009 +0200
> > > > > summary:     complete change d5570d4b1116
> > > > > 
> > > > > changeset:   9402:1d5a487a01cf
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Mon Aug 10 11:14:46 2009 +0200
> > > > > summary:     parse.y (Fevalin): also return output from CATCH expression
> > > > > 
> > > > > changeset:   9403:a29f3eba78a2
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Thu Aug 13 07:56:00 2009 +0200
> > > > > summary:     new option, --no-window-system
> > > > > 
> > > > > changeset:   9404:1347fcb231bd
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Sun Aug 23 11:09:17 2009 +0200
> > > > > summary:     dlmread: perform tilde expansion to filename argument
> > > > > 
> > > > > changeset:   9405:3a65f1038bdb
> > > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > > date:        Sun Aug 23 11:10:05 2009 +0200
> > > > > summary:     fix some functions help markup
> > > > > 
> > > > > changeset:   9406:4963bb455582
> > > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > > date:        Sun Aug 23 11:10:35 2009 +0200
> > > > > summary:     fix typos in complex xgemm
> > > > > 
> > > > > changeset:   9407:1371eecefd99
> > > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > > date:        Sun Aug 23 11:11:27 2009 +0200
> > > > > summary:     make single prec. matrix mutliply tests really single
> > > > > 
> > > > > changeset:   9408:9e66af7e1593
> > > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > > date:        Sun Aug 23 11:11:27 2009 +0200
> > > > > summary:     more fixes & tests for matrix multiply
> > > > > 
> > > > > changeset:   9409:f0d18d74a519
> > > > > user:        John W. Eaton <jwe at octave.org>
> > > > > date:        Sun Aug 23 11:12:16 2009 +0200
> > > > > summary:     acx_blas_f77_func.m4 (ACX_BLAS_F77_FUNC): Save and restore LIBS
> > > > > 
> > > > > changeset:   9410:c3d37d2a2b55
> > > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > > date:        Sun Aug 23 11:12:35 2009 +0200
> > > > > summary:     zero matrix assignment fix
> > > > > 
> > > > > changeset:   9411:d208ae6e9d74
> > > > > user:        David Bateman <dbateman at free.fr>
> > > > > date:        Mon Aug 24 10:02:47 2009 +0200
> > > > > summary:     Fix test for setting of datasource properties. Add the
> > > > > edgecolor property to contours
> > > > > 
> > > > > changeset:   9412:8e69b1d41c03
> > > > > tag:         qparent
> > > > > user:        Jaroslav Hajek <highegg at gmail.com>
> > > > > date:        Mon Aug 24 10:06:52 2009 +0200
> > > > > summary:     fix typo in acx_blas_f77_func.m4
> > > > > 
> > > > > In case your favorite patch is missing, now would be a good time to mention it.
> > > > > 
> > > > > regards
> > > > > 
> > > > > -- 
> > > > > RNDr. Jaroslav Hajek
> > > > > computing expert & GNU Octave developer
> > > > > Aeronautical Research and Test Institute (VZLU)
> > > > > Prague, Czech Republic
> > > > > url: www.highegg.matfyz.cz
> > > > > 
> > > > 
> > > > 
> > > > --------------------------------------
> > > > 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/
> > 
> 
> 
> --------------------------------------
> 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/

From highegg at gmail.com  Tue Aug 25 03:19:44 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 25 Aug 2009 10:19:44 +0200
Subject: 3.2.3 RC1
In-Reply-To: <4A936DB9.8060801@gmx.net>
References: <69d8d540908240158v634b5d0aj71554f0505a78395@mail.gmail.com>
	<4A92EEC4.9080609@gmx.net> <4A936DB9.8060801@gmx.net>
Message-ID: <69d8d540908250119p59939a0dhd274864e61cd590e@mail.gmail.com>

On Tue, Aug 25, 2009 at 6:51 AM, Benjamin Lindner<lindnerben at gmx.net> wrote:
> Benjamin Lindner wrote:
>>
>> Jaroslav Hajek wrote:
>>>
>>> hi all,
>>>
>>> I want to make 3.2.3 in the first half of September. The 1st release
>>> candidate tarballs for 3.2.3 are available at:
>>> http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
>>
>> Building on mingw32 tdm-gcc-4.3.0-3 completes fine.
>> Make check also OK with the already known failures.
>>
>> Summary:
>>
>> ?PASS ? 5744
>> ?FAIL ? ? 10
>>
>> benjamin
>>
>
> I forgot to mention that I require the fix at the end of the thread
> http://www.nabble.com/%22dir%22-crashing-oactve-3.2.0-mingw32-td24234760.html
> to successfully link.
>
> benjamin
>

OK, I applied that one to both main and 3.2.x.

thanks

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


From highegg at gmail.com  Tue Aug 25 03:29:38 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 25 Aug 2009 10:29:38 +0200
Subject: 3.2.3 RC1
In-Reply-To: <20090825061251.205040@gmx.net>
References: <20090825061251.205040@gmx.net>
Message-ID: <69d8d540908250129k1273eccaq3629b475379bc348@mail.gmail.com>

On Tue, Aug 25, 2009 at 8:12 AM, Benjamin Lindner<lindnerben at gmx.net> wrote:
> Hello,
>
> The imread/imfinfo issue as reported in
> http://www.nabble.com/imgwrite-imfinfo-fail-in-octave-3.2.x-td25004136.html
> should also be fixed before releasing a new 3.2.x version.
>

Done.

> Unfortunately there is no test of the imread/imwrite/imfinfo scripts in the 3.2.x branch, thus it does not show in "make check", so I missed it at first...

Maybe there's a patch that can be transplanted?

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

From tmacchant at yahoo.co.jp  Tue Aug 25 05:04:06 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Tue, 25 Aug 2009 19:04:06 +0900 (JST)
Subject: 3.2.3 RC1
In-Reply-To: <4A936DE4.5050803@gmx.net>
Message-ID: <20090825100406.89743.qmail@web3813.mail.bbt.yahoo.co.jp>

Hello

> But then calls to strftime might segfault, as numerous bugs have been 
> reported on this.
> 
> See the thread at 
> http://www.nabble.com/%22dir%22-crashing-oactve-3.2.0-mingw32-td24234760.html
> for a fix for the link error.

I know it

Without the patch below, my octave does not crash at all and clear all works correct.
See below
  
*********************************************************************
$ ./run-octave
GNU Octave, version 3.2.3
Copyright (C) 2009 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type `warranty'.

Octave was configured for "i686-pc-mingw32".

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/help-wanted.html

Report bugs to <bug at octave.org> (but first, please read
http://www.octave.org/bugs.html to learn how to write a helpful report).

For information about changes from previous versions, type `news'.

octave.exe:1> clear all
octave.exe:2> A=rand(5)
A =

   0.798582   0.421041   0.055617   0.347532   0.638430
   0.990263   0.117516   0.065540   0.281049   0.366005
   0.955282   0.662246   0.632050   0.749596   0.108140
   0.256726   0.580323   0.349829   0.804008   0.236990
   0.228088   0.705807   0.279213   0.447449   0.014671

octave.exe:3> eigs(A,2)
ans =

   2.15348
   0.43633

octave.exe:4> clear all
octave.exe:5> A
error: `A' undefined near line 5 column 1
octave.exe:5>
******************************************************************

> I also ran into some issues with the newly relased packages. I tried to 
> cirumvent it by *not* using the "mingw32" versions, rather than the 
> "msys" versions.
> This is not what's suggested, but it worked for me, at least up to now.

Now the latest Msys works well, after ./autogen.sh executed with the 'configure.in' is modified.

Thanks

Tatsuro

--- Benjamin Lindner <lindnerben at gmx.net> wrote:

> Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > Sorry!
> > The error comes from two origin.
> > The patch
> > http://hg.savannah.gnu.org/hgweb/octave/rev/69d05d1a63b9
> > --- a/configure.in	Fri Jun 26 21:12:09 2009 +0100
> > +++ b/configure.in	Thu Jul 09 15:04:34 2009 -0400
> > @@ -1654,8 +1654,8 @@
> >  esac
> >  
> >  case "$canonical_host_type" in
> > -  *-*-msdosmsvc)
> > -    ## The %T format specifier for strftime is reportedly broken,
> > +  *-*-msdosmsvc | *-*-mingw*)
> > +    ## The %T and %e format specifiers for strftime are not implemented
> >      ## so use our version.  We could use an actual configure test
> >      ## for this.
> >    ;;
> > The reversing this patch is necesarry for my case.
> 
> 
> 
> > causes error at the link.
> > So I rewrote  the configure.in.  Therefore autoconf was executed.
> > 
> > In addition, autoconf for my msys seemed to be broken.
> > I have update the latest Msys-1.0.11 (Sat Jul 18 2009 ).
> 
> 
> benjamin
> 
> 
> 


--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

From tmacchant at yahoo.co.jp  Tue Aug 25 05:19:35 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Tue, 25 Aug 2009 19:19:35 +0900 (JST)
Subject: 3.2.3 RC1
In-Reply-To: <20090825074909.44617.qmail@web3802.mail.bbt.yahoo.co.jp>
Message-ID: <20090825101935.85529.qmail@web3812.mail.bbt.yahoo.co.jp>

Hello

The changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/69d05d1a63b9

 gives link error for liboctave. 

See 
http://www.nabble.com/make-fails-at-linkiking-liboctave-(MinGW-4.4.0)-td25002706.html

SO I disabled it and ./autogen.sh, I can build octave-3.2.3,
'make check' result is 

 d:\usr\Tatsu\mingwhome\octaves\octave-3.2.3-RC1\src\data.cc  PASS  506/509  FAIL 3
  test_string.m .......................................... PASS   78/79   FAIL 1
Summary:

  PASS   5750
  FAIL      4

Regards

Tatsuro

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

From tmacchant at yahoo.co.jp  Tue Aug 25 05:28:55 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Tue, 25 Aug 2009 19:28:55 +0900 (JST)
Subject: 3.2.3 RC1
In-Reply-To: <20090825101935.85529.qmail@web3812.mail.bbt.yahoo.co.jp>
Message-ID: <20090825102855.97230.qmail@web3813.mail.bbt.yahoo.co.jp>

Hello

I think that this patch in principle should be attached Because The %T and %e format specifiers for
strftime are not implemented also for GCC-4.4.0 MinGW official.

However it gives the link error, I temporally disables the changeset.

I have to look at what is done by the patch and what is the origin ununderstandabel link error with
it.

Hopefully this issue is not beyond my ability.

Regards

Tatsuro 
 

--- Tatsuro MATSUOKA wrote:

> Hello
> 
> The changeset
> http://hg.savannah.gnu.org/hgweb/octave/rev/69d05d1a63b9
> 
>  gives link error for liboctave. 
> 
> See 
> http://www.nabble.com/make-fails-at-linkiking-liboctave-(MinGW-4.4.0)-td25002706.html
> 
> SO I disabled it and ./autogen.sh, I can build octave-3.2.3,
> 'make check' result is 
> 
>  d:\usr\Tatsu\mingwhome\octaves\octave-3.2.3-RC1\src\data.cc  PASS  506/509  FAIL 3
>   test_string.m .......................................... PASS   78/79   FAIL 1
> Summary:
> 
>   PASS   5750
>   FAIL      4
> 
> Regards
> 
> Tatsuro
> 
> --------------------------------------
> Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
> http://pr.mail.yahoo.co.jp/ec10years/
> 


--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

From individ at acc.umu.se  Tue Aug 25 07:07:24 2009
From: individ at acc.umu.se (David Grundberg)
Date: Tue, 25 Aug 2009 14:07:24 +0200
Subject: [changeset] GraphicsMagick++ configuration
In-Reply-To: <4A93D1D0.9040500@acc.umu.se>
References: <4A7AEEF4.2070101@acc.umu.se>	<19066.62968.137520.390478@segfault.lan>	<4A7B3868.9020001@acc.umu.se>	<19067.14844.220747.257229@segfault.lan>	<20090816210909.GA15975@atlan>
	<20090825055536.GA7737@atlan> <4A93D1D0.9040500@acc.umu.se>
Message-ID: <4A93D3FC.4080203@acc.umu.se>

David Grundberg wrote:
> Thomas Weber wrote:
>> On Sun, Aug 16, 2009 at 11:09:09PM +0200, Thomas Weber wrote:
>>  
>>> On Thu, Aug 06, 2009 at 04:15:56PM -0400, John W. Eaton wrote:
>>>    
>>>> On  6-Aug-2009, David Grundberg wrote:
>>>>
>>>> | John W. Eaton skrev:
>>>> | > On  6-Aug-2009, David Grundberg wrote:
>>>> | >
>>>> | > | I've rearranged the GraphicsMagick++ configuration. I had 
>>>> some trouble | > | since I'm running a custom GraphicsMagick 
>>>> installation. The Octave build | > | system was running 
>>>> GraphicsMagick++-config during make. It was missing | > | ldflags 
>>>> and using only the basename of the config executable (as opposed | 
>>>> > | to a full path).
>>>> | > | | > | I've changed it so that GraphicsMagick++-config is only 
>>>> run in the | > | configure script. Also introduced MAGICK_CONFIG as 
>>>> a precious variable.
>>>> | >
>>>> | > I removed --ldflags to fix the following mysterious problem on my
>>>> | > system:
>>>> | >
>>>> | >   
>>>> https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-July/012879.html 
>>>>
>>>> | >
>>>> | > So I don't think I can put it back without breaking 
>>>> __magick_read__
>>>> | > again, at least for me and other Debian users.
>>>> | >
>>>> | > What are -Wl,-z,relro and -pie doing in the ldflags anyway?  
>>>> Are those
>>>> | > arguments not present on your system?  Maybe they are present 
>>>> on mine
>>>> | > because of the way Debian builds the graphics magick library 
>>>> package?
>>>> | > Perhaps these flags make sense for creating the graphics magick
>>>> | > library itself, but I can't see any reason for them to be 
>>>> required to
>>>> | > link the graphics magick library with __magick_read__.oct.
>>>> | >
>>>> | > jwe
>>>> | >   | So that's why --ldflags was taken away! I don't have that 
>>>> problem. This | is the output from my config (where I'm building):
>>>> | | $ | 
>>>> octave-patching/dependencies/graphicsmagick-install/bin/GraphicsMagick++-config 
>>>> | --ldflags --libs
>>>> | 
>>>> -L/Home/staff/davidg/octave-patching/dependencies/graphicsmagick-install/lib 
>>>> | -L/usr/lib -L/usr/lib
>>>> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype 
>>>> -ljasper | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 
>>>> -lxml2 -lz -lm | -lgomp -lpthread
>>>> | | My ubuntu 9.04 box says this about the managed package (haven't 
>>>> tried | building against it):
>>>> | david at lack:~$ GraphicsMagick++-config --ldflags --libs
>>>> | -L/usr/lib -Wl,-Bsymbolic-functions -L/usr/lib/X11 -L/usr/lib 
>>>> -L/usr/lib
>>>> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype 
>>>> -ljasper | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 
>>>> -lxml2 -lz -lm | -lpthread
>>>>
>>>> So what should we do about this?        
>>> These are different versions. The Ubuntu version is 1.1.11-something,
>>> your Debian versions is 1.3.5-something.
>>>
>>>    
>>>> around it by filtering out everything except -L options from the
>>>> --ldflags output, but I'd rather see it fixed in graphics magick.
>>>> What should graphics magick really be storing in the config script
>>>> for --ldflags?  Should options like -pie and -Wl,-z,relro really
>>>> appear there?  Or is this just a Debian packaging problem?
>>>>       
>>> The Debian packaging adds the -pie and -Wl options when building
>>> GraphicsMagick to the LDFLAGS. GraphicsMagick then copies LDFLAGS 
>>> into its
>>> --ldflags output. Looking at Ubuntu's build logs, the same is already
>>> happening with newer versions of graphicsmagick.
>>>
>>> I'll ask the Debian maintainer of GraphicsMagick about it.
>>>     
>>
>> Okay, his answer is below. Short version: we should go we with
>> pkg-config.
>>
>> ============================================================================ 
>>
>> Historically, the output of the *Magick*config scripts has been 
>> documented as
>> the list of compiler/linker options *Magick was built with. This 
>> makes sense
>> when build additional modules, but it's rather nonsensical for 
>> anything that
>> just wants to link the C or C++ bindings. I recommend to use 
>> pkg-config for
>> these kinds of applications instead. The hardening options aren't 
>> included
>> there.
>> ============================================================================ 
>>
>>
>>     Thomas
>>   
>
> Thanks a lot for your help!
>
> I made a new changeset, attached to this mail.
>
> At first I tried the pkg-config setup and was disappointed to see 
> (some ubuntu):
>
> $ pkg-config GraphicsMagick++ --libs
> -Wl,-Bsymbolic-functions -lGraphicsMagick++ -lGraphicsMagick $ 
> pkg-config GraphicsMagick++ --cflags
> -I/usr/include/GraphicsMagick
> But then I discovered the --libs-only-l/L arguments (didn't know about 
> these):
>
> $ pkg-config GraphicsMagick++ --libs-only-L
>
> $ pkg-config GraphicsMagick++ --libs-only-l
> -lGraphicsMagick++ -lGraphicsMagick
>
> Nice.
>
> David
(responding to self)

Ooops. An invalid email address sneaked into the ChangeLog. Fixed it. 
Sorry for the noise.

David
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: magick2.changeset
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090825/9f4b1927/attachment-0001.ksh 

From individ at acc.umu.se  Tue Aug 25 06:58:08 2009
From: individ at acc.umu.se (David Grundberg)
Date: Tue, 25 Aug 2009 13:58:08 +0200
Subject: [changeset] GraphicsMagick++ configuration
In-Reply-To: <20090825055536.GA7737@atlan>
References: <4A7AEEF4.2070101@acc.umu.se>	<19066.62968.137520.390478@segfault.lan>	<4A7B3868.9020001@acc.umu.se>	<19067.14844.220747.257229@segfault.lan>	<20090816210909.GA15975@atlan>
	<20090825055536.GA7737@atlan>
Message-ID: <4A93D1D0.9040500@acc.umu.se>

Thomas Weber wrote:
> On Sun, Aug 16, 2009 at 11:09:09PM +0200, Thomas Weber wrote:
>   
>> On Thu, Aug 06, 2009 at 04:15:56PM -0400, John W. Eaton wrote:
>>     
>>> On  6-Aug-2009, David Grundberg wrote:
>>>
>>> | John W. Eaton skrev:
>>> | > On  6-Aug-2009, David Grundberg wrote:
>>> | >
>>> | > | I've rearranged the GraphicsMagick++ configuration. I had some trouble 
>>> | > | since I'm running a custom GraphicsMagick installation. The Octave build 
>>> | > | system was running GraphicsMagick++-config during make. It was missing 
>>> | > | ldflags and using only the basename of the config executable (as opposed 
>>> | > | to a full path).
>>> | > | 
>>> | > | I've changed it so that GraphicsMagick++-config is only run in the 
>>> | > | configure script. Also introduced MAGICK_CONFIG as a precious variable.
>>> | >
>>> | > I removed --ldflags to fix the following mysterious problem on my
>>> | > system:
>>> | >
>>> | >   https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-July/012879.html
>>> | >
>>> | > So I don't think I can put it back without breaking __magick_read__
>>> | > again, at least for me and other Debian users.
>>> | >
>>> | > What are -Wl,-z,relro and -pie doing in the ldflags anyway?  Are those
>>> | > arguments not present on your system?  Maybe they are present on mine
>>> | > because of the way Debian builds the graphics magick library package?
>>> | > Perhaps these flags make sense for creating the graphics magick
>>> | > library itself, but I can't see any reason for them to be required to
>>> | > link the graphics magick library with __magick_read__.oct.
>>> | >
>>> | > jwe
>>> | >   
>>> | So that's why --ldflags was taken away! I don't have that problem. This 
>>> | is the output from my config (where I'm building):
>>> | 
>>> | $ 
>>> | octave-patching/dependencies/graphicsmagick-install/bin/GraphicsMagick++-config 
>>> | --ldflags --libs
>>> | -L/Home/staff/davidg/octave-patching/dependencies/graphicsmagick-install/lib 
>>> | -L/usr/lib -L/usr/lib
>>> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper 
>>> | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm 
>>> | -lgomp -lpthread
>>> | 
>>> | My ubuntu 9.04 box says this about the managed package (haven't tried 
>>> | building against it):
>>> | david at lack:~$ GraphicsMagick++-config --ldflags --libs
>>> | -L/usr/lib -Wl,-Bsymbolic-functions -L/usr/lib/X11 -L/usr/lib -L/usr/lib
>>> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper 
>>> | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm 
>>> | -lpthread
>>>
>>> So what should we do about this?  
>>>       
>> These are different versions. The Ubuntu version is 1.1.11-something,
>> your Debian versions is 1.3.5-something.
>>
>>     
>>> around it by filtering out everything except -L options from the
>>> --ldflags output, but I'd rather see it fixed in graphics magick.
>>> What should graphics magick really be storing in the config script
>>> for --ldflags?  Should options like -pie and -Wl,-z,relro really
>>> appear there?  Or is this just a Debian packaging problem?
>>>       
>> The Debian packaging adds the -pie and -Wl options when building
>> GraphicsMagick to the LDFLAGS. GraphicsMagick then copies LDFLAGS into its
>> --ldflags output. Looking at Ubuntu's build logs, the same is already
>> happening with newer versions of graphicsmagick.
>>
>> I'll ask the Debian maintainer of GraphicsMagick about it.
>>     
>
> Okay, his answer is below. Short version: we should go we with
> pkg-config.
>
> ============================================================================
> Historically, the output of the *Magick*config scripts has been documented as
> the list of compiler/linker options *Magick was built with. This makes sense
> when build additional modules, but it's rather nonsensical for anything that
> just wants to link the C or C++ bindings. I recommend to use pkg-config for
> these kinds of applications instead. The hardening options aren't included
> there.
> ============================================================================
>
> 	Thomas
>   

Thanks a lot for your help!

I made a new changeset, attached to this mail.

At first I tried the pkg-config setup and was disappointed to see (some 
ubuntu):

$ pkg-config GraphicsMagick++ --libs
-Wl,-Bsymbolic-functions -lGraphicsMagick++ -lGraphicsMagick 
$ pkg-config GraphicsMagick++ --cflags
-I/usr/include/GraphicsMagick 

But then I discovered the --libs-only-l/L arguments (didn't know about 
these):

$ pkg-config GraphicsMagick++ --libs-only-L

$ pkg-config GraphicsMagick++ --libs-only-l
-lGraphicsMagick++ -lGraphicsMagick

Nice.

David
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: magick2.changeset
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090825/f8e03457/attachment-0001.ksh 

From jwleblan at gmail.com  Tue Aug 25 08:06:58 2009
From: jwleblan at gmail.com (Joel LeBlanc)
Date: Tue, 25 Aug 2009 09:06:58 -0400
Subject: Unreliable OSX Builds
In-Reply-To: <69d8d540908250011s7c0d6021i1eaacbf553e0c037@mail.gmail.com>
References: <34716c2e0908240808l6c5cac49ldf4f02f9f176d51d@mail.gmail.com>
	<4A92DE3D.7060009@gmx.net>
	<34716c2e0908241211o30fe1645v2f89199e959b186e@mail.gmail.com>
	<69d8d540908250011s7c0d6021i1eaacbf553e0c037@mail.gmail.com>
Message-ID: <34716c2e0908250606i643bf74aqf24ce7ad385a5289@mail.gmail.com>

Easy Jaroslav.  I didn't mean to offend anyone.  The tone of my last e-mail
was somewhat poor, and I apologize.
I'm just saying that I don't have the necessary skills to help out here, and
it's frustrating because I really like the idea of octave, and would like to
contribute.  I can help by reporting bugs, and I can help by contributing
m-code, but if the project won't build I'm pretty much useless.

Since I starting following things (a few weeks before the last release), I
have been updating every day and Octave has only built maybe 10% of the
time.  There are no instructions for OSX, and the documentation I have found
says nothing about the huge number of configure parameters that is
apparently needed.  I'm not even sure if you're supposed to have lines like
that, but after I couldn't get it to work I modified what a fink maintainer
had done.  For all I know, I'm going about this in entirely the wrong way.

Maybe "So what?" is the response we want to have, but if that's the case,
what kind of community can we hope to develop?  Perhaps the group is too
small to support OSX (it feels like it's just Ben and I), or maybe none of
the core developers even have access to an OSX box, I don't know.  I was
just trying to give feedback and get some help.

Jaroslav, I didn't mean to be critical of you.  You are replying to pretty
much every e-mail, and from what I can tell, are involved in the majority of
the development.  I was kinda hoping you wouldn't even respond, and I would
here back from one of the NUMEROUS OSX users... all of whom build regularly,
and without fail... who would respond with the secret build script.  : D

Cheers,

~Joel

On Tue, Aug 25, 2009 at 3:11 AM, Jaroslav Hajek <highegg at gmail.com> wrote:

> On Mon, Aug 24, 2009 at 9:11 PM, Joel LeBlanc<jwleblan at gmail.com> wrote:
> > I'm not nearly talented enough to get this thing built with any
> confidence.
> >  For a while, I "fixed" something by adding "-L/sw/lib/fltk-aqua/lib
> > -L/sw/lib/flex/lib -L/sw/lib -lfltk_gl -lfltk" to the configure statement
> > (see my original post).
> > It seems that autoconf is completely unaware that port and fink produce
> /opt
> > and /sw folders that are highly likely to contain the libraries your
> gonna
> > need.  I'd try to help, but seriously, my ineptitude in such matters is
> > staggering ; )
>
>
>
> > What worries me is that it won't build... regularly.
>
> In the past few weeks, a lot of us experienced build problems, because
> John was making major changes to the configuration part. I think it's
> mostly settled, but if things still don't work for you, more tweaks
> are probably needed. I hope you understand, though, that without OSX
> users actually participating in development there's not much chance to
> ensure flawless builds on OSX.
>
> > It released without being able to be built.  How can this thing possibly
> be passing testing, and
> > get to a released, if it won't even build?
>
> Believe it or not, the release did build for a lot of people - in
> fact, nobody reported a build failure, so that's why it was released.
> Had you participated in the testing, you could have made a difference.
>
> > It's too bad.  I'd really like to contribute to testing (I'm a power
> Matlab
> > user), but I'm basically being left out.  Imagine the average Matlab
> user,
> > they're not going to tweak configure flags.
>
> So what?
>
> > As a result, they'll never even
> > have a chance to give feedback because it'll never build.
> > I guess bringing it up in the forums (is this really a forum?), is the
> best
> > way to start moving toward a fix.
>
> Well, yes, but it's like "going out of your door is the best way to
> start hiking". Someone needs to find out what's wrong, work out a fix,
> make a patch and then apply it. I (and not just I) will gladly do the
> last bit for you and possibly even assist you in the third one.
>
> > Thanks for the feedback guys!
> > ~Joel
> >
>
>
>
> --
> RNDr. Jaroslav Hajek
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090825/31c17545/attachment.html 

From highegg at gmail.com  Tue Aug 25 09:01:40 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Tue, 25 Aug 2009 16:01:40 +0200
Subject: Unreliable OSX Builds
In-Reply-To: <34716c2e0908250606i643bf74aqf24ce7ad385a5289@mail.gmail.com>
References: <34716c2e0908240808l6c5cac49ldf4f02f9f176d51d@mail.gmail.com>
	<4A92DE3D.7060009@gmx.net>
	<34716c2e0908241211o30fe1645v2f89199e959b186e@mail.gmail.com>
	<69d8d540908250011s7c0d6021i1eaacbf553e0c037@mail.gmail.com>
	<34716c2e0908250606i643bf74aqf24ce7ad385a5289@mail.gmail.com>
Message-ID: <69d8d540908250701u359a6f92n153c4ec8856375d5@mail.gmail.com>

On Tue, Aug 25, 2009 at 3:06 PM, Joel LeBlanc<jwleblan at gmail.com> wrote:
> Easy Jaroslav. ?I didn't mean to offend anyone.

And nobody was offended, I hope :)

> The tone of my last e-mail was somewhat poor, and I apologize.

Well, no need. I'm not exactly known to be diplomatic either.

> I'm just saying that I don't have the necessary skills to help out here, and
> it's frustrating because I really like the idea of octave, and would like to
> contribute. ?I can help by reporting bugs, and I can help by contributing
> m-code, but if the project won't build I'm pretty much useless.

I understand all that. Unfortunately, fixing the building process for
OSX is by far best done by OSX users. Despite using GNU/Linux, I think
supporting OSX is great, but I'm afraid I can help you here even less
than you can help yourself.

> Since I starting following things (a few weeks before the last release), I
> have been updating every day and Octave has only built maybe 10% of the
> time.

Well, as I said, that was just bad luck. There was only a single
change to configure.in in July and in June we also had just one :D

> There are no instructions for OSX, and the documentation I have found
> says nothing about the huge number of configure parameters that is
> apparently needed.

http://wiki.octave.org/wiki.pl?OctaveForMac
I'm sure your updates will be welcome. Just ask for password to the wiki.

> I'm not even sure if you're supposed to have lines like
> that, but after I couldn't get it to work I modified what a fink maintainer
> had done. ?For all I know, I'm going about this in entirely the wrong way.

I have no idea what "fink" is, but I take your word for that :)

> Maybe "So what?" is the response we want to have, but if that's the case,
> what kind of community can we hope to develop?

"So what?" was mainly a response to the "average Matlab user"
observation (which is probably correct) and I was curious what
conclusions you could draw from it. You'll see it's not easy.

> Perhaps the group is too
> small to support OSX (it feels like it's just Ben and I), or maybe none of
> the core developers even have access to an OSX box, I don't know.

As one of the currently most active developers, I confess my OSX
knowledge is essentially zero. All I know is that there usually are
very long paths :)

> I was just trying to give feedback and get some help.

That was perfectly OK.
Given that I was unable to actually help you, maybe I should have
saved my breath :) Couldn't resist, I guess.

> Jaroslav, I didn't mean to be critical of you.

No, of course not. Actually, I don't think you were critical at all,
just surprised that "It released without being able to be built.  How
can this thing possibly be passing testing, and get to a released, if
it won't even build." You probably expected a lot more to "passing
testing" than there really is. Usually the tarballs are released and
several regular contributors build & run test suite, and report
problems, if any. And that's about releases, not the development
sources.

> You are replying to pretty
> much every e-mail, and from what I can tell, are involved in the majority of
> the development. ?I was kinda hoping you wouldn't even respond, and I would
> here back from one of the NUMEROUS OSX users... all of whom build regularly,
> and without fail... who would respond with the secret build script. ?: D

lol :)

Setting up the build environment (with all deps) for Octave is not
easy even on GNU/Linux, and that is more common amongst Octavers. When
I started contributing to Octave (early 2008), it was a small victory
for me. And of course now there are more (weak) dependencies, so it's
even harder. But after you succeed, updating is usually just about "hg
pull -u; make -j2". Usually.

I hope you're still determined to become a contributor :)

regards

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


From jpswensen at comcast.net  Tue Aug 25 11:07:43 2009
From: jpswensen at comcast.net (John Swensen)
Date: Tue, 25 Aug 2009 12:07:43 -0400
Subject: Unreliable OSX Builds
In-Reply-To: <34716c2e0908240808l6c5cac49ldf4f02f9f176d51d@mail.gmail.com>
References: <34716c2e0908240808l6c5cac49ldf4f02f9f176d51d@mail.gmail.com>
Message-ID: <BE854F65-791E-45BE-AB2D-A86B07C57318@comcast.net>


On Aug 24, 2009, at 11:08 AM, Joel LeBlanc wrote:

> I have been building (or trying to build) octave on OSX for some  
> time now.  It didn't work, then I fixed a few things and it did for  
> a couple of weeks, now it won't build again.  Surely I am doing  
> something wrong.  I can't understand how the build process can be so  
> fragile.  There also don't seem to be clear instructions on how to  
> build, and from what I've read in the archives its far from autogen- 
> >configure->make.
>
> For example here is what I'm doing:
> __________________________________________________________
> #! /bin/sh -ev
>
> ./autogen.sh
>
> # Apple's vecLib:
> export blas='--with-lapack=-Wl,-framework,Accelerate,-dylib_file,/ 
> System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ 
> vecLib.framework/Versions/A/libLAPACK.dylib:/System/Library/ 
> Frameworks/Accelerate.framework/Versions/A/Frameworks/ 
> vecLib.framework/Versions/A/libLAPACK.dylib --with-blas=-Wl,- 
> framework,Accelerate,-dylib_file,/System/Library/Frameworks/ 
> Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/ 
> A/libBLAS.dylib:/System/Library/Frameworks/Accelerate.framework/ 
> Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib'
>
>
> # Similar to Fink's configure
> ./configure --prefix=/sw FLIBS=/sw/lib/gcc4.4/lib/libgfortran.dylib  
> F77=/sw/bin/gfortran FC=/sw/bin/gfortran CC=gcc-4 CPP=cpp-4 CXX=g+ 
> +-4 --infodir='${prefix}/share/info' --mandir='${prefix}/share/man'  
> --libexecdir='${prefix}/lib' -enable-shared -enable-dl --disable- 
> static --without-mpi --with-hdf5 --with-fftw CPPFLAGS="-g -I/sw/ 
> include -I/sw/include/freetype2 -I/sw/lib/flex/include" FFLAGS="-g - 
> ff2c" LDFLAGS="-L/sw/lib/fltk-aqua/lib -L/sw/lib/flex/lib -L/sw/lib - 
> lfltk_gl -lfltk -lpthread" $blas
>
> make clean
> make all
> __________________________________________________________
>
> And the results:
>
> g++-4 -dynamiclib -single_module -L/sw/lib/fltk-aqua/lib -L/sw/lib/ 
> flex/lib -L/sw/lib -lfltk_gl -lfltk -lpthread -L/sw/lib/fltk-aqua/ 
> lib -L/sw/lib/flex/lib -L/sw/lib -lfltk_gl -lfltk -lpthread - 
> install_name /sw/lib/octave-3.1.55/liboctinterp.dylib -o  
> liboctinterp.dylib pic/Cell.o pic/bitfcns.o pic/c-file-ptr-stream.o  
> pic/comment-list.o pic/cutils.o pic/data.o pic/debug.o pic/ 
> defaults.o pic/defun.o pic/dirfns.o pic/display.o pic/dynamic-ld.o  
> pic/error.o pic/file-io.o pic/gl-render.o pic/graphics.o pic/ 
> gripes.o pic/help.o pic/input.o pic/lex.o pic/load-path.o pic/load- 
> save.o pic/ls-hdf5.o pic/ls-mat-ascii.o pic/ls-mat4.o pic/ls-mat5.o  
> pic/ls-oct-ascii.o pic/ls-ascii-helper.o pic/ls-oct-binary.o pic/ls- 
> utils.o pic/main.o pic/mappers.o pic/matherr.o pic/mex.o pic/oct- 
> fstrm.o pic/oct-hist.o pic/oct-iostrm.o pic/oct-map.o pic/oct-obj.o  
> pic/oct-prcstrm.o pic/oct-procbuf.o pic/oct-stream.o pic/octave.o  
> pic/zfstream.o pic/oct-strstrm.o pic/oct-lvalue.o pic/pager.o pic/ 
> parse.o pic/pr-output.o pic/procstream.o pic/sighandlers.o pic/ 
> siglist.o pic/sparse-xdiv.o pic/sparse-xpow.o pic/strfns.o pic/ 
> syscalls.o pic/symtab.o pic/sysdep.o pic/token.o pic/toplev.o pic/ 
> txt-eng-ft.o pic/unwind-prot.o pic/utils.o pic/variables.o pic/ 
> xdiv.o pic/xnorm.o pic/xpow.o pic/ov-base.o pic/ov-ch-mat.o pic/ov- 
> cs-list.o pic/ov-list.o pic/ov-re-mat.o pic/ov-cx-mat.o pic/ov- 
> range.o pic/ov-scalar.o pic/ov-complex.o pic/ov-str-mat.o pic/ov- 
> struct.o pic/ov-colon.o pic/ov-bool-mat.o pic/ov-bool.o pic/ov-null- 
> mat.o pic/ov-cell.o pic/ov.o pic/ov-fcn.o pic/ov-builtin.o pic/ov- 
> dld-fcn.o pic/ov-mex-fcn.o pic/ov-usr-fcn.o pic/ov-fcn-handle.o pic/ 
> ov-fcn-inline.o pic/ov-class.o pic/ov-typeinfo.o pic/ov-flt-re-mat.o  
> pic/ov-flt-cx-mat.o pic/ov-float.o pic/ov-flt-complex.o pic/ov-re- 
> diag.o pic/ov-flt-re-diag.o pic/ov-cx-diag.o pic/ov-flt-cx-diag.o  
> pic/ov-perm.o pic/ov-int8.o pic/ov-int16.o pic/ov-int32.o pic/ov- 
> int64.o pic/ov-uint8.o pic/ov-uint16.o pic/ov-uint32.o pic/ov- 
> uint64.o pic/ov-base-sparse.o pic/ov-bool-sparse.o pic/ov-cx- 
> sparse.o pic/ov-re-sparse.o pic/pt.o pic/pt-arg-list.o pic/pt- 
> assign.o pic/pt-bp.o pic/pt-binop.o pic/pt-cbinop.o pic/pt-cell.o  
> pic/pt-check.o pic/pt-cmd.o pic/pt-colon.o pic/pt-const.o pic/pt- 
> decl.o pic/pt-eval.o pic/pt-except.o pic/pt-exp.o pic/pt-fcn- 
> handle.o pic/pt-id.o pic/pt-idx.o pic/pt-jump.o pic/pt-loop.o pic/pt- 
> mat.o pic/pt-misc.o pic/pt-pr-code.o pic/pt-select.o pic/pt-stmt.o  
> pic/pt-unop.o pic/op-b-b.o pic/op-b-bm.o pic/op-bm-b.o pic/op-bm- 
> bm.o pic/op-cell.o pic/op-chm.o pic/op-class.o pic/op-list.o pic/op- 
> range.o pic/op-str-m.o pic/op-str-s.o pic/op-str-str.o pic/op- 
> struct.o pic/op-double-conv.o pic/op-cm-cm.o pic/op-cm-cs.o pic/op- 
> cm-m.o pic/op-cm-s.o pic/op-cs-cm.o pic/op-cs-cs.o pic/op-cs-m.o pic/ 
> op-cs-s.o pic/op-m-cm.o pic/op-m-cs.o pic/op-m-m.o pic/op-m-s.o pic/ 
> op-s-cm.o pic/op-s-cs.o pic/op-s-m.o pic/op-s-s.o pic/op-float- 
> conv.o pic/op-fcm-fcm.o pic/op-fcm-fcs.o pic/op-fcm-fm.o pic/op-fcm- 
> fs.o pic/op-fcs-fcm.o pic/op-fcs-fcs.o pic/op-fcs-fm.o pic/op-fcs- 
> fs.o pic/op-fm-fcm.o pic/op-fm-fcs.o pic/op-fm-fm.o pic/op-fm-fs.o  
> pic/op-fs-fcm.o pic/op-fs-fcs.o pic/op-fs-fm.o pic/op-fs-fs.o pic/op- 
> int-concat.o pic/op-int-conv.o pic/op-i8-i8.o pic/op-i16-i16.o pic/ 
> op-i32-i32.o pic/op-i64-i64.o pic/op-ui8-ui8.o pic/op-ui16-ui16.o  
> pic/op-ui32-ui32.o pic/op-ui64-ui64.o pic/op-bm-sbm.o pic/op-b-sbm.o  
> pic/op-cm-scm.o pic/op-cm-sm.o pic/op-cs-scm.o pic/op-cs-sm.o pic/op- 
> m-scm.o pic/op-m-sm.o pic/op-sbm-b.o pic/op-sbm-bm.o pic/op-sbm- 
> sbm.o pic/op-scm-cm.o pic/op-scm-cs.o pic/op-scm-m.o pic/op-scm-s.o  
> pic/op-scm-scm.o pic/op-scm-sm.o pic/op-sm-cm.o pic/op-sm-cs.o pic/ 
> op-sm-m.o pic/op-sm-s.o pic/op-sm-scm.o pic/op-sm-sm.o pic/op-s- 
> scm.o pic/op-s-sm.o pic/op-cdm-cdm.o pic/op-cdm-cm.o pic/op-cdm-cs.o  
> pic/op-cdm-dm.o pic/op-cdm-m.o pic/op-cdm-s.o pic/op-cm-cdm.o pic/op- 
> cm-dm.o pic/op-dm-cdm.o pic/op-dm-cm.o pic/op-dm-cs.o pic/op-dm-dm.o  
> pic/op-dm-m.o pic/op-dm-s.o pic/op-m-cdm.o pic/op-m-dm.o pic/op-dm- 
> sm.o pic/op-dm-scm.o pic/op-fcdm-fcdm.o pic/op-fcdm-fcm.o pic/op- 
> fcdm-fcs.o pic/op-fcdm-fdm.o pic/op-fcdm-fm.o pic/op-fcdm-fs.o pic/ 
> op-fcm-fcdm.o pic/op-fcm-fdm.o pic/op-fdm-fcdm.o pic/op-fdm-fcm.o  
> pic/op-fdm-fcs.o pic/op-fdm-fdm.o pic/op-fdm-fm.o pic/op-fdm-fs.o  
> pic/op-fm-fcdm.o pic/op-fm-fdm.o pic/op-cm-pm.o pic/op-fcm-pm.o pic/ 
> op-fm-pm.o pic/op-pm-fcm.o pic/op-pm-fm.o pic/op-m-pm.o pic/op-pm- 
> cm.o pic/op-pm-m.o pic/op-pm-pm.o pic/op-pm-sm.o pic/op-pm-scm.o pic/ 
> Array-os.o pic/Array-tc.o pic/oct-errno.o pic/builtins.o pic/ 
> ops.o ../libcruft/blas-xtra/pic/xerbla.o  -L../liboctave -loctave - 
> L../libcruft -lcruft  -lfftw3 -lfftw3f  -lhdf5  -lz -L/usr/X11/lib - 
> lfontconfig -lftgl -L/sw/lib -lfreetype -lz -Wl,- 
> framework,CoreServices -Wl,-framework,ApplicationServices -Wl,- 
> framework -Wl,OpenGL -L/usr/X11/lib -lX11 -Wl,-framework -Wl,Carbon - 
> lreadline -lm
> Undefined symbols:
> "__gfortran_st_write", referenced from:
>     _xerbla_ in xerbla.o
> "__gfortran_st_write_done", referenced from:
>     _xerbla_ in xerbla.o
> "__gfortran_transfer_character", referenced from:
>     _xerbla_ in xerbla.o
> "__gfortran_transfer_integer", referenced from:
>     _xerbla_ in xerbla.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[2]: *** [liboctinterp.dylib] Error 1
> make[1]: *** [src] Error 2
> make: *** [all] Error 2
> miys02-leblanpb2:octave leblanc$
>
>
> Is there a reliable way to get things built?  Do any of the  
> developers work on OSX, or is there a procedure that SHOULD result  
> in a successful build?  How do I get to the current stable code (I'm  
> assuming the HEAD is the "testing/devepment" code).
>
> I apologize in advance for my ignorance,
>
> ~Joel

I have a modified version of this same script that uses the Fink GCC4,  
rather than that provided by Apple.  I'm not sure if this will help,  
but here is my script for configuring:

# Apple's vecLib:
a='--with-lapack=-Wl,-framework,Accelerate,-dylib_file,/System/Library/ 
Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/ 
Versions/A/libLAPACK.dylib:/System/Library/Frameworks/ 
Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/ 
libLAPACK.dylib --with-blas=-Wl,-framework,Accelerate,-dylib_file,/ 
System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ 
vecLib.framework/Versions/A/libBLAS.dylib:/System/Library/Frameworks/ 
Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/ 
libBLAS.dylib'

# Similar to Fink's configure
./configure --prefix=/sw/opt/octave/hg20090520 FLIBS=/sw/lib/gcc4.3/ 
lib/libgfort
ran.dylib F77=/sw/bin/gfortran --infodir='${prefix}/share/info' -- 
mandir='${pref
ix}/share/man' --libexecdir='${prefix}/lib' -enable-shared -enable-dl  
--disable-
static --without-mpi --with-hdf5 --with-fftw CPPFLAGS="-I/sw/include - 
FOpenGL -I
/sw/opt/octavegl/include -I/sw/include/freetype2" FFLAGS="-ff2c"  
LDFLAGS="-dylib
_file /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ 
libGL.dyl
ib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ 
libGL.dylib
-L/sw/lib/fltk-aqua/lib -L/sw/lib -lfltk_gl -framework AGL -framework  
OpenGL -lf
ltk -lpthread -framework Carbon -framework ApplicationServices " $a


Hope this might help.  I haven't tried building Octave for OSX in  
several months, but it did work on a repository version as recent as  
2009_05_20.

John Swensen


From jwe at octave.org  Tue Aug 25 14:22:32 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 25 Aug 2009 15:22:32 -0400
Subject: popen2 vs pclose
Message-ID: <19092.14840.653613.198317@segfault.lan>

Octave's popen2 function will create zombie processes, even if you use
pclose to close streams returned by popen2.  One problem is that
popen2 does not set the close function for the stream to be pclose.
But just doing that is not enough since pclose does not know about
files opened with popen2.  It only knows about child processes that
are created with popen.

The attached diff shows a draft of a solution I came up with that I
think will fix the popen2 zombie problem.  The idea is to keep track
of the pid for the process created by popen2, then wait for it when
either the input or output stream is closed.  I'm not sure whether
this is the best thing to do.  Maybe there are reasons to close one
end of the connection to the process but not wait for it to exit?  If
so, then this fix will also cause some trouble.

Also, the two streams returned by popen2 are not associated with
one another and with this patch, both store the pid.  This means that
waitpid is called once for each stream.  That doesn't seem like the
best thing to do.

Maybe it is just best to expect users of the popen2 function to do
something like

  [in, out, pid] = popen2 (...);

  ...

  fclose (in);
  fclose (out);

  waitpid (pid);

and not try to do this automatically for them.  If so, then I think we
just need to document this behavior and make sure that this is done
properly for any code in Octave that uses popen2.

Comments or suggestions?

Thanks,

jwe

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs
Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090825/5b1b6f08/attachment.ksh 

From bpabbott at mac.com  Tue Aug 25 14:22:35 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Tue, 25 Aug 2009 15:22:35 -0400
Subject: overriding print.m pdf default terminal choices?
In-Reply-To: <40068F1C-C18D-48A6-8B9E-AC0BFC2AF27C@mac.com>
References: <150650070158267485735317469619294396129-Webmail@me.com>
	<152987640169990211162329315010467704320-Webmail@me.com>
	<4A89AA20.3060802@gmx.net> <4A92F199.3090305@gmx.net>
	<40068F1C-C18D-48A6-8B9E-AC0BFC2AF27C@mac.com>
Message-ID: <743D2725-CD80-48FE-8665-6DBE0F7B329C@mac.com>


On Aug 24, 2009, at 6:43 PM, Ben Abbott wrote:

> On Aug 24, 2009, at 4:01 PM, Benjamin Lindner wrote:
>
>> Benjamin Lindner wrote:
>>> Ben Abbott wrote:
>>>> On Monday, August 17, 2009, at 11:27AM, "Benjamin Lindner" <lindnerben at gmx.net 
>>>> > wrote:
>>>>> Hello list,
>>>>>
>>>>> I wondered if it is possible to force print.m to use ghostscript  
>>>>> for
>>>>> printing to pdf even if gnuplot provides a pdfcairo terminal?
>>>>>
>>>>> I ask because the last available gnuplot for win32 does not  
>>>>> include the
>>>>> patch which fixes the spurious-pages-in-pdf-output bug.
>>>>> So a command as
>>>>> plot(0:0.1:10, sin(0:0.1:10), "@-"); print -dpdf test.pdf
>>>>> produces a three-page pdf.
>>>>>
>>>>> I don't know when there will be a new gnuplot release or snapshot
>>>>> release but the do not happen very frequently.
>>>>>
>>>>> So for the mingw32 binaries I'd like to have print.m to use ps- 
>>>>> >pdf via
>>>>> ghostscript for the moment.
>>>>>
>>>>> benjamin
>>>>
>>>> I assume you are referring to Octave's latest sources, and that  
>>>> you are not running gnuplot's development sources (meaning your  
>>>> version of gnuplot is 4.2.x, or earlier)?
>>> Actually I'm referring to the 3.2.x branch of octave and the  
>>> latest version of gnuplot available is the 2008-11-21 4.3.0 cvs  
>>> snapshot.
>>>> If so then, what you're asking for should be the default. If it  
>>>> is not, then the check for ghostscript may be failing.
>>>>
>>>> Does the code below indicate you have ghostscript installed?
>>>>
>>>>   if (~isempty (getenv ("GSC")))
>>>>     persistent ghostscript_binary = getenv ("GSC");
>>>>   else
>>>>     persistent ghostscript_binary = "gswin32c";
>>>>   endif
>>>>   [status, output] = system (sprintf ("if exist \"%s\" ( exit /B  
>>>> 1 ) else ( exit /B 0 )", ghostscript_binary));
>>>>   have_ghostscript = (status == 0)
>>>>
>>>> Ben
>>>>
>>> thanks for the hint.
>>> I have the environment variable GSC defined as
>>> > ghostscript_binary = getenv("GSC")
>>> ghostscript_binary = C:\Programs\gs\gs8.62\bin\gswin32c.exe
>>> and naturally this executable exists.
>>> However, have_ghostscript evaluates to false.
>>> This is strange.
>>> Seems the exit code is not propagated into the variable status, as
>>> > [s,o]=system("exit 1")
>>> s =  127
>>> o =
>>> but
>>> > system("exit 1")
>>> ans =  1
>>> I need to investigate this further.
>>
>> Ben, I think your code snippet above is out of date.
>> In both 3.2.3 and current development tip I have
>>
>> elseif (ispc ())
>>     [status, output] = system (sprintf ("if exist \"%s\" ( exit /B  
>> 1 ) else ( exit /B 0 )", ghostscript_binary));
>>     have_ghostscript = (status ~= 0);
>> endif
>>
>> The fact that calling system with two outputs does not return the  
>> correct exit code on windows aside, I end up with have_ghostscript  
>> = 1.
>> I use the 4.3.0-cvs snapshot of 2008-11-21 (from the gnuplot  
>> homepage) and built with support for the pdfcairo terminal.
>>
>> The result being that print uses the pdfcairo terminal, because it  
>> is preferred over an available ghostscript.
>>
>> And I'm back again at my first question: Is there an easy way to  
>> make print.m prefer the ghostscript way?
>> Or do I need to provide a 4.3.0 version of gnuplot without the  
>> cairo terminals?
>>
>> benjamin
>
> You are correct. Thanks for catching my error.
>
> Although others have expressed a preference for the cairo terminals,  
> I have no objection the changing the preferred default to use  
> Ghostscript. There is one feature of the postscript terminal that  
> concerns me. The ghostcript terminal explicitly sets the BBOX to be  
> 50pts inside the edge of the page. This often results in text being  
> clipped with printed.
>
> Perhaps print() should be rewritten to crop ps output at the BBOX?  
> If so a 50pt border added to the pagesize and then clipped by  
> ghostscript. Once that is done, we could also produce eps output by  
> converting a postscript file. This would be nice as gnuplot's eps  
> terminal scales down the size of the fonts.
>
> The only problem with that is we currently don't have ghostscript as  
> a run time dependency. Should that be changed?
>
> In any event, I'm presently not able to build octave, am weary of  
> producing any changesets until I can.
>
> Ben

I opted for a less ambitious solution. The attached changeset allow  
the use to add "-ghostscript" when producing a pdf output.

Is that an acceptable solution?

Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: changeset.patch
Type: application/octet-stream
Size: 2655 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090825/91ca230e/attachment.obj 
-------------- next part --------------






From bpabbott at mac.com  Tue Aug 25 15:18:51 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Tue, 25 Aug 2009 16:18:51 -0400
Subject: popen2 vs pclose
In-Reply-To: <19092.14840.653613.198317@segfault.lan>
References: <19092.14840.653613.198317@segfault.lan>
Message-ID: <168381465217114815009196428085031587628-Webmail@me.com>

On Tuesday, August 25, 2009, at 03:22PM, "John W. Eaton" <jwe at octave.org> wrote:
>Octave's popen2 function will create zombie processes, even if you use
>pclose to close streams returned by popen2.  One problem is that
>popen2 does not set the close function for the stream to be pclose.
>But just doing that is not enough since pclose does not know about
>files opened with popen2.  It only knows about child processes that
>are created with popen.
>
>The attached diff shows a draft of a solution I came up with that I
>think will fix the popen2 zombie problem.  The idea is to keep track
>of the pid for the process created by popen2, then wait for it when
>either the input or output stream is closed.  I'm not sure whether
>this is the best thing to do.  Maybe there are reasons to close one
>end of the connection to the process but not wait for it to exit?  If
>so, then this fix will also cause some trouble.
>
>Also, the two streams returned by popen2 are not associated with
>one another and with this patch, both store the pid.  This means that
>waitpid is called once for each stream.  That doesn't seem like the
>best thing to do.
>
>Maybe it is just best to expect users of the popen2 function to do
>something like
>
>  [in, out, pid] = popen2 (...);
>
>  ...
>
>  fclose (in);
>  fclose (out);
>
>  waitpid (pid);
>
>and not try to do this automatically for them.  If so, then I think we
>just need to document this behavior and make sure that this is done
>properly for any code in Octave that uses popen2.
>
>Comments or suggestions?
>
>Thanks,
>
>jwe

Adding the "waitpid (pid)" for the gnuplot backend would be fairly simple, so from that perspective either would work.

Ben

From rob at utk.edu  Tue Aug 25 16:37:46 2009
From: rob at utk.edu (Rob Mahurin)
Date: Tue, 25 Aug 2009 17:37:46 -0400
Subject: popen2 vs pclose
In-Reply-To: <19092.14840.653613.198317@segfault.lan>
References: <19092.14840.653613.198317@segfault.lan>
Message-ID: <9C63D265-D0F9-47D3-B977-6D44A4C7EC23@utk.edu>

On Aug 25, 2009, at 3:22 PM, John W. Eaton wrote:
> Maybe it is just best to expect users of the popen2 function to do
> something like
>
>   [in, out, pid] = popen2 (...);
>   ...
>   fclose (in);
>   fclose (out);
>   waitpid (pid);
>
> and not try to do this automatically for them.  If so, then I think we
> just need to document this behavior and make sure that this is done
> properly for any code in Octave that uses popen2.

This seems to be the approach taken by Perl's IPC::Open2:

>> open2() does not wait for and reap the child process after it  
>> exits.  Except for short programs where it's acceptable to let the  
>> operating system take care of this, you need to do this yourself.  
>> This is normally as simple as calling "waitpid $pid, 0" when  
>> you're done with the process. Failing to do this can result in an  
>> accumulation of defunct or "zombie" processes. See "waitpid" in  
>> perlfunc for more information.

Python (http://pydoc.org/2.4.1/popen2.html) seems to have a class  
with poll() and wait() methods, closer perhaps to your proposed patch.

The reason to call wait() is to collect the status of the child, and  
the reason that zombies stay in the process table is to allow this  
status to be collected.  If you write auto-reaping code where waitpid 
() is called at least twice for each pipe, then the whichever call  
happens second is guaranteed to fail and there's no reliable access  
to the exit status unless you invent a user-space-accessible object.

I think the documentation solution is the simplest and the least  
likely to cause mysteries later on.

Rob

-- 
Rob Mahurin
University of Manitoba, Dept. of Physics & Astronomy
at:	Oak Ridge National Laboratory	865 207 2594
	Oak Ridge, Tennessee		rob at utk.edu


From jwe at octave.org  Tue Aug 25 16:44:04 2009
From: jwe at octave.org (John W. Eaton)
Date: Tue, 25 Aug 2009 17:44:04 -0400
Subject: popen2 vs pclose
In-Reply-To: <9C63D265-D0F9-47D3-B977-6D44A4C7EC23@utk.edu>
References: <19092.14840.653613.198317@segfault.lan>
	<9C63D265-D0F9-47D3-B977-6D44A4C7EC23@utk.edu>
Message-ID: <19092.23332.213648.551852@segfault.lan>

On 25-Aug-2009, Rob Mahurin wrote:

| I think the documentation solution is the simplest and the least  
| likely to cause mysteries later on.

I agree.  I checked in the following change.

  http://hg.savannah.gnu.org/hgweb/octave/rev/c60a9e1a0372

Note that we were also leaving zombies for something as simple as

  ...plot something...
  close all

The patch I checked in should also fix that problem.

The popen2 docstring still needs to have a note added.  I'd be
grateful if someone else could take care of that.

Thanks,

jwe

From rob at utk.edu  Wed Aug 26 00:54:15 2009
From: rob at utk.edu (Rob Mahurin)
Date: Wed, 26 Aug 2009 01:54:15 -0400
Subject: popen2 vs pclose
In-Reply-To: <19092.23332.213648.551852@segfault.lan>
References: <19092.14840.653613.198317@segfault.lan>
	<9C63D265-D0F9-47D3-B977-6D44A4C7EC23@utk.edu>
	<19092.23332.213648.551852@segfault.lan>
Message-ID: <6318FBF0-DB6A-4D8C-A3D4-1B3E8EC4D833@utk.edu>

On Aug 25, 2009, at 5:44 PM, John W. Eaton wrote:
> The popen2 docstring still needs to have a note added.  I'd be
> grateful if someone else could take care of that.

Here's a changeset.

Can these patches go in 3.2.3 ?

Rob

-- 
Rob Mahurin
University of Manitoba, Dept. of Physics & Astronomy
at:	Oak Ridge National Laboratory	865 207 2594
	Oak Ridge, Tennessee		rob at utk.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: waitpid.patch
Type: application/octet-stream
Size: 1311 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090826/96e1f9fb/attachment.obj 
-------------- next part --------------



From highegg at gmail.com  Wed Aug 26 01:08:45 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 26 Aug 2009 08:08:45 +0200
Subject: popen2 vs pclose
In-Reply-To: <19092.23332.213648.551852@segfault.lan>
References: <19092.14840.653613.198317@segfault.lan>
	<9C63D265-D0F9-47D3-B977-6D44A4C7EC23@utk.edu>
	<19092.23332.213648.551852@segfault.lan>
Message-ID: <69d8d540908252308w79b5f0a5ya497cf9ee6e01dcd@mail.gmail.com>

On Tue, Aug 25, 2009 at 11:44 PM, John W. Eaton<jwe at octave.org> wrote:
> On 25-Aug-2009, Rob Mahurin wrote:
>
> | I think the documentation solution is the simplest and the least
> | likely to cause mysteries later on.
>
> I agree. ?I checked in the following change.
>
> ?http://hg.savannah.gnu.org/hgweb/octave/rev/c60a9e1a0372
>
> Note that we were also leaving zombies for something as simple as
>
> ?...plot something...
> ?close all
>
> The patch I checked in should also fix that problem.
>
> The popen2 docstring still needs to have a note added. ?I'd be
> grateful if someone else could take care of that.
>
> Thanks,
>
> jwe
>

I'm likewise happy with this situation; where popen2 is just shortcut
for pipe&fork&exec. This is also cleaner because there is no confusion
about which pclose returns the exit code. Further, I think it would be
wrong to wait for the child as soon as *either* stream is closed; I
can think of numerous cases where you want to close the process's
input but keap reading its output.

regards

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


From highegg at gmail.com  Wed Aug 26 01:19:02 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Wed, 26 Aug 2009 08:19:02 +0200
Subject: popen2 vs pclose
In-Reply-To: <6318FBF0-DB6A-4D8C-A3D4-1B3E8EC4D833@utk.edu>
References: <19092.14840.653613.198317@segfault.lan>
	<9C63D265-D0F9-47D3-B977-6D44A4C7EC23@utk.edu>
	<19092.23332.213648.551852@segfault.lan>
	<6318FBF0-DB6A-4D8C-A3D4-1B3E8EC4D833@utk.edu>
Message-ID: <69d8d540908252319n7c778870x66db0bb133e95659@mail.gmail.com>

On Wed, Aug 26, 2009 at 7:54 AM, Rob Mahurin<rob at utk.edu> wrote:
> On Aug 25, 2009, at 5:44 PM, John W. Eaton wrote:
>>
>> The popen2 docstring still needs to have a note added. ?I'd be
>> grateful if someone else could take care of that.
>
> Here's a changeset.
>

Applied. Please add this to your .hgrc so that you get the correct
user info into each changeset:
[ui]
username = Rob Mahurin <rob at utk.edu>

Also, you omitted \n in the patch.

> Can these patches go in 3.2.3 ?

I transplanted both of them.

thanks

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


From tmacchant at yahoo.co.jp  Wed Aug 26 04:58:10 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Wed, 26 Aug 2009 18:58:10 +0900 (JST)
Subject: GCC for octave/mingw32 (and ,
	mingw64?) (was OctaveForWindows Wiki (CategoryInstall) is updated
	(2009-08-24))
In-Reply-To: <20090825083301.189590@gmx.net>
Message-ID: <20090826095810.95125.qmail@web3802.mail.bbt.yahoo.co.jp>

Hello Benjamin

The discussion is better to be moved to the maintainers list.
Because discussions have been on the selection of GCC-complier.

In my opinion, from users point of view, the mingw complier is official or not is small problem.
I have been used for GCC-4.3.3-TDM for octave building before the gcc-4.4.0 MinGW on MinGW official
site. It worked fine for me.

The 'clear all' crash problem exist for octave-3.2.x by gcc-4.3.0-TDM, while no problem occurs for
that by GCC-4.4.0-Official.  

In the readme
The command "clear all" exits with the error message
   
     error: stdin is not a tty!
   
   in conjunction with the ARPACK package e.g. when calling eigs()

In my computer, 'clear all' cashe octave soon after 'error: stdin is not a tty' when callinf eigs() on
octave3.2.2/GCC-4.3.0.MinGW/TDM.


The combination octave-3.2.x and gcc-4.3.0-TDM seems to cause this problem.

However, GCC-4.4.0-Official has the problem to use shared libstdc++ for dll and oct file building.
Please see

http://www.nabble.com/octave-3.2.2-build-with-libstdc%2B%2B_s.a-by-GCC-4.4.0-(MinGW-Official)-td24662825.html#a24879769

I think that if 'clear all' problem is serious and this problem will not be solved easily, it is
better you to try gcc-4.4.0-MinGW official.


> BTW, do you know that there are x64 versions of gcc for win64 which are *not* provided by the
> mingw project (and hence also 'unofficial'?).
> They look very good, and I'll certainly going to use them for trying w64 builds of octave. 

Sounds good. I do not have a 64 bit machine at present and looking forward to hearing good news from
you.

Regards

Tatsuro

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

From jwe at octave.org  Wed Aug 26 10:37:37 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 26 Aug 2009 11:37:37 -0400
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A8BB83A.4060408@gmx.net>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
	<4A868317.10203@gmx.net> <19081.34869.778915.594647@segfault.lan>
	<4A8A63BE.4090300@gmx.net> <19082.50054.994278.817764@segfault.lan>
	<4A8BB83A.4060408@gmx.net>
Message-ID: <19093.22209.535838.360776@segfault.lan>

On 19-Aug-2009, Benjamin Lindner wrote:

| John W. Eaton wrote:
| > On 18-Aug-2009, Benjamin Lindner wrote:
| > 
| > | John W. Eaton wrote:
| > | > On 15-Aug-2009, Benjamin Lindner wrote:
| > | > 
| > | > | Now for the undefined reference linker errors:
| > | > 
| > | > I checked in some additional changes.  I will deal with the mkoctfile
| > | > and octave-bug scripts/programs later, but is there anything that I
| > | > missed for building libcruft, liboctave, liboctinterp, and the .oct
| > | > files?
| > | > 
| > | 
| > | Aside from the pending octave-bug.cc and mkoctfile.cc changes,
| > | building and linking completes successfully for mingw32/gcc.
| > 
| > I checked in changes for octave-bug.cc.in and mkoctfile.cc.in so they
| > should build now.  Are there still problems?  BTW, this is why I think
| > we should eliminate the script versions of these files.  It would be
| > easier to ensure consistency if we didn't have both shell script and
| > C++ versions...
| > 
| > jwe
| > 
| 
| building from the following tip
| 
| changeset:   9545:8670e55078fd
| tag:         tip
| user:        Jaroslav Hajek <highegg at gmail.com>
| date:        Mon Aug 17 14:46:18 2009 +0200
| summary:     allow constructing octave_value_list from size
| 
| build fails at build-octave.cc with the attached errors.
| I guess all substitution variables should be prefixed with 
| 'OCTAVE_CONF_' as in the attached changeset.
| 
| Furthermore, there is a '|' character where it should be a '+' character 
| in line 254 in mkoctfile.cc.in -> see changeset.
| 
| 
| However, linking liboctinterp.dll now again fails with the following error
| Creating library file: 
| liboctinterp.dll.a../libcruft/blas-xtra/xerbla.o:xerbla.f:(.text+0x50): 
| undefined reference to `_gfortran_st_write'
| ../libcruft/blas-xtra/xerbla.o:xerbla.f:(.text+0x67): undefined 
| reference to `_gfortran_transfer_character'
| ../libcruft/blas-xtra/xerbla.o:xerbla.f:(.text+0x7e): undefined 
| reference to `_gfortran_transfer_integer'
| ../libcruft/blas-xtra/xerbla.o:xerbla.f:(.text+0x86): undefined 
| reference to `_gfortran_st_write_done'
| 
| Since xerbla.o is linked directly into liboctinterp.dll, $(FLIBS) is 
| required in the link dependencies as
| 
| diff -r 87d36823eb0d src/Makefile.in
| --- a/src/Makefile.in   Wed Aug 19 10:09:44 2009 +0200
| +++ b/src/Makefile.in   Wed Aug 19 10:27:04 2009 +0200
| @@ -331,7 +331,7 @@
|     $(HDF5_LDFLAGS) $(HDF5_LIBS) $(Z_LDFLAGS) $(Z_LIBS) \
|     $(OPENGL_LIBS) $(X11_LIBS) $(CARBON_LIBS) \
|     $(READLINE_LIBS) \
| -  $(LIBS)
| +  $(FLIBS) $(LIBS)
| 
|   OCT_LINK_DEPS = $(RLD_FLAG) -L. $(LIBOCTINTERP) \
|     -L../liboctave $(LIBOCTAVE) \

I made this change.

| The rest builds & links fine.

I added a ChangeLog entry and checked in your changeset.

Thanks,

jwe

From jwe at octave.org  Wed Aug 26 10:40:00 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 26 Aug 2009 11:40:00 -0400
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A8AF498.6000306@gmx.net>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
	<4A867B26.3030508@gmx.net> <19082.54127.595607.366724@segfault.lan>
	<4A8AF498.6000306@gmx.net>
Message-ID: <19093.22352.617077.954938@segfault.lan>

On 18-Aug-2009, Thomas Treichl wrote:

| > Where is the requirement for -lexpat coming from?
| 
| -lexpat "or" -lxml2 is a dependency of -lfontconfig, I don't know if this in a 
| general issue or if I need to fight such things for myself?

Probably our check for the fontconfig library needs to take that into
account.  I haven't tried to update the part of the configure script
that checks for the fontconfig library.

jwe

From jwe at octave.org  Wed Aug 26 10:44:33 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 26 Aug 2009 11:44:33 -0400
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <96361AD8-3C95-451A-804E-30E1F1430F08@mac.com>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
	<4A867B26.3030508@gmx.net> <19082.54127.595607.366724@segfault.lan>
	<4A8AF498.6000306@gmx.net>
	<030AB5F5-E4F5-4FB7-B776-2152E7973630@mac.com>
	<4A8C61EE.8040706@gmx.net>
	<96361AD8-3C95-451A-804E-30E1F1430F08@mac.com>
Message-ID: <19093.22625.379388.107881@segfault.lan>

On 19-Aug-2009, Ben Abbott wrote:

| I don't have much spare time for Octave at the moment, but ... my  
| attempt to build from sources I pulled on the 17th failed while  
| building liboctinterp.dylib
| 
| Undefined symbols:
|   "__gfortran_st_write", referenced from:
|       _xerbla_ in xerbla.o
|   "__gfortran_transfer_character", referenced from:
|       _xerbla_ in xerbla.o
|   "__gfortran_st_write_done", referenced from:
|       _xerbla_ in xerbla.o
|   "__gfortran_transfer_integer", referenced from:
|       _xerbla_ in xerbla.o
| ld: symbol(s) not found
| collect2: ld returned 1 exit status
| make[2]: *** [liboctinterp.dylib] Error 1
| make[1]: *** [src] Error 2
| make: *** [all] Error 2

I've added BLAS_LIBS to the list for linking octave and liboctinterp.

jwe

From jwe at octave.org  Wed Aug 26 11:12:55 2009
From: jwe at octave.org (John W. Eaton)
Date: Wed, 26 Aug 2009 12:12:55 -0400
Subject: linking liboctave fails
In-Reply-To: <MTAwMDAwMi5ub21hZA.1250804680@quikprotect>
References: <mailman.3530.1250784514.29411.octave-maintainers@octave.org>
	<MTAwMDAwMi5ub21hZA.1250804680@quikprotect>
Message-ID: <19093.24327.580809.381797@segfault.lan>

On 20-Aug-2009, Rik wrote:

| 8/20/09
| 
| Yet more issues with the configuration files and building.  I don't have
| the development package for libcurl.  This is fine and the configuration
| scripts give me the following message:
| configure: WARNING: cURL library not found.  The urlread and urlwrite
| functions will be disabled.
| 
| That is indeed what used to happen but now the build process ignores the
| configure script and attempts to build urlwrite anyways which results in:
| 
| g++ -shared -o urlwrite.oct pic/urlwrite.o -Wl,-rpath
| -Wl,/home/rik/downloads/movies/local/lib/octave-3.1.55 -L. -loctinterp
| -L../liboctave -loctave -L../libcruft -lcruft  -lcurl
| /usr/bin/ld: cannot find -lcurl
| collect2: ld returned 1 exit status
| make[2]: *** [urlwrite.oct] Error 1
| make[2]: *** Waiting for unfinished jobs....
| make[2]: Leaving directory `/home/rik/wip/Projects_Mine/octave-dev/src'
| 
| I hope someone can restore the correct build behavior.

If you don't have the curl libraries, then the definition of CURL_LIBS
in the Makeconf file should be empty.  Is it?  If not, why not?  How
is the test for the library succeding if you don't have the library?

I removed the libcurl-dev packages on my system and ran configure
again and CURL_LIBS is empty, so linking urlwrite.oct succeeds.  Then
the urlread and urlwrite functions are still present but they only
produce error messages explaining that the functionality is missing.
So it seems to work as expected for me.

jwe

From octave at nomad.inbox5.com  Wed Aug 26 12:54:39 2009
From: octave at nomad.inbox5.com (Rik)
Date: Wed, 26 Aug 2009 10:54:39 -0700
Subject: linking liboctave fails
In-Reply-To: <19093.24327.580809.381797@segfault.lan>
References: <mailman.3530.1250784514.29411.octave-maintainers@octave.org>	<MTAwMDAwMi5ub21hZA.1250804680@quikprotect>
	<19093.24327.580809.381797@segfault.lan>
Message-ID: <MTAwMDAwNS5ub21hZA.1251309287@quikprotect>

John W. Eaton wrote:
> On 20-Aug-2009, Rik wrote:
>
> | 8/20/09
> | 
> | Yet more issues with the configuration files and building.  I don't have
> | the development package for libcurl.  This is fine and the configuration
> | scripts give me the following message:
> | configure: WARNING: cURL library not found.  The urlread and urlwrite
> | functions will be disabled.
> | 
> | That is indeed what used to happen but now the build process ignores the
> | configure script and attempts to build urlwrite anyways which results in:
> | 
> | g++ -shared -o urlwrite.oct pic/urlwrite.o -Wl,-rpath
> | -Wl,/home/rik/downloads/movies/local/lib/octave-3.1.55 -L. -loctinterp
> | -L../liboctave -loctave -L../libcruft -lcruft  -lcurl
> | /usr/bin/ld: cannot find -lcurl
> | collect2: ld returned 1 exit status
> | make[2]: *** [urlwrite.oct] Error 1
> | make[2]: *** Waiting for unfinished jobs....
> | make[2]: Leaving directory `/home/rik/wip/Projects_Mine/octave-dev/src'
> | 
> | I hope someone can restore the correct build behavior.
>
> If you don't have the curl libraries, then the definition of CURL_LIBS
> in the Makeconf file should be empty.  Is it?  If not, why not?  How
> is the test for the library succeding if you don't have the library?
>   
There has been a lot of change to the configure scripts.  When I wrote,
about a week ago, CURL_LIBS was defined to -lcurl despite not having the
development version of libcurl.  The problem has been fixed and now
CURL_LIBS is empty.  I haven't bothered to check which Changeset
actually solved it.

--Rik


From lindnerben at gmx.net  Wed Aug 26 14:45:32 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Wed, 26 Aug 2009 21:45:32 +0200
Subject: 3.2.3 RC1
In-Reply-To: <69d8d540908250129k1273eccaq3629b475379bc348@mail.gmail.com>
References: <20090825061251.205040@gmx.net>
	<69d8d540908250129k1273eccaq3629b475379bc348@mail.gmail.com>
Message-ID: <4A9590DC.3060904@gmx.net>

Jaroslav Hajek wrote:
> On Tue, Aug 25, 2009 at 8:12 AM, Benjamin Lindner<lindnerben at gmx.net> wrote:
>> Hello,
>>
>> The imread/imfinfo issue as reported in
>> http://www.nabble.com/imgwrite-imfinfo-fail-in-octave-3.2.x-td25004136.html
>> should also be fixed before releasing a new 3.2.x version.
>>
> 
> Done.

thanks

>> Unfortunately there is no test of the imread/imwrite/imfinfo scripts in the 3.2.x branch, thus it does not show in "make check", so I missed it at first...
> 
> Maybe there's a patch that can be transplanted?
> 

The following two changesets added a test to imread.m in the development 
sources:

http://hg.savannah.gnu.org/hgweb/octave/rev/ab563d2adc10
http://hg.savannah.gnu.org/hgweb/octave/rev/8a082b66c1e0

ben

From lindnerben at gmx.net  Wed Aug 26 15:21:45 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Wed, 26 Aug 2009 22:21:45 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <19093.22209.535838.360776@segfault.lan>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>	<19077.28862.827842.41629@segfault.lan>	<4A868317.10203@gmx.net>	<19081.34869.778915.594647@segfault.lan>	<4A8A63BE.4090300@gmx.net>	<19082.50054.994278.817764@segfault.lan>	<4A8BB83A.4060408@gmx.net>
	<19093.22209.535838.360776@segfault.lan>
Message-ID: <4A959959.3040707@gmx.net>

John W. Eaton wrote:
> On 19-Aug-2009, Benjamin Lindner wrote:
> 
> | John W. Eaton wrote:
> | > On 18-Aug-2009, Benjamin Lindner wrote:
> | > 
> | > | John W. Eaton wrote:
> | > | > On 15-Aug-2009, Benjamin Lindner wrote:
> | > | > 
> | > | > | Now for the undefined reference linker errors:
> | > | > 
> | > | > I checked in some additional changes.  I will deal with the mkoctfile
> | > | > and octave-bug scripts/programs later, but is there anything that I
> | > | > missed for building libcruft, liboctave, liboctinterp, and the .oct
> | > | > files?
> | > | > 
> | > | 
> | > | Aside from the pending octave-bug.cc and mkoctfile.cc changes,
> | > | building and linking completes successfully for mingw32/gcc.
> | > 
> | > I checked in changes for octave-bug.cc.in and mkoctfile.cc.in so they
> | > should build now.  Are there still problems?  BTW, this is why I think
> | > we should eliminate the script versions of these files.  It would be
> | > easier to ensure consistency if we didn't have both shell script and
> | > C++ versions...
> | > 
> | > jwe
> | > 
> | 
> | building from the following tip
> | 
> | changeset:   9545:8670e55078fd
> | tag:         tip
> | user:        Jaroslav Hajek <highegg at gmail.com>
> | date:        Mon Aug 17 14:46:18 2009 +0200
> | summary:     allow constructing octave_value_list from size
> | 
> | build fails at build-octave.cc with the attached errors.
> | I guess all substitution variables should be prefixed with 
> | 'OCTAVE_CONF_' as in the attached changeset.
> | 
> | Furthermore, there is a '|' character where it should be a '+' character 
> | in line 254 in mkoctfile.cc.in -> see changeset.
> | 
> | 
> | However, linking liboctinterp.dll now again fails with the following error
> | Creating library file: 
> | liboctinterp.dll.a../libcruft/blas-xtra/xerbla.o:xerbla.f:(.text+0x50): 
> | undefined reference to `_gfortran_st_write'
> | ../libcruft/blas-xtra/xerbla.o:xerbla.f:(.text+0x67): undefined 
> | reference to `_gfortran_transfer_character'
> | ../libcruft/blas-xtra/xerbla.o:xerbla.f:(.text+0x7e): undefined 
> | reference to `_gfortran_transfer_integer'
> | ../libcruft/blas-xtra/xerbla.o:xerbla.f:(.text+0x86): undefined 
> | reference to `_gfortran_st_write_done'
> | 
> | Since xerbla.o is linked directly into liboctinterp.dll, $(FLIBS) is 
> | required in the link dependencies as
> | 
> | diff -r 87d36823eb0d src/Makefile.in
> | --- a/src/Makefile.in   Wed Aug 19 10:09:44 2009 +0200
> | +++ b/src/Makefile.in   Wed Aug 19 10:27:04 2009 +0200
> | @@ -331,7 +331,7 @@
> |     $(HDF5_LDFLAGS) $(HDF5_LIBS) $(Z_LDFLAGS) $(Z_LIBS) \
> |     $(OPENGL_LIBS) $(X11_LIBS) $(CARBON_LIBS) \
> |     $(READLINE_LIBS) \
> | -  $(LIBS)
> | +  $(FLIBS) $(LIBS)
> | 
> |   OCT_LINK_DEPS = $(RLD_FLAG) -L. $(LIBOCTINTERP) \
> |     -L../liboctave $(LIBOCTAVE) \
> 
> I made this change.
> 
> | The rest builds & links fine.
> 
> I added a ChangeLog entry and checked in your changeset.
> 

I did a fresh configure&build cycle and it builds&links successfully.
Excellent, thanks

benjamin

From bpabbott at mac.com  Wed Aug 26 20:52:06 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Wed, 26 Aug 2009 21:52:06 -0400
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A959959.3040707@gmx.net>
References: <4A8449ED.1090506@gmx.net> <4A845073.5010601@gmx.net>
	<4A847CEC.6090800@gmx.net> <19077.28862.827842.41629@segfault.lan>
	<4A868317.10203@gmx.net> <19081.34869.778915.594647@segfault.lan>
	<4A8A63BE.4090300@gmx.net> <19082.50054.994278.817764@segfault.lan>
	<4A8BB83A.4060408@gmx.net> <19093.22209.535838.360776@segfault.lan>
	<4A959959.3040707@gmx.net>
Message-ID: <77186FBD-A43A-48FD-979A-2C6D7BA39A5A@mac.com>


On Aug 26, 2009, at 4:21 PM, Benjamin Lindner wrote:

> John W. Eaton wrote:
>> On 19-Aug-2009, Benjamin Lindner wrote:
>> | John W. Eaton wrote:
>> | > On 18-Aug-2009, Benjamin Lindner wrote:
>> | > | > | John W. Eaton wrote:
>> | > | > On 15-Aug-2009, Benjamin Lindner wrote:
>> | > | > | > | > | Now for the undefined reference linker errors:
>> | > | > | > | > I checked in some additional changes.  I will deal  
>> with the mkoctfile
>> | > | > and octave-bug scripts/programs later, but is there  
>> anything that I
>> | > | > missed for building libcruft, liboctave, liboctinterp, and  
>> the .oct
>> | > | > files?
>> | > | > | > | | > | Aside from the pending octave-bug.cc and  
>> mkoctfile.cc changes,
>> | > | building and linking completes successfully for mingw32/gcc.
>> | > | > I checked in changes for octave-bug.cc.in and  
>> mkoctfile.cc.in so they
>> | > should build now.  Are there still problems?  BTW, this is why  
>> I think
>> | > we should eliminate the script versions of these files.  It  
>> would be
>> | > easier to ensure consistency if we didn't have both shell  
>> script and
>> | > C++ versions...
>> | > | > jwe
>> | > | | building from the following tip
>> | | changeset:   9545:8670e55078fd
>> | tag:         tip
>> | user:        Jaroslav Hajek <highegg at gmail.com>
>> | date:        Mon Aug 17 14:46:18 2009 +0200
>> | summary:     allow constructing octave_value_list from size
>> | | build fails at build-octave.cc with the attached errors.
>> | I guess all substitution variables should be prefixed with |  
>> 'OCTAVE_CONF_' as in the attached changeset.
>> | | Furthermore, there is a '|' character where it should be a '+'  
>> character | in line 254 in mkoctfile.cc.in -> see changeset.
>> | | | However, linking liboctinterp.dll now again fails with the  
>> following error
>> | Creating library file: | liboctinterp.dll.a../libcruft/blas-xtra/ 
>> xerbla.o:xerbla.f:(.text+0x50): | undefined reference to  
>> `_gfortran_st_write'
>> | ../libcruft/blas-xtra/xerbla.o:xerbla.f:(.text+0x67): undefined |  
>> reference to `_gfortran_transfer_character'
>> | ../libcruft/blas-xtra/xerbla.o:xerbla.f:(.text+0x7e): undefined |  
>> reference to `_gfortran_transfer_integer'
>> | ../libcruft/blas-xtra/xerbla.o:xerbla.f:(.text+0x86): undefined |  
>> reference to `_gfortran_st_write_done'
>> | | Since xerbla.o is linked directly into liboctinterp.dll, $ 
>> (FLIBS) is | required in the link dependencies as
>> | | diff -r 87d36823eb0d src/Makefile.in
>> | --- a/src/Makefile.in   Wed Aug 19 10:09:44 2009 +0200
>> | +++ b/src/Makefile.in   Wed Aug 19 10:27:04 2009 +0200
>> | @@ -331,7 +331,7 @@
>> |     $(HDF5_LDFLAGS) $(HDF5_LIBS) $(Z_LDFLAGS) $(Z_LIBS) \
>> |     $(OPENGL_LIBS) $(X11_LIBS) $(CARBON_LIBS) \
>> |     $(READLINE_LIBS) \
>> | -  $(LIBS)
>> | +  $(FLIBS) $(LIBS)
>> | |   OCT_LINK_DEPS = $(RLD_FLAG) -L. $(LIBOCTINTERP) \
>> |     -L../liboctave $(LIBOCTAVE) \
>> I made this change.
>> | The rest builds & links fine.
>> I added a ChangeLog entry and checked in your changeset.
>
> I did a fresh configure&build cycle and it builds&links successfully.
> Excellent, thanks
>
> benjamin

I'm now able to build on Mac OSX as well.

Thanks!
Ben



From tmacchant at yahoo.co.jp  Wed Aug 26 22:31:54 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Thu, 27 Aug 2009 12:31:54 +0900 (JST)
Subject: 3.2.3 RC1
In-Reply-To: <4A9590DC.3060904@gmx.net>
Message-ID: <20090827033155.19681.qmail@web3812.mail.bbt.yahoo.co.jp>

Please reflects about the discussion on README.MSVC
Also in the developmet branch.

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

--- "John W. Eaton" wrote: 

> On  3-Aug-2009, Tatsuro MATSUOKA wrote: 
> 
> | 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. 
> 
> Maybe it should be updated instead? 

Michael himself have been working for octave development branch by MSVC complier. 
Of course, if Michael will update README.MSVC, it will be desirable than be removed. 

> --- "John W. Eaton" wrote: 
> 
>> On  3-Aug-2009, Tatsuro MATSUOKA wrote: 
>> 
>> | 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. 
>> 
>> Maybe it should be updated instead? 
> 
> Michael himself have been working for octave development branch by MSVC complier. 
> Of course, if Michael will update README.MSVC, it will be desirable than be removed.

To be honest, I have no plan to update it. It's now unsupported and 
should be removed to avoid confusing users. 

Michael.

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

From tmacchant at yahoo.co.jp  Wed Aug 26 22:38:47 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Thu, 27 Aug 2009 12:38:47 +0900 (JST)
Subject: R: 3.2.3 RC1
In-Reply-To: <396697.65506.qm@web25506.mail.ukl.yahoo.com>
Message-ID: <20090827033847.17195.qmail@web3803.mail.bbt.yahoo.co.jp>

Hello Marco Atzeri 

Can you update README.Cygwin ?

http://www.nabble.com/README.MSVC-and-README.cygwin-(was-Re:-can-this-compile-on-vs2008-or-not)-tt24784219.html#a24784219

Regards

Tatsuro

--- Marco Atzeri <marco_atzeri at yahoo.it> wrote:

> --- Lun 24/8/09, Jaroslav Hajek <highegg at gmail.com> ha scritto:
> 
> > Da: Jaroslav Hajek <highegg at gmail.com>
> > Oggetto: 3.2.3 RC1
> > A: "octave maintainers list" <maintainers at octave.org>
> > Data: Luned?? 24 agosto 2009, 10:58
> > hi all,
> > 
> > I want to make 3.2.3 in the first half of September. The
> > 1st release
> > candidate tarballs for 3.2.3 are available at:
> > http://artax.karlin.mff.cuni.cz/~hajej2am/ulozna/octave/
> > 
> [cut]
> > 
> > In case your favorite patch is missing, now would be a good
> > time to mention it.
> > 
> > regards
> > 
> > -- 
> > RNDr. Jaroslav Hajek
> > computing expert & GNU Octave developer
> > Aeronautical Research and Test Institute (VZLU)
> > Prague, Czech Republic
> > url: www.highegg.matfyz.cz
> > 
> 
> Hi Jaroslav,
> it builds fine and pass the usual tests on cygwin
> 
> Regards
> Marco
> 
> 
> 
>       
> 
> 
> 


--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

From daniel.sebald at ieee.org  Thu Aug 27 01:04:21 2009
From: daniel.sebald at ieee.org (Daniel J Sebald)
Date: Thu, 27 Aug 2009 01:04:21 -0500
Subject: autoconf-2.64 required?
Message-ID: <4A9621E5.1010204@ieee.org>

> Autoconf 2.64 is really very new; though by the time Octave 3.4 will
> be released, it may already be widespread.
> However, in this case apparently it's just m4_ifblank and m4_ifnblank
> missing, so an easy remedy is to steal them out from autoconf 2.64 and
> define them ourselves if they're not there:
> http://hg.savannah.gnu.org/hgweb/octave/rev/691545147aca
> 
> this enables use of autoconf 2.63 for me.

Wait a second...

First, shouldn't a copyright notice be given if hunks of autoconf are moved into Octave?

Second, for years I've occassionally (well, more than occassionally) fallen behind in autoconf or some other tool and the only deference I got from the list was to "download the latest version of autoconf".  (autoconf is not that difficult to keep up to date.)  Now we start adding little hunks to work around this issue?  Avoiding using the new macro is fine, but pulling in patches seems bad practice.

If anything, an expiration date (i.e., a note/date saying remove this a year or two from now) should be put on that hunk of code so that someone can take it out when it is extraneous.

Dan


From daniel.sebald at ieee.org  Thu Aug 27 01:05:12 2009
From: daniel.sebald at ieee.org (Daniel J Sebald)
Date: Thu, 27 Aug 2009 01:05:12 -0500
Subject: overriding print.m pdf default terminal choices?
Message-ID: <4A962218.9090209@ieee.org>



> Hello list,
> 
> I wondered if it is possible to force print.m to use ghostscript for
> printing to pdf even if gnuplot provides a pdfcairo terminal?
> 
> I ask because the last available gnuplot for win32 does not include the
> patch which fixes the spurious-pages-in-pdf-output bug.
> So a command as
>   plot(0:0.1:10, sin(0:0.1:10), "@-"); print -dpdf test.pdf
> produces a three-page pdf.
> 
> I don't know when there will be a new gnuplot release or snapshot
> release but the do not happen very frequently.

Did you submit a bug report to the gnuplot development site, Benjamin?  The most active developer on gnuplot is very knowledgable in this subject and might be able to give a date when a fix is available.  He's more of a unix person, but I think he'd know how to deal with Windows and pdfcairo.

Dan


From highegg at gmail.com  Thu Aug 27 01:34:52 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 27 Aug 2009 08:34:52 +0200
Subject: autoconf-2.64 required?
In-Reply-To: <4A9621E5.1010204@ieee.org>
References: <4A9621E5.1010204@ieee.org>
Message-ID: <69d8d540908262334y74c451dv76a606775dda8335@mail.gmail.com>

On Thu, Aug 27, 2009 at 8:04 AM, Daniel J Sebald<daniel.sebald at ieee.org> wrote:
>> Autoconf 2.64 is really very new; though by the time Octave 3.4 will
>> be released, it may already be widespread.
>> However, in this case apparently it's just m4_ifblank and m4_ifnblank
>> missing, so an easy remedy is to steal them out from autoconf 2.64 and
>> define them ourselves if they're not there:
>> http://hg.savannah.gnu.org/hgweb/octave/rev/691545147aca
>>
>> this enables use of autoconf 2.63 for me.
>
> Wait a second...
>
> First, shouldn't a copyright notice be given if hunks of autoconf are moved
> into Octave?
>

Maybe. I don't think it's legally necessary (the copyright exists
whether stated or not), but probably a good practice, even in the case
of trivial few-liners. Note that I quoted Autoconf, however.

>
> Second, for years I've occassionally (well, more than occassionally) fallen
> behind in autoconf or some other tool and the only deference I got from the
> list was to "download the latest version of autoconf". ?(autoconf is not
> that difficult to keep up to date.) ?Now we start adding little hunks to
> work around this issue? ?Avoiding using the new macro is fine, but pulling
> in patches seems bad practice.
>

Here, this strips the requirement down from 2.64 to at least 2.61.
2.64 was released really recently (late July) and John stated he had
no intent to enforce 2.64. Since the only missing macros are trivial,
this seemed the best solution to me. But feel free to suggest a patch.

> If anything, an expiration date (i.e., a note/date saying remove this a year
> or two from now) should be put on that hunk of code so that someone can take
> it out when it is extraneous.
>

How would you estimate the date? I quoted that those are macros from
Autoconf 2.64; which seems sufficient to decide whether it is OK to
delete. A FIXME markup should probably be there, though.

regards

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


From daniel.sebald at ieee.org  Thu Aug 27 02:04:12 2009
From: daniel.sebald at ieee.org (Daniel J Sebald)
Date: Thu, 27 Aug 2009 02:04:12 -0500
Subject: autoconf-2.64 required?
In-Reply-To: <69d8d540908262334y74c451dv76a606775dda8335@mail.gmail.com>
References: <4A9621E5.1010204@ieee.org>
	<69d8d540908262334y74c451dv76a606775dda8335@mail.gmail.com>
Message-ID: <4A962FEC.6080103@ieee.org>

Jaroslav Hajek wrote:

> How would you estimate the date? I quoted that those are macros from
> Autoconf 2.64; which seems sufficient to decide whether it is OK to
> delete. A FIXME markup should probably be there, though.

That would be fine.  It wouldn't take someone too long to figure out why the code was added, but something like

FIXME: Remove when autoconf 2.64+ is commonplace, 14aug2009

above the comments would make it immediately clear the code can (and should) go.

Dan

From marco_atzeri at yahoo.it  Thu Aug 27 02:13:55 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Thu, 27 Aug 2009 07:13:55 +0000 (GMT)
Subject: R: 3.2.3 RC1
In-Reply-To: <20090827033847.17195.qmail@web3803.mail.bbt.yahoo.co.jp>
Message-ID: <112893.81494.qm@web25508.mail.ukl.yahoo.com>

--- Gio 27/8/09, Tatsuro MATSUOKA <tmacchant at yahoo.co.jp> ha scritto:

> Da: Tatsuro MATSUOKA <tmacchant at yahoo.co.jp>
> Oggetto: Re: R: 3.2.3 RC1
> A: "Marco Atzeri" <marco_atzeri at yahoo.it>, "octave maintainers list" <maintainers at octave.org>
> Cc: "John W. Eaton" <jwe at octave.org>, "Jaroslav Hajek" <highegg at gmail.com>
> Data: Gioved? 27 agosto 2009, 05:38
> Hello Marco Atzeri 
> 
> Can you update README.Cygwin ?
> 
> http://www.nabble.com/README.MSVC-and-README.cygwin-(was-Re:-can-this-compile-on-vs2008-or-not)-tt24784219.html#a24784219
> 
> Regards
> 
> Tatsuro

Hi Tatsuro,
as you already highlighted I already proposed a change in
 
https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-June/012476.html

that was not merged, and I didn't follow up the issue.

Or are you asking for something more ?

Regards
Marco



      



From highegg at gmail.com  Thu Aug 27 02:18:20 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 27 Aug 2009 09:18:20 +0200
Subject: autoconf-2.64 required?
In-Reply-To: <4A962FEC.6080103@ieee.org>
References: <4A9621E5.1010204@ieee.org>
	<69d8d540908262334y74c451dv76a606775dda8335@mail.gmail.com>
	<4A962FEC.6080103@ieee.org>
Message-ID: <69d8d540908270018t306286b7laf187b89baf50861@mail.gmail.com>

On Thu, Aug 27, 2009 at 9:04 AM, Daniel J Sebald<daniel.sebald at ieee.org> wrote:
> Jaroslav Hajek wrote:
>
>> How would you estimate the date? I quoted that those are macros from
>> Autoconf 2.64; which seems sufficient to decide whether it is OK to
>> delete. A FIXME markup should probably be there, though.
>
> That would be fine. ?It wouldn't take someone too long to figure out why the
> code was added, but something like
>
> FIXME: Remove when autoconf 2.64+ is commonplace, 14aug2009
>
> above the comments would make it immediately clear the code can (and should)
> go.
>
> Dan
>

I ended up with this:
http://hg.savannah.gnu.org/hgweb/octave/rev/b03062e16c6f


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


From lindnerben at gmx.net  Thu Aug 27 03:31:13 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Thu, 27 Aug 2009 10:31:13 +0200
Subject: overriding print.m pdf default terminal choices?
In-Reply-To: <4A962218.9090209@ieee.org>
References: <4A962218.9090209@ieee.org>
Message-ID: <20090827083113.229870@gmx.net>

> 
> 
> > Hello list,
> > 
> > I wondered if it is possible to force print.m to use ghostscript for
> > printing to pdf even if gnuplot provides a pdfcairo terminal?
> > 
> > I ask because the last available gnuplot for win32 does not include the
> > patch which fixes the spurious-pages-in-pdf-output bug.
> > So a command as
> >   plot(0:0.1:10, sin(0:0.1:10), "@-"); print -dpdf test.pdf
> > produces a three-page pdf.
> > 
> > I don't know when there will be a new gnuplot release or snapshot
> > release but the do not happen very frequently.
> 
> Did you submit a bug report to the gnuplot development site, Benjamin? 
> The most active developer on gnuplot is very knowledgable in this subject and
> might be able to give a date when a fix is available.  He's more of a unix
> person, but I think he'd know how to deal with Windows and pdfcairo.
> 

No I didn't submit a bug report, as the issue came up at the time Ben implemented the cairo terminal support in print.m and we know that this issue has been fixed in CVS (as the gnuplot developers told us then).

I must apologise, there are newer snapshots avilable which fix this particular bug, but they did not list it on gnupot's homepage and did not announce it on the mailing list, you have to actually read the directory listsings, which I did not do thoroughly, so I shamefully missed it. 

So this particular bug is already fixed, and there are snapshots available that include it. My fault, I didn't realize it.

benjamin


-- 
GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

From tmacchant at yahoo.co.jp  Thu Aug 27 03:35:27 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Thu, 27 Aug 2009 17:35:27 +0900 (JST)
Subject: R: 3.2.3 RC1
In-Reply-To: <112893.81494.qm@web25508.mail.ukl.yahoo.com>
Message-ID: <20090827083527.8510.qmail@web3804.mail.bbt.yahoo.co.jp>

Hello

--- Marco Atzeri  wrote:

> --- Gio 27/8/09, Tatsuro MATSUOKA <tmacchant at yahoo.co.jp> ha scritto:
> 
> > Da: Tatsuro MATSUOKA <tmacchant at yahoo.co.jp>
> > Oggetto: Re: R: 3.2.3 RC1
> > A: "Marco Atzeri" <marco_atzeri at yahoo.it>, "octave maintainers list" <maintainers at octave.org>
> > Cc: "John W. Eaton" <jwe at octave.org>, "Jaroslav Hajek" <highegg at gmail.com>
> > Data: Gioved?? 27 agosto 2009, 05:38
> > Hello Marco Atzeri 
> > 
> > Can you update README.Cygwin ?
> > 
> >
>
http://www.nabble.com/README.MSVC-and-README.cygwin-(was-Re:-can-this-compile-on-vs2008-or-not)-tt24784219.html#a24784219
> > 
> > Regards
> > 
> > Tatsuro
> 
> Hi Tatsuro,
> as you already highlighted I already proposed a change in
>  
> https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-June/012476.html
> 
> that was not merged, and I didn't follow up the issue.
> 
> Or are you asking for something more ?
Sorry
I have?overlooked the above.

Please update README.cywin for3.2.x and development branch.

Regards

Tatsuro

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

From highegg at gmail.com  Thu Aug 27 05:09:18 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 27 Aug 2009 12:09:18 +0200
Subject: complex comparison ops vs. Matlab
Message-ID: <69d8d540908270309x652b2cebp804714d4c27d887b@mail.gmail.com>

hi all,

by this changeset:
http://hg.savannah.gnu.org/hgweb/octave/rev/7dafdb8b062f

I finished my project of refactoring dense binary operator
implementations in liboctave. The approach is similar to what I've
done before for reduction operations:
The innermost loops on pointer arrays are encapsulated as overloaded
template functions, providing good performance; appliers are provided
that take array arguments and return array, applying a given loop.
Using this machinery, the (MS|SM|MM|NDS|SND|NDND)_(BIN|CMP|BOOL)_OP(S)
macros in mx-op-defs were changed into trivial one-line wrappers, and
the *OPS1, *OPS2 alternatives are gone.

The total of mx-op-defs.h, mx-inlines.cc and MArray-defs.h is now 200
lines shorter than 3.2.x, and that also includes the new stuff for
in-place binary ops. It will be even more if also the VS_,SV_,and
VV_OPS are replaced (which was not immediately possible because
*Vector classes are not constructible from dim_vector).

The new implementation also probably creates less object code; as the
loop bodies are passed by pointer and thus can be shared amongst the
matrix and ndarray wrappers. I'm not sure whether the GNU linker
actually merges the instances, but it certainly has the possibility
(the last change cut down liboctave size by 330KB. It's still 400KB
larger than 3.2.x, but that's not fair comparison because there's a
lot of new stuff since 3.2.x).

The logical binary ops were sped up significantly by this change,
although the code is logically equal - probably GCC was not powerful
enough to optimize the previous code:

n = 4e3;
a = rand (n) < 0.5;
b = rand (n) < 0.5;
tic; a & b; toc
tic; a | b; toc
tic; a & !b; toc
tic; a | !b; toc
tic; !a | b; toc
tic; !a & b; toc

GCC 4.3.1, -O3 -march=native, Core 2 Duo @ 2.83 GHz:

3.2.x:

Elapsed time is 0.0800021 seconds.
Elapsed time is 0.0852289 seconds.
Elapsed time is 0.080343 seconds.
Elapsed time is 0.0791581 seconds.
Elapsed time is 0.0736232 seconds.
Elapsed time is 0.074126 seconds.

tip:

Elapsed time is 0.018801 seconds.
Elapsed time is 0.0197818 seconds.
Elapsed time is 0.026242 seconds.
Elapsed time is 0.020916 seconds.
Elapsed time is 0.0185721 seconds.
Elapsed time is 0.0178182 seconds.

One important point is that I changed the way comparing complex number works.
I think that Matlab compares only real parts of complex arrays when
involved in comparison operators; at least the previous Octave
implementation did so.
OTOH, Matlab defines a rigorous ordering on complex numbers as the
lexicographical ordering of [abs(z), arg(z)], which is used in sort,
min and max, and is shared with Octave.
I couldn't find the Matlab behavior documented anywhere, so I presume
it's a relic of the past and probably stemming from the fact that
Matlab is widely known to store the real and imaginary parts of arrays
separately - so it's the lazy do-nothing approach. However, it
simplifies the implementation significantly to consider one universal
ordering of complex numbers (defined in oct-cmplx.h) that gets
automatically used everywhere. As a result, Octave now uses the strict
abs/arg ordering of complex numbers for comparing complex arrays:

octave:1> 1+5i > 2+2i
ans =  1
octave:2> 1+i > 1-i
ans =  1

This means that various "obvious" invariants, such as

octave:3> a = sort (rand(100, 1) + i*rand(100,1)); all (a(1:99) <= a(2:100))
ans =  1
octave:4> a = rand(100, 1) + i*rand(100,1); all (a <= max (a(:)))
ans =  1

now hold for complex arrays as well (previously, this was not true).
Personally, I think this new behavior is more logical and consistent
and I vote for a change. I suppose few code depends on this and broken
scripts can be trivially fixed by wrapping operands in real () (which
I'd suggest anyway).

If I'm outvoted on this, I'd still like to keep that Matlab
compatibility mess out of liboctave, so I'll probably add a hack into
the interpreter to apply "real" to the operands first. It could also
be made conditional (for instance, keep the old behavior in the
braindamage mode), but I think John already said he doesn't like
global variables fundamentally influencing code flow.

Opinions? Comments?

regards

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

From highegg at gmail.com  Thu Aug 27 06:02:13 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Thu, 27 Aug 2009 13:02:13 +0200
Subject: [changeset] GraphicsMagick++ configuration
In-Reply-To: <4A93D3FC.4080203@acc.umu.se>
References: <4A7AEEF4.2070101@acc.umu.se>
	<19066.62968.137520.390478@segfault.lan> <4A7B3868.9020001@acc.umu.se>
	<19067.14844.220747.257229@segfault.lan>
	<20090816210909.GA15975@atlan> <20090825055536.GA7737@atlan>
	<4A93D1D0.9040500@acc.umu.se> <4A93D3FC.4080203@acc.umu.se>
Message-ID: <69d8d540908270402k2b5635a7gd9af02fd7f8161ca@mail.gmail.com>

On Tue, Aug 25, 2009 at 2:07 PM, David Grundberg<individ at acc.umu.se> wrote:
> David Grundberg wrote:
>>
>> Thomas Weber wrote:
>>>
>>> On Sun, Aug 16, 2009 at 11:09:09PM +0200, Thomas Weber wrote:
>>>
>>>>
>>>> On Thu, Aug 06, 2009 at 04:15:56PM -0400, John W. Eaton wrote:
>>>>
>>>>>
>>>>> On ?6-Aug-2009, David Grundberg wrote:
>>>>>
>>>>> | John W. Eaton skrev:
>>>>> | > On ?6-Aug-2009, David Grundberg wrote:
>>>>> | >
>>>>> | > | I've rearranged the GraphicsMagick++ configuration. I had some
>>>>> trouble | > | since I'm running a custom GraphicsMagick installation. The
>>>>> Octave build | > | system was running GraphicsMagick++-config during make.
>>>>> It was missing | > | ldflags and using only the basename of the config
>>>>> executable (as opposed | > | to a full path).
>>>>> | > | | > | I've changed it so that GraphicsMagick++-config is only run
>>>>> in the | > | configure script. Also introduced MAGICK_CONFIG as a precious
>>>>> variable.
>>>>> | >
>>>>> | > I removed --ldflags to fix the following mysterious problem on my
>>>>> | > system:
>>>>> | >
>>>>> | >
>>>>> https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-July/012879.html
>>>>> | >
>>>>> | > So I don't think I can put it back without breaking __magick_read__
>>>>> | > again, at least for me and other Debian users.
>>>>> | >
>>>>> | > What are -Wl,-z,relro and -pie doing in the ldflags anyway? ?Are
>>>>> those
>>>>> | > arguments not present on your system? ?Maybe they are present on
>>>>> mine
>>>>> | > because of the way Debian builds the graphics magick library
>>>>> package?
>>>>> | > Perhaps these flags make sense for creating the graphics magick
>>>>> | > library itself, but I can't see any reason for them to be required
>>>>> to
>>>>> | > link the graphics magick library with __magick_read__.oct.
>>>>> | >
>>>>> | > jwe
>>>>> | > ? | So that's why --ldflags was taken away! I don't have that
>>>>> problem. This | is the output from my config (where I'm building):
>>>>> | | $ |
>>>>> octave-patching/dependencies/graphicsmagick-install/bin/GraphicsMagick++-config
>>>>> | --ldflags --libs
>>>>> |
>>>>> -L/Home/staff/davidg/octave-patching/dependencies/graphicsmagick-install/lib
>>>>> | -L/usr/lib -L/usr/lib
>>>>> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper
>>>>> | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm |
>>>>> -lgomp -lpthread
>>>>> | | My ubuntu 9.04 box says this about the managed package (haven't
>>>>> tried | building against it):
>>>>> | david at lack:~$ GraphicsMagick++-config --ldflags --libs
>>>>> | -L/usr/lib -Wl,-Bsymbolic-functions -L/usr/lib/X11 -L/usr/lib
>>>>> -L/usr/lib
>>>>> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper
>>>>> | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm |
>>>>> -lpthread
>>>>>
>>>>> So what should we do about this?
>>>>
>>>> These are different versions. The Ubuntu version is 1.1.11-something,
>>>> your Debian versions is 1.3.5-something.
>>>>
>>>>
>>>>>
>>>>> around it by filtering out everything except -L options from the
>>>>> --ldflags output, but I'd rather see it fixed in graphics magick.
>>>>> What should graphics magick really be storing in the config script
>>>>> for --ldflags? ?Should options like -pie and -Wl,-z,relro really
>>>>> appear there? ?Or is this just a Debian packaging problem?
>>>>>
>>>>
>>>> The Debian packaging adds the -pie and -Wl options when building
>>>> GraphicsMagick to the LDFLAGS. GraphicsMagick then copies LDFLAGS into
>>>> its
>>>> --ldflags output. Looking at Ubuntu's build logs, the same is already
>>>> happening with newer versions of graphicsmagick.
>>>>
>>>> I'll ask the Debian maintainer of GraphicsMagick about it.
>>>>
>>>
>>> Okay, his answer is below. Short version: we should go we with
>>> pkg-config.
>>>
>>>
>>> ============================================================================
>>> Historically, the output of the *Magick*config scripts has been
>>> documented as
>>> the list of compiler/linker options *Magick was built with. This makes
>>> sense
>>> when build additional modules, but it's rather nonsensical for anything
>>> that
>>> just wants to link the C or C++ bindings. I recommend to use pkg-config
>>> for
>>> these kinds of applications instead. The hardening options aren't
>>> included
>>> there.
>>>
>>> ============================================================================
>>>
>>> ? ?Thomas
>>>
>>
>> Thanks a lot for your help!
>>
>> I made a new changeset, attached to this mail.
>>
>> At first I tried the pkg-config setup and was disappointed to see (some
>> ubuntu):
>>
>> $ pkg-config GraphicsMagick++ --libs
>> -Wl,-Bsymbolic-functions -lGraphicsMagick++ -lGraphicsMagick $ pkg-config
>> GraphicsMagick++ --cflags
>> -I/usr/include/GraphicsMagick
>> But then I discovered the --libs-only-l/L arguments (didn't know about
>> these):
>>
>> $ pkg-config GraphicsMagick++ --libs-only-L
>>
>> $ pkg-config GraphicsMagick++ --libs-only-l
>> -lGraphicsMagick++ -lGraphicsMagick
>>
>> Nice.
>>
>> David
>
> (responding to self)
>
> Ooops. An invalid email address sneaked into the ChangeLog. Fixed it. Sorry
> for the noise.
>

I applied this, updating also src/oct-conf.h.in and src/toplev.cc,
which was necessary.

regards


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


From individ at acc.umu.se  Thu Aug 27 07:15:36 2009
From: individ at acc.umu.se (David Grundberg)
Date: Thu, 27 Aug 2009 14:15:36 +0200
Subject: [changeset] GraphicsMagick++ configuration
In-Reply-To: <69d8d540908270402k2b5635a7gd9af02fd7f8161ca@mail.gmail.com>
References: <4A7AEEF4.2070101@acc.umu.se>	
	<19066.62968.137520.390478@segfault.lan>
	<4A7B3868.9020001@acc.umu.se>	
	<19067.14844.220747.257229@segfault.lan>	
	<20090816210909.GA15975@atlan> <20090825055536.GA7737@atlan>	
	<4A93D1D0.9040500@acc.umu.se> <4A93D3FC.4080203@acc.umu.se>
	<69d8d540908270402k2b5635a7gd9af02fd7f8161ca@mail.gmail.com>
Message-ID: <4A9678E8.9010409@acc.umu.se>

Jaroslav Hajek wrote:
> On Tue, Aug 25, 2009 at 2:07 PM, David Grundberg<individ at acc.umu.se> wrote:
>   
>> David Grundberg wrote:
>>     
>>> Thomas Weber wrote:
>>>       
>>>> On Sun, Aug 16, 2009 at 11:09:09PM +0200, Thomas Weber wrote:
>>>>
>>>>         
>>>>> On Thu, Aug 06, 2009 at 04:15:56PM -0400, John W. Eaton wrote:
>>>>>
>>>>>           
>>>>>> On  6-Aug-2009, David Grundberg wrote:
>>>>>>
>>>>>> | John W. Eaton skrev:
>>>>>> | > On  6-Aug-2009, David Grundberg wrote:
>>>>>> | >
>>>>>> | > | I've rearranged the GraphicsMagick++ configuration. I had some
>>>>>> trouble | > | since I'm running a custom GraphicsMagick installation. The
>>>>>> Octave build | > | system was running GraphicsMagick++-config during make.
>>>>>> It was missing | > | ldflags and using only the basename of the config
>>>>>> executable (as opposed | > | to a full path).
>>>>>> | > | | > | I've changed it so that GraphicsMagick++-config is only run
>>>>>> in the | > | configure script. Also introduced MAGICK_CONFIG as a precious
>>>>>> variable.
>>>>>> | >
>>>>>> | > I removed --ldflags to fix the following mysterious problem on my
>>>>>> | > system:
>>>>>> | >
>>>>>> | >
>>>>>> https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-July/012879.html
>>>>>> | >
>>>>>> | > So I don't think I can put it back without breaking __magick_read__
>>>>>> | > again, at least for me and other Debian users.
>>>>>> | >
>>>>>> | > What are -Wl,-z,relro and -pie doing in the ldflags anyway?  Are
>>>>>> those
>>>>>> | > arguments not present on your system?  Maybe they are present on
>>>>>> mine
>>>>>> | > because of the way Debian builds the graphics magick library
>>>>>> package?
>>>>>> | > Perhaps these flags make sense for creating the graphics magick
>>>>>> | > library itself, but I can't see any reason for them to be required
>>>>>> to
>>>>>> | > link the graphics magick library with __magick_read__.oct.
>>>>>> | >
>>>>>> | > jwe
>>>>>> | >   | So that's why --ldflags was taken away! I don't have that
>>>>>> problem. This | is the output from my config (where I'm building):
>>>>>> | | $ |
>>>>>> octave-patching/dependencies/graphicsmagick-install/bin/GraphicsMagick++-config
>>>>>> | --ldflags --libs
>>>>>> |
>>>>>> -L/Home/staff/davidg/octave-patching/dependencies/graphicsmagick-install/lib
>>>>>> | -L/usr/lib -L/usr/lib
>>>>>> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper
>>>>>> | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm |
>>>>>> -lgomp -lpthread
>>>>>> | | My ubuntu 9.04 box says this about the managed package (haven't
>>>>>> tried | building against it):
>>>>>> | david at lack:~$ GraphicsMagick++-config --ldflags --libs
>>>>>> | -L/usr/lib -Wl,-Bsymbolic-functions -L/usr/lib/X11 -L/usr/lib
>>>>>> -L/usr/lib
>>>>>> | -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype -ljasper
>>>>>> | -ljpeg -lpng -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm |
>>>>>> -lpthread
>>>>>>
>>>>>> So what should we do about this?
>>>>>>             
>>>>> These are different versions. The Ubuntu version is 1.1.11-something,
>>>>> your Debian versions is 1.3.5-something.
>>>>>
>>>>>
>>>>>           
>>>>>> around it by filtering out everything except -L options from the
>>>>>> --ldflags output, but I'd rather see it fixed in graphics magick.
>>>>>> What should graphics magick really be storing in the config script
>>>>>> for --ldflags?  Should options like -pie and -Wl,-z,relro really
>>>>>> appear there?  Or is this just a Debian packaging problem?
>>>>>>
>>>>>>             
>>>>> The Debian packaging adds the -pie and -Wl options when building
>>>>> GraphicsMagick to the LDFLAGS. GraphicsMagick then copies LDFLAGS into
>>>>> its
>>>>> --ldflags output. Looking at Ubuntu's build logs, the same is already
>>>>> happening with newer versions of graphicsmagick.
>>>>>
>>>>> I'll ask the Debian maintainer of GraphicsMagick about it.
>>>>>
>>>>>           
>>>> Okay, his answer is below. Short version: we should go we with
>>>> pkg-config.
>>>>
>>>>
>>>> ============================================================================
>>>> Historically, the output of the *Magick*config scripts has been
>>>> documented as
>>>> the list of compiler/linker options *Magick was built with. This makes
>>>> sense
>>>> when build additional modules, but it's rather nonsensical for anything
>>>> that
>>>> just wants to link the C or C++ bindings. I recommend to use pkg-config
>>>> for
>>>> these kinds of applications instead. The hardening options aren't
>>>> included
>>>> there.
>>>>
>>>> ============================================================================
>>>>
>>>>    Thomas
>>>>
>>>>         
>>> Thanks a lot for your help!
>>>
>>> I made a new changeset, attached to this mail.
>>>
>>> At first I tried the pkg-config setup and was disappointed to see (some
>>> ubuntu):
>>>
>>> $ pkg-config GraphicsMagick++ --libs
>>> -Wl,-Bsymbolic-functions -lGraphicsMagick++ -lGraphicsMagick $ pkg-config
>>> GraphicsMagick++ --cflags
>>> -I/usr/include/GraphicsMagick
>>> But then I discovered the --libs-only-l/L arguments (didn't know about
>>> these):
>>>
>>> $ pkg-config GraphicsMagick++ --libs-only-L
>>>
>>> $ pkg-config GraphicsMagick++ --libs-only-l
>>> -lGraphicsMagick++ -lGraphicsMagick
>>>
>>> Nice.
>>>
>>> David
>>>       
>> (responding to self)
>>
>> Ooops. An invalid email address sneaked into the ChangeLog. Fixed it. Sorry
>> for the noise.
>>
>>     
>
> I applied this, updating also src/oct-conf.h.in and src/toplev.cc,
> which was necessary.
>
> regards
>
>
>   

Yes, I saw that you did so.

Thanks,
David

From Thomas.Treichl at gmx.net  Thu Aug 27 14:17:16 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Thu, 27 Aug 2009 21:17:16 +0200
Subject: [changeset] GraphicsMagick++ configuration
In-Reply-To: <4A9678E8.9010409@acc.umu.se>
References: <4A7AEEF4.2070101@acc.umu.se>		<19066.62968.137520.390478@segfault.lan>	<4A7B3868.9020001@acc.umu.se>		<19067.14844.220747.257229@segfault.lan>		<20090816210909.GA15975@atlan>
	<20090825055536.GA7737@atlan>		<4A93D1D0.9040500@acc.umu.se>
	<4A93D3FC.4080203@acc.umu.se>	<69d8d540908270402k2b5635a7gd9af02fd7f8161ca@mail.gmail.com>
	<4A9678E8.9010409@acc.umu.se>
Message-ID: <4A96DBBC.1030201@gmx.net>

David Grundberg schrieb:
> Jaroslav Hajek wrote:
>> I applied this, updating also src/oct-conf.h.in and src/toplev.cc,
>> which was necessary.
>>
>> regards
> 
> Yes, I saw that you did so.
> 
> Thanks,
> David

That change causes a failing GraphicsMagick++ test for me. I changed

   CPPFLAGS="$CPPFLAGS $MAGICK_CPPFLAGS"
   LDFLAGS="$LIBS $MAGICK_LDFLAGS"
   LIBS="$LIBS $MAGICK_LIBS"

(cf. LDFLAGS line) to

   CPPFLAGS="$CPPFLAGS $MAGICK_CPPFLAGS"
   LDFLAGS="$LDFLAGS $MAGICK_LDFLAGS"
   LIBS="$LIBS $MAGICK_LIBS"

then it worked for me again. If this is the right thing to do then can you 
please make such a change? Thanks,

   Thomas

From jwe at octave.org  Thu Aug 27 14:50:11 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 27 Aug 2009 15:50:11 -0400
Subject: [changeset] GraphicsMagick++ configuration
In-Reply-To: <4A96DBBC.1030201@gmx.net>
References: <4A7AEEF4.2070101@acc.umu.se>
	<19066.62968.137520.390478@segfault.lan>
	<4A7B3868.9020001@acc.umu.se>
	<19067.14844.220747.257229@segfault.lan>
	<20090816210909.GA15975@atlan> <20090825055536.GA7737@atlan>
	<4A93D1D0.9040500@acc.umu.se> <4A93D3FC.4080203@acc.umu.se>
	<69d8d540908270402k2b5635a7gd9af02fd7f8161ca@mail.gmail.com>
	<4A9678E8.9010409@acc.umu.se> <4A96DBBC.1030201@gmx.net>
Message-ID: <19094.58227.727125.934346@segfault.lan>

On 27-Aug-2009, Thomas Treichl wrote:

| David Grundberg schrieb:
| > Jaroslav Hajek wrote:
| >> I applied this, updating also src/oct-conf.h.in and src/toplev.cc,
| >> which was necessary.
| >>
| >> regards
| > 
| > Yes, I saw that you did so.
| > 
| > Thanks,
| > David
| 
| That change causes a failing GraphicsMagick++ test for me. I changed
| 
|    CPPFLAGS="$CPPFLAGS $MAGICK_CPPFLAGS"
|    LDFLAGS="$LIBS $MAGICK_LDFLAGS"
|    LIBS="$LIBS $MAGICK_LIBS"
| 
| (cf. LDFLAGS line) to
| 
|    CPPFLAGS="$CPPFLAGS $MAGICK_CPPFLAGS"
|    LDFLAGS="$LDFLAGS $MAGICK_LDFLAGS"
|    LIBS="$LIBS $MAGICK_LIBS"
| 
| then it worked for me again. If this is the right thing to do then can you 
| please make such a change? Thanks,

In the configure script, I would not modify LDFLAGS, but instead just
do

  save_LIBS="$LIBS"
  LIBS="$MAGICK_LDFLAGS $MAGICK_LIBS $LIBS"

  ...

  LIBS="$save_LIBS"

I checked in the following change.

  http://hg.savannah.gnu.org/hgweb/octave/rev/8dc1531e2149

Thanks,

jwe

From Thomas.Treichl at gmx.net  Thu Aug 27 14:55:14 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Thu, 27 Aug 2009 21:55:14 +0200
Subject: [changeset] GraphicsMagick++ configuration
In-Reply-To: <19094.58227.727125.934346@segfault.lan>
References: <4A7AEEF4.2070101@acc.umu.se>	<19066.62968.137520.390478@segfault.lan>	<4A7B3868.9020001@acc.umu.se>	<19067.14844.220747.257229@segfault.lan>	<20090816210909.GA15975@atlan>	<20090825055536.GA7737@atlan>	<4A93D1D0.9040500@acc.umu.se>	<4A93D3FC.4080203@acc.umu.se>	<69d8d540908270402k2b5635a7gd9af02fd7f8161ca@mail.gmail.com>	<4A9678E8.9010409@acc.umu.se>	<4A96DBBC.1030201@gmx.net>
	<19094.58227.727125.934346@segfault.lan>
Message-ID: <4A96E4A2.3030006@gmx.net>

John W. Eaton schrieb:
> On 27-Aug-2009, Thomas Treichl wrote:
> | David Grundberg schrieb:
> | > Jaroslav Hajek wrote:
> | >> I applied this, updating also src/oct-conf.h.in and src/toplev.cc,
> | >> which was necessary.
> | >>
> | >> regards
> | > 
> | > Yes, I saw that you did so.
> | > 
> | > Thanks,
> | > David
> | 
> | That change causes a failing GraphicsMagick++ test for me. I changed
> | 
> |    CPPFLAGS="$CPPFLAGS $MAGICK_CPPFLAGS"
> |    LDFLAGS="$LIBS $MAGICK_LDFLAGS"
> |    LIBS="$LIBS $MAGICK_LIBS"
> | 
> | (cf. LDFLAGS line) to
> | 
> |    CPPFLAGS="$CPPFLAGS $MAGICK_CPPFLAGS"
> |    LDFLAGS="$LDFLAGS $MAGICK_LDFLAGS"
> |    LIBS="$LIBS $MAGICK_LIBS"
> | 
> | then it worked for me again. If this is the right thing to do then can you 
> | please make such a change? Thanks,
> 
> In the configure script, I would not modify LDFLAGS, but instead just
> do
> 
>   save_LIBS="$LIBS"
>   LIBS="$MAGICK_LDFLAGS $MAGICK_LIBS $LIBS"
> 
>   ...
> 
>   LIBS="$save_LIBS"
> 
> I checked in the following change.
> 
>   http://hg.savannah.gnu.org/hgweb/octave/rev/8dc1531e2149

Works perfectly for me, thanks,

   Thomas

From jwe at octave.org  Thu Aug 27 15:02:12 2009
From: jwe at octave.org (John W. Eaton)
Date: Thu, 27 Aug 2009 16:02:12 -0400
Subject: complex comparison ops vs. Matlab
In-Reply-To: <69d8d540908270309x652b2cebp804714d4c27d887b@mail.gmail.com>
References: <69d8d540908270309x652b2cebp804714d4c27d887b@mail.gmail.com>
Message-ID: <19094.58948.770534.882138@segfault.lan>

On 27-Aug-2009, Jaroslav Hajek wrote:

| by this changeset:
| http://hg.savannah.gnu.org/hgweb/octave/rev/7dafdb8b062f
| 
| I finished my project of refactoring dense binary operator
| implementations in liboctave.

Thanks for taking on this project.

| One important point is that I changed the way comparing complex number works.
| I think that Matlab compares only real parts of complex arrays when
| involved in comparison operators; at least the previous Octave
| implementation did so.

Yes.  Not that it makes much sense (at least to me) but Matlab is
documented to work this way.

| OTOH, Matlab defines a rigorous ordering on complex numbers as the
| lexicographical ordering of [abs(z), arg(z)], which is used in sort,
| min and max, and is shared with Octave.
| I couldn't find the Matlab behavior documented anywhere,

Look at the alphabetical list of the documentation for Matlab
functions on the web.  Near the top of the page for relational
operators, it says

  The operators <, >, <=, and >= use only the real part of their
  operands for the comparison. The operators == and ~= test real and
  imaginary parts.

| However, it
| simplifies the implementation significantly to consider one universal
| ordering of complex numbers (defined in oct-cmplx.h) that gets
| automatically used everywhere.

Yes, I think it makes much more sense to have one definition for the
ordering.  Can anyone think of a case where it is really useful to
compare complex numbers using only the real part?good reason, then

| now hold for complex arrays as well (previously, this was not true).
| Personally, I think this new behavior is more logical and consistent
| and I vote for a change. I suppose few code depends on this and broken
| scripts can be trivially fixed by wrapping operands in real () (which
| I'd suggest anyway).

Yes, I agree that if you want to compare complex numbers by real part
only, then you should say so explicitly.

| If I'm outvoted on this, I'd still like to keep that Matlab
| compatibility mess out of liboctave, so I'll probably add a hack into
| the interpreter to apply "real" to the operands first. It could also
| be made conditional (for instance, keep the old behavior in the
| braindamage mode), but I think John already said he doesn't like
| global variables fundamentally influencing code flow.

What about an optional "matlab-incompatibility" warning?  Especially
since we are changing the behavior of Octave too, and this is the kind
of change that will otherwise silently change the results obtained
from of previously "working" code.

jwe

From octave at phaselockedsystems.com  Thu Aug 27 15:26:14 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Thu, 27 Aug 2009 13:26:14 -0700
Subject: octave panic calling builtin('subsref', ...)
In-Reply-To: <69d8d540908270718u214f3039s52f4c0c3e7999e2@mail.gmail.com>
References: <58373.91.43.109.157.1251370445.squirrel@webmail.tf.uni-kiel.de>	
	<69d8d540908270507i6c47de37q83f947d69676ea63@mail.gmail.com>
	<69d8d540908270718u214f3039s52f4c0c3e7999e2@mail.gmail.com>
Message-ID: <4A96EBE6.4040300@phaselockedsystems.com>

An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090827/e3efa4c0/attachment.html 

From daniel.sebald at ieee.org  Thu Aug 27 23:37:34 2009
From: daniel.sebald at ieee.org (Daniel J Sebald)
Date: Thu, 27 Aug 2009 23:37:34 -0500
Subject: autoconf-2.64 required?
In-Reply-To: <69d8d540908270018t306286b7laf187b89baf50861@mail.gmail.com>
References: <4A9621E5.1010204@ieee.org>	
	<69d8d540908262334y74c451dv76a606775dda8335@mail.gmail.com>	
	<4A962FEC.6080103@ieee.org>
	<69d8d540908270018t306286b7laf187b89baf50861@mail.gmail.com>
Message-ID: <4A975F0E.5090809@ieee.org>

Jaroslav Hajek wrote:

> I ended up with this:
> http://hg.savannah.gnu.org/hgweb/octave/rev/b03062e16c6f

Looks good.

Dan

From highegg at gmail.com  Fri Aug 28 00:54:31 2009
From: highegg at gmail.com (Jaroslav Hajek)
Date: Fri, 28 Aug 2009 07:54:31 +0200
Subject: complex comparison ops vs. Matlab
In-Reply-To: <19094.58948.770534.882138@segfault.lan>
References: <69d8d540908270309x652b2cebp804714d4c27d887b@mail.gmail.com>
	<19094.58948.770534.882138@segfault.lan>
Message-ID: <69d8d540908272254t4ed75fact2ffe0f193ebf3952@mail.gmail.com>

On Thu, Aug 27, 2009 at 10:02 PM, John W. Eaton<jwe at octave.org> wrote:
> On 27-Aug-2009, Jaroslav Hajek wrote:
>
> | by this changeset:
> | http://hg.savannah.gnu.org/hgweb/octave/rev/7dafdb8b062f
> |
> | I finished my project of refactoring dense binary operator
> | implementations in liboctave.
>
> Thanks for taking on this project.
>
> | One important point is that I changed the way comparing complex number works.
> | I think that Matlab compares only real parts of complex arrays when
> | involved in comparison operators; at least the previous Octave
> | implementation did so.
>
> Yes. ?Not that it makes much sense (at least to me) but Matlab is
> documented to work this way.
>
> | OTOH, Matlab defines a rigorous ordering on complex numbers as the
> | lexicographical ordering of [abs(z), arg(z)], which is used in sort,
> | min and max, and is shared with Octave.
> | I couldn't find the Matlab behavior documented anywhere,
>
> Look at the alphabetical list of the documentation for Matlab
> functions on the web. ?Near the top of the page for relational
> operators, it says
>
> ?The operators <, >, <=, and >= use only the real part of their
> ?operands for the comparison. The operators == and ~= test real and
> ?imaginary parts.
>
> | However, it
> | simplifies the implementation significantly to consider one universal
> | ordering of complex numbers (defined in oct-cmplx.h) that gets
> | automatically used everywhere.
>
> Yes, I think it makes much more sense to have one definition for the
> ordering. ?Can anyone think of a case where it is really useful to
> compare complex numbers using only the real part?good reason, then
>

Right now I can't think of any (which doesn't mean there isn't any),
but even if it is, it can be done with real (), which will also be
more readable. On the contrary, getting the complex ordering is not
trivial. For instance, how would you check that a complex array is
strictly upwards sorted in Matlab? Compare
za = abs (z); zf = arg (z); all (za(1:n-1) < za(2:n) || (za(1:n-1) ==
za(2:n) && zf(1:n-1) < zf(2:n))
to the simple
z(1:n-1) < z(2:n)

But of course, it's primarily the inconsistency with max/min/sort that
makes the Matlab behavior nutty. Also, the complex ordering defined by
sort is consistent with complex equality (one of <, >, == is always
true, except for NaNs) but comparison by real parts isn't. It' also
consistent with the normal ordering of reals.

>
> | now hold for complex arrays as well (previously, this was not true).
> | Personally, I think this new behavior is more logical and consistent
> | and I vote for a change. I suppose few code depends on this and broken
> | scripts can be trivially fixed by wrapping operands in real () (which
> | I'd suggest anyway).
>
> Yes, I agree that if you want to compare complex numbers by real part
> only, then you should say so explicitly.
>
> | If I'm outvoted on this, I'd still like to keep that Matlab
> | compatibility mess out of liboctave, so I'll probably add a hack into
> | the interpreter to apply "real" to the operands first. It could also
> | be made conditional (for instance, keep the old behavior in the
> | braindamage mode), but I think John already said he doesn't like
> | global variables fundamentally influencing code flow.
>
> What about an optional "matlab-incompatibility" warning? ?Especially
> since we are changing the behavior of Octave too, and this is the kind
> of change that will otherwise silently change the results obtained
> from of previously "working" code.
>
> jwe
>

OK, that would probably work best. And the warning on in traditional
mode, I suppose. I'll try making a patch.

regards

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


From individ at acc.umu.se  Fri Aug 28 01:57:06 2009
From: individ at acc.umu.se (David Grundberg)
Date: Fri, 28 Aug 2009 08:57:06 +0200
Subject: [changeset] GraphicsMagick++ configuration
In-Reply-To: <19094.58227.727125.934346@segfault.lan>
References: <4A7AEEF4.2070101@acc.umu.se>	<19066.62968.137520.390478@segfault.lan>	<4A7B3868.9020001@acc.umu.se>	<19067.14844.220747.257229@segfault.lan>	<20090816210909.GA15975@atlan>	<20090825055536.GA7737@atlan>	<4A93D1D0.9040500@acc.umu.se>	<4A93D3FC.4080203@acc.umu.se>	<69d8d540908270402k2b5635a7gd9af02fd7f8161ca@mail.gmail.com>	<4A9678E8.9010409@acc.umu.se>	<4A96DBBC.1030201@gmx.net>
	<19094.58227.727125.934346@segfault.lan>
Message-ID: <4A977FC2.9070806@acc.umu.se>

John W. Eaton wrote:
> On 27-Aug-2009, Thomas Treichl wrote:
>
> | David Grundberg schrieb:
> | > Jaroslav Hajek wrote:
> | >> I applied this, updating also src/oct-conf.h.in and src/toplev.cc,
> | >> which was necessary.
> | >>
> | >> regards
> | > 
> | > Yes, I saw that you did so.
> | > 
> | > Thanks,
> | > David
> | 
> | That change causes a failing GraphicsMagick++ test for me. I changed
> | 
> |    CPPFLAGS="$CPPFLAGS $MAGICK_CPPFLAGS"
> |    LDFLAGS="$LIBS $MAGICK_LDFLAGS"
> |    LIBS="$LIBS $MAGICK_LIBS"
> | 
> | (cf. LDFLAGS line) to
> | 
> |    CPPFLAGS="$CPPFLAGS $MAGICK_CPPFLAGS"
> |    LDFLAGS="$LDFLAGS $MAGICK_LDFLAGS"
> |    LIBS="$LIBS $MAGICK_LIBS"
> | 
> | then it worked for me again. If this is the right thing to do then can you 
> | please make such a change? Thanks,
>
> In the configure script, I would not modify LDFLAGS, but instead just
> do
>
>   save_LIBS="$LIBS"
>   LIBS="$MAGICK_LDFLAGS $MAGICK_LIBS $LIBS"
>
>   ...
>
>   LIBS="$save_LIBS"
>
> I checked in the following change.
>
>   http://hg.savannah.gnu.org/hgweb/octave/rev/8dc1531e2149
>
> Thanks,
>
> jwe
>   


Thanks for fixing the typo, John. I'm curious; from reading the autoconf 
manual, LIBS are for -l flags, and LDFLAGS are for the rest. Why do you 
prefer using LIBS only?

David

From marco_atzeri at yahoo.it  Fri Aug 28 08:49:31 2009
From: marco_atzeri at yahoo.it (Marco Atzeri)
Date: Fri, 28 Aug 2009 13:49:31 +0000 (GMT)
Subject: linking order for suitesparse
Message-ID: <20170.89276.qm@web25501.mail.ukl.yahoo.com>

Hi,
building on last hg source I stumbled on
makeconf.in


## FIXME -- does order matter here?
SPARSE_LIBS = \
  $(AMD_LIBS) $(CAMD_LIBS) $(COLAMD_LIBS) \
    $(CCOLAMD_LIBS) $(CHOLMOD_LIBS) $(CXSPARSE_LIBS) \
    $(UMFPACK_LIBS)

at least on cygwin, it does matter and this order

-lcholmod -lumfpack  -lamd -lcamd -lcolamd -lccolamd -lcxsparse
 
works. So it should be:

SPARSE_LIBS = \
    $(CHOLMOD_LIBS) $(UMFPACK_LIBS) \
    $(AMD_LIBS) $(CAMD_LIBS) $(COLAMD_LIBS) \
    $(CCOLAMD_LIBS) $(CXSPARSE_LIBS)


Regards
Marco


      



From Thomas.Treichl at gmx.net  Fri Aug 28 13:44:47 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Fri, 28 Aug 2009 20:44:47 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <77186FBD-A43A-48FD-979A-2C6D7BA39A5A@mac.com>
References: <4A8449ED.1090506@gmx.net>
	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>
	<19077.28862.827842.41629@segfault.lan>	<4A868317.10203@gmx.net>
	<19081.34869.778915.594647@segfault.lan>	<4A8A63BE.4090300@gmx.net>
	<19082.50054.994278.817764@segfault.lan>	<4A8BB83A.4060408@gmx.net>
	<19093.22209.535838.360776@segfault.lan>	<4A959959.3040707@gmx.net>
	<77186FBD-A43A-48FD-979A-2C6D7BA39A5A@mac.com>
Message-ID: <4A98259F.9020600@gmx.net>

Ben Abbott schrieb:
> On Aug 26, 2009, at 4:21 PM, Benjamin Lindner wrote:
>> I did a fresh configure&build cycle and it builds&links successfully.
>> Excellent, thanks
>>
>> benjamin
> 
> I'm now able to build on Mac OSX as well.
> 
> Thanks!
> Ben

Ok now, I can compile everything until the *.oct files. Already compilation of 
amd.oct fails for me (and all the following files). These files require all that 
dependencies like hdf5, fftw3+f, readline and so on that we have in 
liboctinterp.dylib... Currently it seems very similiar like the symbols that 
I've already reported there:

https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-August/013085.html

How should this be treated? What should I do now?

   Thomas

From octave at phaselockedsystems.com  Fri Aug 28 13:48:57 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Fri, 28 Aug 2009 11:48:57 -0700
Subject: Build failure
Message-ID: <4A982699.9090707@phaselockedsystems.com>

Cloned from the tip last night, tried to build and got the following.  
The full configure and make outputs are attached as a tarball.

I am running gnuplot 4.2.5.  I have never successfully built the wxt 
terminal, so this is the x11 terminal.  If that matters.

Any ideas?

Bob


making PKG_ADD
ls: cannot access *.cc: No such file or directory
make[3]: Leaving directory 
`/export/home/rtshort/Mirrored/octave/Sources/octave-full/scripts/time'
make[2]: Leaving directory 
`/export/home/rtshort/Mirrored/octave/Sources/octave-full/scripts'
make -C doc all
make[2]: Entering directory 
`/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc'
making conf.texi from conf.texi.in
conf.texi is unchanged
make -C faq all
make[3]: Entering directory 
`/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc/faq'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc/faq'
make -C interpreter all
make[3]: Entering directory 
`/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc/interpreter'
../../run-octave -f -q -H -p . --eval "plotimages ('plot', 'txt');"
error: get: ambiguous property name paperposition; possible matches:

paperposition      paperpositionmode

error: error setting default property paperposition
error: __go_figure__: failed to create figure handle
error: called from:
error:   
/home/rtshort/Mirrored/octave/Sources/octave-full/scripts/plot/figure.m 
at line 67, column 9
error:   
/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc/interpreter/plotimages.m 
at line 85, column 5
error:   
/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc/interpreter/plotimages.m 
at line 21, column 3
make[3]: *** [plot.txt] Error 1
make[3]: Leaving directory 
`/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc/interpreter'
make[2]: *** [interpreter] Error 2
make[2]: Leaving directory 
`/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc'
make[1]: *** [doc] Error 2
make[1]: Leaving directory 
`/export/home/rtshort/Mirrored/octave/Sources/octave-full'
make: *** [all] Error 2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: crash.tar.gz
Type: application/x-gzip
Size: 35597 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090828/603b953f/attachment-0001.bin 

From Thomas.Treichl at gmx.net  Fri Aug 28 13:53:57 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Fri, 28 Aug 2009 20:53:57 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <19093.22352.617077.954938@segfault.lan>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>	<19077.28862.827842.41629@segfault.lan>	<4A867B26.3030508@gmx.net>	<19082.54127.595607.366724@segfault.lan>	<4A8AF498.6000306@gmx.net>
	<19093.22352.617077.954938@segfault.lan>
Message-ID: <4A9827C5.8040205@gmx.net>

John W. Eaton schrieb:
> On 18-Aug-2009, Thomas Treichl wrote:
> 
> | > Where is the requirement for -lexpat coming from?
> | 
> | -lexpat "or" -lxml2 is a dependency of -lfontconfig, I don't know if this in a 
> | general issue or if I need to fight such things for myself?
> 
> Probably our check for the fontconfig library needs to take that into
> account.  I haven't tried to update the part of the configure script
> that checks for the fontconfig library.

I've had a look into fontconfig.pc - fontconfig's pkg-config configuration file 
- there it says something about -lexpat. Maybe we should change the test for 
fontconfig to the pkg-config variant?

cat /Applications/Octave.app/Contents/Resources/lib/pkgconfig/fontconfig.pc

   prefix=/tmp/deps-i386
   exec_prefix=${prefix}
   libdir=${exec_prefix}/lib
   includedir=${prefix}/include

   Name: Fontconfig
   Description: Font configuration and customization library
   Version: 2.6.0
   Libs: -L${libdir} -lfontconfig
   Libs.private: -lexpat -L/tmp/deps-i386/lib -lfreetype
   Cflags: -I${includedir}

Best regards

   Thomas

From jwe at octave.org  Fri Aug 28 14:01:00 2009
From: jwe at octave.org (John W. Eaton)
Date: Fri, 28 Aug 2009 15:01:00 -0400
Subject: Build failure
In-Reply-To: <4A982699.9090707@phaselockedsystems.com>
References: <4A982699.9090707@phaselockedsystems.com>
Message-ID: <19096.10604.213264.101854@segfault.lan>

On 28-Aug-2009, Robert T. Short wrote:

| Cloned from the tip last night, tried to build and got the following.  
| The full configure and make outputs are attached as a tarball.
| 
| I am running gnuplot 4.2.5.  I have never successfully built the wxt 
| terminal, so this is the x11 terminal.  If that matters.
| 
| Any ideas?
| 
| Bob
| 
| 
| making PKG_ADD
| ls: cannot access *.cc: No such file or directory
| make[3]: Leaving directory 
| `/export/home/rtshort/Mirrored/octave/Sources/octave-full/scripts/time'
| make[2]: Leaving directory 
| `/export/home/rtshort/Mirrored/octave/Sources/octave-full/scripts'
| make -C doc all
| make[2]: Entering directory 
| `/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc'
| making conf.texi from conf.texi.in
| conf.texi is unchanged
| make -C faq all
| make[3]: Entering directory 
| `/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc/faq'
| make[3]: Nothing to be done for `all'.
| make[3]: Leaving directory 
| `/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc/faq'
| make -C interpreter all
| make[3]: Entering directory 
| `/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc/interpreter'
| ../../run-octave -f -q -H -p . --eval "plotimages ('plot', 'txt');"
| error: get: ambiguous property name paperposition; possible matches:
| 
| paperposition      paperpositionmode

This problem was fixed by a later patch that I checked in early this
morning.  There is still another problem related to user-defined
properties reported by Ben Abbott that I'm working on now.

jwe


From Thomas.Treichl at gmx.net  Fri Aug 28 14:11:32 2009
From: Thomas.Treichl at gmx.net (Thomas Treichl)
Date: Fri, 28 Aug 2009 21:11:32 +0200
Subject: linking liboctave fails (lapack missing?)
In-Reply-To: <4A9827C5.8040205@gmx.net>
References: <4A8449ED.1090506@gmx.net>	<4A845073.5010601@gmx.net>	<4A847CEC.6090800@gmx.net>	<19077.28862.827842.41629@segfault.lan>	<4A867B26.3030508@gmx.net>	<19082.54127.595607.366724@segfault.lan>	<4A8AF498.6000306@gmx.net>	<19093.22352.617077.954938@segfault.lan>
	<4A9827C5.8040205@gmx.net>
Message-ID: <4A982BE4.60305@gmx.net>

Thomas Treichl schrieb:
> John W. Eaton schrieb:
>> On 18-Aug-2009, Thomas Treichl wrote:
>>
>> | > Where is the requirement for -lexpat coming from?
>> | | -lexpat "or" -lxml2 is a dependency of -lfontconfig, I don't know 
>> if this in a | general issue or if I need to fight such things for 
>> myself?
>>
>> Probably our check for the fontconfig library needs to take that into
>> account.  I haven't tried to update the part of the configure script
>> that checks for the fontconfig library.
> 
> I've had a look into fontconfig.pc - fontconfig's pkg-config 
> configuration file - there it says something about -lexpat. Maybe we 
> should change the test for fontconfig to the pkg-config variant?
> 
> cat /Applications/Octave.app/Contents/Resources/lib/pkgconfig/fontconfig.pc
> 
>   prefix=/tmp/deps-i386
>   exec_prefix=${prefix}
>   libdir=${exec_prefix}/lib
>   includedir=${prefix}/include
> 
>   Name: Fontconfig
>   Description: Font configuration and customization library
>   Version: 2.6.0
>   Libs: -L${libdir} -lfontconfig
>   Libs.private: -lexpat -L/tmp/deps-i386/lib -lfreetype
>   Cflags: -I${includedir}

Oh. It already is pkg-config driven! I need a new idea ;)

   Thomas

From octave at phaselockedsystems.com  Fri Aug 28 14:23:41 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Fri, 28 Aug 2009 12:23:41 -0700
Subject: Build failure
In-Reply-To: <19096.10604.213264.101854@segfault.lan>
References: <4A982699.9090707@phaselockedsystems.com>
	<19096.10604.213264.101854@segfault.lan>
Message-ID: <4A982EBD.3090200@phaselockedsystems.com>


Thanks.  I will try again this evening.


John W. Eaton wrote:
> On 28-Aug-2009, Robert T. Short wrote:
>
> | Cloned from the tip last night, tried to build and got the following.  
> | The full configure and make outputs are attached as a tarball.
> | 
> | I am running gnuplot 4.2.5.  I have never successfully built the wxt 
> | terminal, so this is the x11 terminal.  If that matters.
> | 
> | Any ideas?
> | 
> | Bob
> | 
> | 
> | making PKG_ADD
> | ls: cannot access *.cc: No such file or directory
> | make[3]: Leaving directory 
> | `/export/home/rtshort/Mirrored/octave/Sources/octave-full/scripts/time'
> | make[2]: Leaving directory 
> | `/export/home/rtshort/Mirrored/octave/Sources/octave-full/scripts'
> | make -C doc all
> | make[2]: Entering directory 
> | `/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc'
> | making conf.texi from conf.texi.in
> | conf.texi is unchanged
> | make -C faq all
> | make[3]: Entering directory 
> | `/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc/faq'
> | make[3]: Nothing to be done for `all'.
> | make[3]: Leaving directory 
> | `/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc/faq'
> | make -C interpreter all
> | make[3]: Entering directory 
> | `/export/home/rtshort/Mirrored/octave/Sources/octave-full/doc/interpreter'
> | ../../run-octave -f -q -H -p . --eval "plotimages ('plot', 'txt');"
> | error: get: ambiguous property name paperposition; possible matches:
> | 
> | paperposition      paperpositionmode
>
> This problem was fixed by a later patch that I checked in early this
> morning.  There is still another problem related to user-defined
> properties reported by Ben Abbott that I'm working on now.
>
> jwe
>
>
>
>   


From tmacchant at yahoo.co.jp  Sun Aug 30 01:53:15 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Sun, 30 Aug 2009 15:53:15 +0900 (JST)
Subject: 3.2.3 RC1
In-Reply-To: <20090825102855.97230.qmail@web3813.mail.bbt.yahoo.co.jp>
Message-ID: <20090830065315.81501.qmail@web3815.mail.bbt.yahoo.co.jp>

Hello

--- Tatsuro MATSUOKA  wrote:
> I think that this patch in principle should be attached Because The %T and %e format specifiers
> for
> strftime are not implemented also for GCC-4.4.0 MinGW official.
> 
> However it gives the link error, I temporally disables the changeset.
> 
> I have to look at what is done by the patch and what is the origin ununderstandabel link error
> with
> it.
> 
> Hopefully this issue is not beyond my ability.
changeset 9424	69d05d1a63b9

--- a/configure.in	Wed Jul 08 18:31:29 2009 -0400
+++ b/configure.in	Thu Jul 09 15:04:34 2009 -0400
@@ -1654,8 +1654,8 @@
esac
 
case "$canonical_host_type" in
*-*-msdosmsvc)
    ## The %T format specifier for strftime is reportedly broken,
  *-*-msdosmsvc | *-*-mingw*)
    ## The %T and %e format specifiers for strftime are not implemented
_____________

AS I wrote previously the above changeset gives a link error for building on 3.2.3RC1 sources like 

Creating library file: liboctave.dll.a
fu008091.o:(.idata$2+0xc): undefined reference to `libmoldname_a_iname'
nmth008090.o:(.idata$4+0x0): undefined reference to `_nm__tzname'
collect2: ld returned 1 exit status
make[2]: *** [liboctave.dll] Error 1
make[2]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-rc1/liboctave'
make[1]: *** [liboctave] Error 2
make[1]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-rc1'


I looked the source strftime.c in liboctave.
The above errors the GCC-4.4.0 + MinGW -offcial seem to be treat code related to 'tzname' in MinGW
libraries.  So I modified condig.h to be the flag HAVE_TZNAME disable after configure like

/* Define to 1 if you don't have `tm_zone' but do have the external array
   `tzname'. */
//#define HAVE_TZNAME 1

With the above, the link error disappeared and I can get successful results on the octave prompt, 

octave.exe:3> strftime ("%e %T", localtime (time ()))
ans = 30 15:37:45

*******************
The errors
fu008091.o:(.idata$2+0xc): undefined reference to `libmoldname_a_iname'
nmth008090.o:(.idata$4+0x0): undefined reference to `_nm__tzname'

Perhaps comes from the fault of the GCC-4.4.0 on MinGW-Official.
I will ask the above problem at the MinGW Mailing list.

Anyway it is pleasure for me the changeset 9424 itself can be applied to the environment for GCC-4.4.0
MinGW-Official.

The results of the inquiry on the MinGW ML will be reported in the Octave-ML list.

Regards

Tatsuro 

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

From lindnerben at gmx.net  Sun Aug 30 06:14:30 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Sun, 30 Aug 2009 13:14:30 +0200
Subject: 3.2.3 RC1
In-Reply-To: <20090830065315.81501.qmail@web3815.mail.bbt.yahoo.co.jp>
References: <20090830065315.81501.qmail@web3815.mail.bbt.yahoo.co.jp>
Message-ID: <4A9A5F16.6080701@gmx.net>

Tatsuro MATSUOKA wrote:
> Hello
> 
> --- Tatsuro MATSUOKA  wrote:
>> I think that this patch in principle should be attached Because The %T and %e format specifiers
>> for
>> strftime are not implemented also for GCC-4.4.0 MinGW official.
>>
>> However it gives the link error, I temporally disables the changeset.
>>
>> I have to look at what is done by the patch and what is the origin ununderstandabel link error
>> with
>> it.
>>
>> Hopefully this issue is not beyond my ability.
> changeset 9424	69d05d1a63b9
> 
> --- a/configure.in	Wed Jul 08 18:31:29 2009 -0400
> +++ b/configure.in	Thu Jul 09 15:04:34 2009 -0400
> @@ -1654,8 +1654,8 @@
> esac
>  
> case "$canonical_host_type" in
> *-*-msdosmsvc)
>     ## The %T format specifier for strftime is reportedly broken,
>   *-*-msdosmsvc | *-*-mingw*)
>     ## The %T and %e format specifiers for strftime are not implemented
> _____________
> 
> AS I wrote previously the above changeset gives a link error for building on 3.2.3RC1 sources like 
> 
> Creating library file: liboctave.dll.a
> fu008091.o:(.idata$2+0xc): undefined reference to `libmoldname_a_iname'
> nmth008090.o:(.idata$4+0x0): undefined reference to `_nm__tzname'
> collect2: ld returned 1 exit status
> make[2]: *** [liboctave.dll] Error 1
> make[2]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-rc1/liboctave'
> make[1]: *** [liboctave] Error 2
> make[1]: Leaving directory `/home/octaves/OctBuild/octave-3.2.3-rc1'
> 

Have you checked with recent tip?

http://hg.savannah.gnu.org/hgweb/octave/rev/d280bfa04996
and
http://hg.tw-math.de/release-3-2-x/rev/ec70e577f419

fix it for at least the gcc-4.3.0 version .

benjamin

From lindnerben at gmx.net  Sun Aug 30 06:18:54 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Sun, 30 Aug 2009 13:18:54 +0200
Subject: GCC for octave/mingw32 (and ,mingw64?) (was OctaveForWindows
	Wiki (CategoryInstall) is updated (2009-08-24))
In-Reply-To: <20090826095810.95125.qmail@web3802.mail.bbt.yahoo.co.jp>
References: <20090826095810.95125.qmail@web3802.mail.bbt.yahoo.co.jp>
Message-ID: <4A9A601E.6080500@gmx.net>

Tatsuro MATSUOKA wrote:
> Hello Benjamin
> 
> The discussion is better to be moved to the maintainers list.
> Because discussions have been on the selection of GCC-complier.
> 
> In my opinion, from users point of view, the mingw complier is official or not is small problem.

It's not a small problem, it's not relevant IMO.

> I have been used for GCC-4.3.3-TDM for octave building before the gcc-4.4.0 MinGW on MinGW official
> site. It worked fine for me.
> 
> The 'clear all' crash problem exist for octave-3.2.x by gcc-4.3.0-TDM, while no problem occurs for
> that by GCC-4.4.0-Official.  
> 
> In the readme
> The command "clear all" exits with the error message
>    
>      error: stdin is not a tty!
>    
>    in conjunction with the ARPACK package e.g. when calling eigs()
> 
> In my computer, 'clear all' cashe octave soon after 'error: stdin is not a tty' when callinf eigs() on
> octave3.2.2/GCC-4.3.0.MinGW/TDM.
> 
> 
> The combination octave-3.2.x and gcc-4.3.0-TDM seems to cause this problem.
> 
> However, GCC-4.4.0-Official has the problem to use shared libstdc++ for dll and oct file building.
> Please see
> 
> http://www.nabble.com/octave-3.2.2-build-with-libstdc%2B%2B_s.a-by-GCC-4.4.0-(MinGW-Official)-td24662825.html#a24879769
> 
> I think that if 'clear all' problem is serious and this problem will not be solved easily, it is
> better you to try gcc-4.4.0-MinGW official.

Now we're talking facts.
If the various "clear all" segfaults are really fixed by gcc-4.4 then I 
should update the binaries, naturally.
I'm currently working on a 4.4 build with shared libstd++. Let's see how 
it works.
I'll report back when I have news.

benjamin

From bpabbott at mac.com  Sun Aug 30 16:03:07 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Sun, 30 Aug 2009 17:03:07 -0400
Subject: attempt to build on Mac OS 10.6 (Snow Leopard)
Message-ID: <010EF1F2-1797-46CD-8D43-A74B2C6E89BC@mac.com>

When I attempt to build 3.2.x or the developers sources on Mac OS 10.6  
I encounter the following configure failure.

> checking for tputs in -lncurses... no
> checking for tputs in -lcurses... no
> checking for tputs in -ltermcap... no
> checking for tputs in -lterminfo... no
> checking for tputs in -ltermlib... no
> configure: WARNING: I couldn't find -ltermcap, -lterminfo, - 
> lncurses, -lcurses, or -ltermlib!
> checking for rl_set_keyboard_input_timeout in -lreadline... no
> configure: WARNING: I need GNU Readline 4.2 or later
> configure: error: this is fatal unless you specify --disable-readline

find /sw/lib -name libncurses\.\*
/sw/lib/libncurses.5.dylib
/sw/lib/libncurses.dylib
/sw/lib/libncurses.dylib.5
/sw/lib/ncurses/libncurses.5.dylib
/sw/lib/ncurses/libncurses.a
/sw/lib/ncurses/libncurses.dylib
find /sw/lib -name libreadline\.\*
/sw/lib/libreadline.4.2.dylib
/sw/lib/libreadline.4.3.dylib
/sw/lib/libreadline.4.dylib
/sw/lib/libreadline.5.0.dylib
/sw/lib/libreadline.5.dylib
/sw/lib/libreadline.a
/sw/lib/libreadline.dylib

When I configure 3.0.5 on Mac OS 10.6, I don't see this problem

> checking for tputs in -lncurses... yes
> checking for rl_set_keyboard_input_timeout in -lreadline... yes

The script I used to configure includes the part below, which is  
derived from Octave package from Fink.

> a='--with-lapack=/sw/lib/liblapack.dylib --with-blas=/sw/lib/ 
> libf77blas.dylib'
> prefix=/sw
> FLIBDIR="/sw/lib/gcc4.4/lib"
> ./configure FLIBS="${FLIBDIR}/libgfortran.dylib" --prefix=/sw F77=/ 
> sw/bin/gfortran --host=i386-apple-darwin --build=i386-apple-darwin -- 
> infodir='${prefix}/share/info' --mandir='${prefix}/share/man' -- 
> libexecdir='${prefix}/lib' --enable-shared --enable-dl --disable- 
> static --without-mpi --with-hdf5 --with-fftw CPPFLAGS="-g -I/sw/ 
> include -I/sw/include/freetype2" FFLAGS="-g" LDFLAGS="-L/sw/lib/fltk- 
> aqua/lib -L/sw/lib -lGraphicsMagick -lfltk_gl -lfltk -lpthread" $a


I'm at a loss to determine what I need to do. Anyone have some insight  
here?

Thanks
Ben

From jwleblan at gmail.com  Sun Aug 30 17:10:57 2009
From: jwleblan at gmail.com (Joel LeBlanc)
Date: Sun, 30 Aug 2009 18:10:57 -0400
Subject: attempt to build on Mac OS 10.6 (Snow Leopard)
In-Reply-To: <010EF1F2-1797-46CD-8D43-A74B2C6E89BC@mac.com>
References: <010EF1F2-1797-46CD-8D43-A74B2C6E89BC@mac.com>
Message-ID: <34716c2e0908301510s633d1925r876cc0edd217cde6@mail.gmail.com>

Ben,
I am trying to build right now, but the configure went smooth.  Here is what
I used:

./autogen.sh

# Apple's vecLib:
export
blas='--with-lapack=-Wl,-framework,Accelerate,-dylib_file,/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib:/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
--with-blas=-Wl,-framework,Accelerate,-dylib_file,/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib:/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib'


# Similar to Fink's configure
./configure --prefix=/sw FLIBS=/sw/lib/gcc4.4/lib/libgfortran.dylib
F77=/sw/bin/gfortran CC=gcc-4 CPP=cpp-4 CXX=g++-4
--infodir='${prefix}/share/info' --mandir='${prefix}/share/man'
--libexecdir='${prefix}/lib' -enable-shared -enable-dl --disable-static
--without-mpi --with-hdf5 --with-fftw CPPFLAGS="-I/sw/include
-I/sw/include/freetype2 -I/sw/lib/flex/include" FFLAGS="-ff2c"
LDFLAGS="-L/sw/lib/fltk-aqua/lib -L/sw/lib/flex/lib -L/sw/lib/gcc4.4/lib/
-L/sw/lib -lgfortran -lGraphicsMagick -lfltk_gl -lfltk -lpthread" $blas

Have you updated your fink yet.  I found that FinkCommander has issues with
10.6, so you may need to do this from the command line.  I 1st installed the
new XCode (an "additional install").  Then I had to reindex fink (fink
index).  I think fink index failed the first time so I needed to run (fink
index -f).  Then I ran fink reinstall fink, to get fink built under 10.6.
 Finally, I ran fink update fink, to get the latest release.

~Joel

P.S. My octave build failed... Haven't looked into it yet.

On Sun, Aug 30, 2009 at 5:03 PM, Ben Abbott <bpabbott at mac.com> wrote:

> When I attempt to build 3.2.x or the developers sources on Mac OS 10.6 I
> encounter the following configure failure.
>
>  checking for tputs in -lncurses... no
>> checking for tputs in -lcurses... no
>> checking for tputs in -ltermcap... no
>> checking for tputs in -lterminfo... no
>> checking for tputs in -ltermlib... no
>> configure: WARNING: I couldn't find -ltermcap, -lterminfo, -lncurses,
>> -lcurses, or -ltermlib!
>> checking for rl_set_keyboard_input_timeout in -lreadline... no
>> configure: WARNING: I need GNU Readline 4.2 or later
>> configure: error: this is fatal unless you specify --disable-readline
>>
>
> find /sw/lib -name libncurses\.\*
> /sw/lib/libncurses.5.dylib
> /sw/lib/libncurses.dylib
> /sw/lib/libncurses.dylib.5
> /sw/lib/ncurses/libncurses.5.dylib
> /sw/lib/ncurses/libncurses.a
> /sw/lib/ncurses/libncurses.dylib
> find /sw/lib -name libreadline\.\*
> /sw/lib/libreadline.4.2.dylib
> /sw/lib/libreadline.4.3.dylib
> /sw/lib/libreadline.4.dylib
> /sw/lib/libreadline.5.0.dylib
> /sw/lib/libreadline.5.dylib
> /sw/lib/libreadline.a
> /sw/lib/libreadline.dylib
>
> When I configure 3.0.5 on Mac OS 10.6, I don't see this problem
>
>  checking for tputs in -lncurses... yes
>> checking for rl_set_keyboard_input_timeout in -lreadline... yes
>>
>
> The script I used to configure includes the part below, which is derived
> from Octave package from Fink.
>
>  a='--with-lapack=/sw/lib/liblapack.dylib
>> --with-blas=/sw/lib/libf77blas.dylib'
>> prefix=/sw
>> FLIBDIR="/sw/lib/gcc4.4/lib"
>> ./configure FLIBS="${FLIBDIR}/libgfortran.dylib" --prefix=/sw
>> F77=/sw/bin/gfortran --host=i386-apple-darwin --build=i386-apple-darwin
>> --infodir='${prefix}/share/info' --mandir='${prefix}/share/man'
>> --libexecdir='${prefix}/lib' --enable-shared --enable-dl --disable-static
>> --without-mpi --with-hdf5 --with-fftw CPPFLAGS="-g -I/sw/include
>> -I/sw/include/freetype2" FFLAGS="-g" LDFLAGS="-L/sw/lib/fltk-aqua/lib
>> -L/sw/lib -lGraphicsMagick -lfltk_gl -lfltk -lpthread" $a
>>
>
>
> I'm at a loss to determine what I need to do. Anyone have some insight
> here?
>
> Thanks
> Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090830/3dc5b1f6/attachment.html 

From bpabbott at mac.com  Sun Aug 30 22:21:49 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Sun, 30 Aug 2009 23:21:49 -0400
Subject: attempt to build on Mac OS 10.6 (Snow Leopard)
In-Reply-To: <34716c2e0908301510s633d1925r876cc0edd217cde6@mail.gmail.com>
References: <010EF1F2-1797-46CD-8D43-A74B2C6E89BC@mac.com>
	<34716c2e0908301510s633d1925r876cc0edd217cde6@mail.gmail.com>
Message-ID: <075192A3-86B4-4243-9539-C8ED9EE2AD89@mac.com>


On Aug 30, 2009, at 6:10 PM, Joel LeBlanc wrote:

> On Sun, Aug 30, 2009 at 5:03 PM, Ben Abbott <bpabbott at mac.com> wrote:
> When I attempt to build 3.2.x or the developers sources on Mac OS  
> 10.6 I encounter the following configure failure.
>
>> checking for tputs in -lncurses... no
>> checking for tputs in -lcurses... no
>> checking for tputs in -ltermcap... no
>> checking for tputs in -lterminfo... no
>> checking for tputs in -ltermlib... no
>> configure: WARNING: I couldn't find -ltermcap, -lterminfo, - 
>> lncurses, -lcurses, or -ltermlib!
>> checking for rl_set_keyboard_input_timeout in -lreadline... no
>> configure: WARNING: I need GNU Readline 4.2 or later
>> configure: error: this is fatal unless you specify --disable-readline
>>
>> find /sw/lib -name libncurses\.\*
>> /sw/lib/libncurses.5.dylib
>> /sw/lib/libncurses.dylib
>> /sw/lib/libncurses.dylib.5
>> /sw/lib/ncurses/libncurses.5.dylib
>> /sw/lib/ncurses/libncurses.a
>> /sw/lib/ncurses/libncurses.dylib
>> find /sw/lib -name libreadline\.\*
>> /sw/lib/libreadline.4.2.dylib
>> /sw/lib/libreadline.4.3.dylib
>> /sw/lib/libreadline.4.dylib
>> /sw/lib/libreadline.5.0.dylib
>> /sw/lib/libreadline.5.dylib
>> /sw/lib/libreadline.a
>> /sw/lib/libreadline.dylib
>>
>> When I configure 3.0.5 on Mac OS 10.6, I don't see this problem
>>
>> checking for tputs in -lncurses... yes
>> checking for rl_set_keyboard_input_timeout in -lreadline... yes
>>
>> The script I used to configure includes the part below, which is  
>> derived from Octave package from Fink.
>>
>> a='--with-lapack=/sw/lib/liblapack.dylib --with-blas=/sw/lib/ 
>> libf77blas.dylib'
>> prefix=/sw
>> FLIBDIR="/sw/lib/gcc4.4/lib"
>> ./configure FLIBS="${FLIBDIR}/libgfortran.dylib" --prefix=/sw F77=/ 
>> sw/bin/gfortran --host=i386-apple-darwin --build=i386-apple-darwin  
>> --infodir='${prefix}/share/info' --mandir='${prefix}/share/man' -- 
>> libexecdir='${prefix}/lib' --enable-shared --enable-dl --disable- 
>> static --without-mpi --with-hdf5 --with-fftw CPPFLAGS="-g -I/sw/ 
>> include -I/sw/include/freetype2" FFLAGS="-g" LDFLAGS="-L/sw/lib/ 
>> fltk-aqua/lib -L/sw/lib -lGraphicsMagick -lfltk_gl -lfltk - 
>> lpthread" $a
>>
>>
>> I'm at a loss to determine what I need to do. Anyone have some  
>> insight here?
>>
>> Thanks
>> Ben
>
>
> I am trying to build right now, but the configure went smooth.  Here  
> is what I used:
>
> ./autogen.sh
>
> # Apple's vecLib:
> export blas='--with-lapack=-Wl,-framework,Accelerate,-dylib_file,/ 
> System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ 
> vecLib.framework/Versions/A/libLAPACK.dylib:/System/Library/ 
> Frameworks/Accelerate.framework/Versions/A/Frameworks/ 
> vecLib.framework/Versions/A/libLAPACK.dylib --with-blas=-Wl,- 
> framework,Accelerate,-dylib_file,/System/Library/Frameworks/ 
> Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/ 
> A/libBLAS.dylib:/System/Library/Frameworks/Accelerate.framework/ 
> Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib'
>
>
> # Similar to Fink's configure
> ./configure --prefix=/sw FLIBS=/sw/lib/gcc4.4/lib/libgfortran.dylib  
> F77=/sw/bin/gfortran CC=gcc-4 CPP=cpp-4 CXX=g++-4 --infodir='$ 
> {prefix}/share/info' --mandir='${prefix}/share/man' --libexecdir='$ 
> {prefix}/lib' -enable-shared -enable-dl --disable-static --without- 
> mpi --with-hdf5 --with-fftw CPPFLAGS="-I/sw/include -I/sw/include/ 
> freetype2 -I/sw/lib/flex/include" FFLAGS="-ff2c" LDFLAGS="-L/sw/lib/ 
> fltk-aqua/lib -L/sw/lib/flex/lib -L/sw/lib/gcc4.4/lib/ -L/sw/lib - 
> lgfortran -lGraphicsMagick -lfltk_gl -lfltk -lpthread" $blas
>
> Have you updated your fink yet.  I found that FinkCommander has  
> issues with 10.6, so you may need to do this from the command line.   
> I 1st installed the new XCode (an "additional install").  Then I had  
> to reindex fink (fink index).  I think fink index failed the first  
> time so I needed to run (fink index -f).  Then I ran fink reinstall  
> fink, to get fink built under 10.6.  Finally, I ran fink update  
> fink, to get the latest release.
>
> ~Joel
>
> P.S. My octave build failed... Haven't looked into it yet.

Thanks Joel. WIth Mac OS 10.6, I now get as far as ...

g++-4 -c -I/sw/include -I/sw/include/freetype2 -I/sw/lib/flex/include - 
I/sw/include   -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/ 
misc  -DHAVE_CONFIG_H -mieee-fp -I/sw/include/freetype2 -I/sw/include - 
I/usr/X11/include   -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2  
-D_THREAD_SAFE  lo-specfun.cc -o pic/lo-specfun.o
lo-specfun.cc: In function ?Complex xlgamma(const Complex&)?:
lo-specfun.cc:327: error: ?lgamma_r? was not declared in this scope
lo-specfun.cc: In function ?FloatComplex xlgamma(const FloatComplex&)?:
lo-specfun.cc:394: error: ?lgammaf_r? was not declared in this scope
make[2]: *** [pic/lo-specfun.o] Error 1
make[1]: *** [liboctave] Error 2
make: *** [all] Error 2

I see this has happened for MacPorts as well. In that case, the  
failure occurred prior to the release of Mac OS 10.6

	http://www.nabble.com/Re%3A-cannot-compile-tt25177426.html#a25177426

My configure reported ...

configure: running /bin/sh ./configure --disable-option-checking '-- 
prefix=/sw'  'FLIBS=/sw/lib/gcc4.4/lib/libgfortran.dylib' 'F77=/sw/bin/ 
gfortran' 'CC=gcc-4' 'CPP=cpp-4' 'CXX=g++-4' '--infodir=${prefix}/ 
share/info' '--mandir=${prefix}/share/man' '--libexecdir=${prefix}/ 
lib' '-enable-shared' '-enable-dl' '--disable-static' '--without-mpi'  
'--with-hdf5' '--with-fftw' 'CPPFLAGS=-g -I/sw/include -I/sw/include/ 
freetype2 -I/sw/lib/flex/include' 'FFLAGS=-g -ff2c' 'LDFLAGS=-L/sw/lib/ 
fltk-aqua/lib -L/sw/lib/flex/lib -L/sw/lib/gcc4.4/lib/ -L/sw/lib - 
lgfortran -lGraphicsMagick -lfltk_gl -lfltk -lpthread' '--with-lapack=- 
Wl,-framework,Accelerate,-dylib_file,/System/Library/Frameworks/ 
Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/ 
libLAPACK.dylib:/System/Library/Frameworks/Accelerate.framework/ 
Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib' '-- 
with-blas=-Wl,-framework,Accelerate,-dylib_file,/System/Library/ 
Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/ 
Versions/A/libBLAS.dylib:/System/Library/Frameworks/ 
Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/ 
libBLAS.dylib' 'CFLAGS=-O3' 'CXXFLAGS=-O3' --cache-file=/dev/null -- 
srcdir=.

Ben



From jwe at octave.org  Sun Aug 30 22:34:42 2009
From: jwe at octave.org (John W. Eaton)
Date: Sun, 30 Aug 2009 23:34:42 -0400
Subject: Building octave with large matrices support
In-Reply-To: <69d8d540908272318k288eb06fgc343d06a5979d3e@mail.gmail.com>
References: <def1d5650908241312l1a54f811vce91ced6b33afae8@mail.gmail.com>
	<69d8d540908250020w58eb4fdci54a81a5bf25f4662@mail.gmail.com>
	<19093.39315.466708.135278@segfault.lan>
	<69d8d540908270400jfb1d72ble72aaafc4f8a2c68@mail.gmail.com>
	<19094.63881.529202.480384@segfault.lan>
	<69d8d540908272318k288eb06fgc343d06a5979d3e@mail.gmail.com>
Message-ID: <19099.17618.522287.15860@segfault.lan>

On 28-Aug-2009, Jaroslav Hajek wrote:

| It doesn't need to. I don't think there's a good way to safely inquire
| the integer size used in BLAS, but if your Fortran uses 64bit and BLAS
| 32bit, you may get garbage in the upper 32bit of the result from
| ISAMAX, hence the test will fail. But you may also get zero as a side
| effect (if the output is via a 64-bit register that is zeroed first).
| Hmmm. Maybe I can improve the test even further. The problem is that
| args are passed by pointers, so as long as no argument is actually
| outside the 32-bit range, it won't make a difference. And you
| certainly don't want a configure test with an 8GB array...
| 
| The converse, i.e. 32-bit Fortran calling 64-bit BLAS, is almost bound
| to fail in the existing test.

Writing tests for LAPACK shoudn't be too hard because it has some
routines that take integer arrays as arguments (for example, a pivot
vector).  If you pass a vector of pivots in an 8-byte integer array
and the routine is compiled for 4-byte integers, I think any
computation that uses the array will have to be wrong, so we could
easily test for that, and it doesn't require large arrays.
Unfortunately, I don't think that method will work for the BLAS
because it doesn't seem to have any routines that require integer
arrays.

| > | I think we should at least check that the Fortran integer matches
| > | octave_idx_type, which is an assumption made throughout Octave
| > | sources.
| >
| > Yes, this should be done so that the Fortran code that is distributed
| > with Octave will compile correctly, but we also need to check all
| > other libraries that we link with and that we pass octave_idx_type
| > values to. ?What's the best way to do that? ?I assume it will require
| > running test programs. ?Maybe we should move any further discussion to
| > the maintainers list?
| 
| The problem is most imminent in Fortran 77-style libraries, which
| typically don't provide any header files. That includes BLAS and
| LAPACK, ARPACK and QRUPDATE. The latter three less likely, because
| they will typically be compiled by system's Fortran compiler using
| default settings. But there are lots of BLASes. I'll see what I can
| do.

Maybe I'm misunderstanding your comment, but default settings are
probably not 8-byte integers.  For example, on my system, the default
settings would be 4-byte integer values, and I would need to use
something like -fdefault-integer-8 with gfortran to make code compiled
by gfortran work with Octave when building with --enable64.  Even
though I'm running an amd64 Debian system, the numerical libraries
that are distributed in Debian packages are all compiled with 4-byte
Fortran INTEGER values.  I think that's the correct thing to do for
Fortran standard conformance if REAL is a 4-byte value.  So building
Octave with --enable-64 most likely requires rebuilding all the
numerical libraries so that the integer values are 8-byte integers.

jwe


From jwe at octave.org  Sun Aug 30 22:43:29 2009
From: jwe at octave.org (John W. Eaton)
Date: Sun, 30 Aug 2009 23:43:29 -0400
Subject: attempt to build on Mac OS 10.6 (Snow Leopard)
In-Reply-To: <075192A3-86B4-4243-9539-C8ED9EE2AD89@mac.com>
References: <010EF1F2-1797-46CD-8D43-A74B2C6E89BC@mac.com>
	<34716c2e0908301510s633d1925r876cc0edd217cde6@mail.gmail.com>
	<075192A3-86B4-4243-9539-C8ED9EE2AD89@mac.com>
Message-ID: <19099.18145.409188.412322@segfault.lan>

On 30-Aug-2009, Ben Abbott wrote:

| Thanks Joel. WIth Mac OS 10.6, I now get as far as ...
| 
| g++-4 -c -I/sw/include -I/sw/include/freetype2 -I/sw/lib/flex/include - 
| I/sw/include   -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/ 
| misc  -DHAVE_CONFIG_H -mieee-fp -I/sw/include/freetype2 -I/sw/include - 
| I/usr/X11/include   -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2  
| -D_THREAD_SAFE  lo-specfun.cc -o pic/lo-specfun.o
| lo-specfun.cc: In function $,1rx(BComplex xlgamma(const Complex&)$,1ry(B:
| lo-specfun.cc:327: error: $,1rx(Blgamma_r$,1ry(B was not declared in this scope
| lo-specfun.cc: In function $,1rx(BFloatComplex xlgamma(const FloatComplex&)$,1ry(B:
| lo-specfun.cc:394: error: $,1rx(Blgammaf_r$,1ry(B was not declared in this scope
| make[2]: *** [pic/lo-specfun.o] Error 1
| make[1]: *** [liboctave] Error 2
| make: *** [all] Error 2

Your system apparently has lgamma_r, but maybe something needs to be
defined for it to be declared?  On my system (Debian, using GNU libc)
it is declared in math.h (actually, in bits/mathcalls.h, which is
unconditionally included in math.h.  It's declaration apparently
requires __USE_MISC to be defined, but apparently it is by default.
Of course, the details on OS X may be completely different, but maybe
you could start by searching for declarations of lgamma in
/usr/include?

jwe

From jwe at octave.org  Sun Aug 30 22:48:00 2009
From: jwe at octave.org (John W. Eaton)
Date: Sun, 30 Aug 2009 23:48:00 -0400
Subject: attempt to build on Mac OS 10.6 (Snow Leopard)
In-Reply-To: <19099.18145.409188.412322@segfault.lan>
References: <010EF1F2-1797-46CD-8D43-A74B2C6E89BC@mac.com>
	<34716c2e0908301510s633d1925r876cc0edd217cde6@mail.gmail.com>
	<075192A3-86B4-4243-9539-C8ED9EE2AD89@mac.com>
	<19099.18145.409188.412322@segfault.lan>
Message-ID: <19099.18416.868238.125032@segfault.lan>

On 30-Aug-2009, John W. Eaton wrote:

| On 30-Aug-2009, Ben Abbott wrote:
| 
| | Thanks Joel. WIth Mac OS 10.6, I now get as far as ...
| | 
| | g++-4 -c -I/sw/include -I/sw/include/freetype2 -I/sw/lib/flex/include - 
| | I/sw/include   -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/ 
| | misc  -DHAVE_CONFIG_H -mieee-fp -I/sw/include/freetype2 -I/sw/include - 
| | I/usr/X11/include   -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2  
| | -D_THREAD_SAFE  lo-specfun.cc -o pic/lo-specfun.o
| | lo-specfun.cc: In function $,1rx(BComplex xlgamma(const Complex&)$,1ry(B:
| | lo-specfun.cc:327: error: $,1rx(Blgamma_r$,1ry(B was not declared in this scope
| | lo-specfun.cc: In function $,1rx(BFloatComplex xlgamma(const FloatComplex&)$,1ry(B:
| | lo-specfun.cc:394: error: $,1rx(Blgammaf_r$,1ry(B was not declared in this scope
| | make[2]: *** [pic/lo-specfun.o] Error 1
| | make[1]: *** [liboctave] Error 2
| | make: *** [all] Error 2
| 
| Your system apparently has lgamma_r, but maybe something needs to be
| defined for it to be declared?  On my system (Debian, using GNU libc)
| it is declared in math.h (actually, in bits/mathcalls.h, which is
| unconditionally included in math.h.  It's declaration apparently
| requires __USE_MISC to be defined, but apparently it is by default.
| Of course, the details on OS X may be completely different, but maybe
| you could start by searching for declarations of lgamma in
| /usr/include?

Oh, I just found the page

  http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man3/lgamma_r.3.html

Which says that you need to define _REENTRANT before including math.h
in order for lgamma_r to be declared.  What happens if you make the
following change?

diff --git a/liboctave/lo-specfun.cc b/liboctave/lo-specfun.cc
--- a/liboctave/lo-specfun.cc
+++ b/liboctave/lo-specfun.cc
@@ -25,6 +25,12 @@
 #include <config.h>
 #endif
 
+#if !defined (_REENTRANT)
+#define _REENTRANT
+#endif
+#include <cmath>
+#undef _REENTRANT
+
 #include "Range.h"
 #include "CColVector.h"
 #include "CMatrix.h"


If we include this change in Octave, then maybe we should restrict it
to OS X systems?  Ugh.  Is there a better way?

jwe

From bpabbott at mac.com  Sun Aug 30 22:58:12 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Sun, 30 Aug 2009 23:58:12 -0400
Subject: attempt to build on Mac OS 10.6 (Snow Leopard)
In-Reply-To: <19099.18416.868238.125032@segfault.lan>
References: <010EF1F2-1797-46CD-8D43-A74B2C6E89BC@mac.com>
	<34716c2e0908301510s633d1925r876cc0edd217cde6@mail.gmail.com>
	<075192A3-86B4-4243-9539-C8ED9EE2AD89@mac.com>
	<19099.18145.409188.412322@segfault.lan>
	<19099.18416.868238.125032@segfault.lan>
Message-ID: <9DFDF37E-059B-42EC-BE56-72ACC952364E@mac.com>


On Aug 30, 2009, at 11:48 PM, John W. Eaton wrote:

> On 30-Aug-2009, John W. Eaton wrote:
>
> | On 30-Aug-2009, Ben Abbott wrote:
> |
> | | Thanks Joel. WIth Mac OS 10.6, I now get as far as ...
> | |
> | | g++-4 -c -I/sw/include -I/sw/include/freetype2 -I/sw/lib/flex/ 
> include -
> | | I/sw/include   -fPIC -I. -I.. -I../liboctave -I../src -I../ 
> libcruft/
> | | misc  -DHAVE_CONFIG_H -mieee-fp -I/sw/include/freetype2 -I/sw/ 
> include -
> | | I/usr/X11/include   -Wall -W -Wshadow -Wold-style-cast -Wformat - 
> g -O2
> | | -D_THREAD_SAFE  lo-specfun.cc -o pic/lo-specfun.o
> | | lo-specfun.cc: In function $,1rx(BComplex xlgamma(const  
> Complex&)$,1ry(B:
> | | lo-specfun.cc:327: error: $,1rx(Blgamma_r$,1ry(B was not  
> declared in this scope
> | | lo-specfun.cc: In function $,1rx(BFloatComplex xlgamma(const  
> FloatComplex&)$,1ry(B:
> | | lo-specfun.cc:394: error: $,1rx(Blgammaf_r$,1ry(B was not  
> declared in this scope
> | | make[2]: *** [pic/lo-specfun.o] Error 1
> | | make[1]: *** [liboctave] Error 2
> | | make: *** [all] Error 2
> |
> | Your system apparently has lgamma_r, but maybe something needs to be
> | defined for it to be declared?  On my system (Debian, using GNU  
> libc)
> | it is declared in math.h (actually, in bits/mathcalls.h, which is
> | unconditionally included in math.h.  It's declaration apparently
> | requires __USE_MISC to be defined, but apparently it is by default.
> | Of course, the details on OS X may be completely different, but  
> maybe
> | you could start by searching for declarations of lgamma in
> | /usr/include?
>
> Oh, I just found the page
>
>  http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man3/lgamma_r.3.html
>
> Which says that you need to define _REENTRANT before including math.h
> in order for lgamma_r to be declared.  What happens if you make the
> following change?
>
> diff --git a/liboctave/lo-specfun.cc b/liboctave/lo-specfun.cc
> --- a/liboctave/lo-specfun.cc
> +++ b/liboctave/lo-specfun.cc
> @@ -25,6 +25,12 @@
> #include <config.h>
> #endif
>
> +#if !defined (_REENTRANT)
> +#define _REENTRANT
> +#endif
> +#include <cmath>
> +#undef _REENTRANT
> +
> #include "Range.h"
> #include "CColVector.h"
> #include "CMatrix.h"
>
>
> If we include this change in Octave, then maybe we should restrict it
> to OS X systems?  Ugh.  Is there a better way?
>
> jwe

I've run ./configure with you change, and make has now progressed past  
lo-specfun.o

Thanks
Ben



From tmacchant at yahoo.co.jp  Mon Aug 31 06:08:11 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Mon, 31 Aug 2009 20:08:11 +0900 (JST)
Subject: 3.2.3 RC1
In-Reply-To: <4A9A5F16.6080701@gmx.net>
Message-ID: <20090831110812.8322.qmail@web3805.mail.bbt.yahoo.co.jp>

Hello

--- Benjamin Lindner  wrote:
> Have you checked with recent tip?
> 
> http://hg.savannah.gnu.org/hgweb/octave/rev/d280bfa04996
> and
> http://hg.tw-math.de/release-3-2-x/rev/ec70e577f419
> 
> fix it for at least the gcc-4.3.0 version .
> 
> benjamin
> 

It worked well.  Thanks!!

Regards

Tatsuro

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

From bpabbott at mac.com  Mon Aug 31 07:51:38 2009
From: bpabbott at mac.com (Ben Abbott)
Date: Mon, 31 Aug 2009 08:51:38 -0400
Subject: attempt to build on Mac OS 10.6 (Snow Leopard)
In-Reply-To: <9DFDF37E-059B-42EC-BE56-72ACC952364E@mac.com>
References: <010EF1F2-1797-46CD-8D43-A74B2C6E89BC@mac.com>
	<34716c2e0908301510s633d1925r876cc0edd217cde6@mail.gmail.com>
	<075192A3-86B4-4243-9539-C8ED9EE2AD89@mac.com>
	<19099.18145.409188.412322@segfault.lan>
	<19099.18416.868238.125032@segfault.lan>
	<9DFDF37E-059B-42EC-BE56-72ACC952364E@mac.com>
Message-ID: <FAE84779-DBF2-45F9-B0EB-FC45EFAF3532@mac.com>


On Aug 30, 2009, at 11:58 PM, Ben Abbott wrote:

> On Aug 30, 2009, at 11:48 PM, John W. Eaton wrote:
>
>> On 30-Aug-2009, John W. Eaton wrote:
>>
>> | On 30-Aug-2009, Ben Abbott wrote:
>> |
>> | | Thanks Joel. WIth Mac OS 10.6, I now get as far as ...
>> | |
>> | | g++-4 -c -I/sw/include -I/sw/include/freetype2 -I/sw/lib/flex/ 
>> include -
>> | | I/sw/include   -fPIC -I. -I.. -I../liboctave -I../src -I../ 
>> libcruft/
>> | | misc  -DHAVE_CONFIG_H -mieee-fp -I/sw/include/freetype2 -I/sw/ 
>> include -
>> | | I/usr/X11/include   -Wall -W -Wshadow -Wold-style-cast -Wformat  
>> -g -O2
>> | | -D_THREAD_SAFE  lo-specfun.cc -o pic/lo-specfun.o
>> | | lo-specfun.cc: In function $,1rx(BComplex xlgamma(const  
>> Complex&)$,1ry(B:
>> | | lo-specfun.cc:327: error: $,1rx(Blgamma_r$,1ry(B was not  
>> declared in this scope
>> | | lo-specfun.cc: In function $,1rx(BFloatComplex xlgamma(const  
>> FloatComplex&)$,1ry(B:
>> | | lo-specfun.cc:394: error: $,1rx(Blgammaf_r$,1ry(B was not  
>> declared in this scope
>> | | make[2]: *** [pic/lo-specfun.o] Error 1
>> | | make[1]: *** [liboctave] Error 2
>> | | make: *** [all] Error 2
>> |
>> | Your system apparently has lgamma_r, but maybe something needs to  
>> be
>> | defined for it to be declared?  On my system (Debian, using GNU  
>> libc)
>> | it is declared in math.h (actually, in bits/mathcalls.h, which is
>> | unconditionally included in math.h.  It's declaration apparently
>> | requires __USE_MISC to be defined, but apparently it is by default.
>> | Of course, the details on OS X may be completely different, but  
>> maybe
>> | you could start by searching for declarations of lgamma in
>> | /usr/include?
>>
>> Oh, I just found the page
>>
>> http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man3/lgamma_r.3.html
>>
>> Which says that you need to define _REENTRANT before including math.h
>> in order for lgamma_r to be declared.  What happens if you make the
>> following change?
>>
>> diff --git a/liboctave/lo-specfun.cc b/liboctave/lo-specfun.cc
>> --- a/liboctave/lo-specfun.cc
>> +++ b/liboctave/lo-specfun.cc
>> @@ -25,6 +25,12 @@
>> #include <config.h>
>> #endif
>>
>> +#if !defined (_REENTRANT)
>> +#define _REENTRANT
>> +#endif
>> +#include <cmath>
>> +#undef _REENTRANT
>> +
>> #include "Range.h"
>> #include "CColVector.h"
>> #include "CMatrix.h"
>>
>>
>> If we include this change in Octave, then maybe we should restrict it
>> to OS X systems?  Ugh.  Is there a better way?
>>
>> jwe
>
> I've run ./configure with you change, and make has now progressed  
> past lo-specfun.o
>
> Thanks
> Ben


"make check" now fails with a panic attack ...

> $ make check
> make -f octMakefile check
> make -C test check
> ./build_sparse_tests.sh
> ../run-octave --norc --silent --no-history ./fntests.m .
>
> Integrated test scripts:
>
>   src/DLD-FUNCTIONS/besselj.cc ........................... PASS   
> 180/180
>   src/DLD-FUNCTIONS/betainc.cc ........................... PASS    6/6
>   src/DLD-FUNCTIONS/bsxfun.cc ............................ PASS    
> 55/55
>   src/DLD-FUNCTIONS/cellfun.cc ........................... PASS    
> 74/74
>   src/DLD-FUNCTIONS/chol.cc ..............................terminate  
> called after throwing an instance of 'octave_execution_exception'
> panic: Abort trap -- stopping myself...
> make[2]: *** [check] Abort trap
> make[1]: *** [check] Error 2
> make: *** [check] Error 2


I copied the tests for chol.cc to an m-file and ran them to get a  
better look, and nothing failed.

> octave:1> chol_test
> warning: spcholinv is obsolete and will be removed from a future  
> version of Octave; please use cholinv instead
> warning: In this version of Octave, QR & Cholesky updating routines
> simply update the matrix and recalculate factorizations.
> To use fast algorithms, link Octave with the qrupdate library.
> See <http://sourceforge.net/projects/qrupdate>.


However, when I quit ...

octave:2> quit
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
/usr/local/bin/octave-dev: line 2: 51439 Segmentation fault      / 
Users/bpabbott/Development/mercurial/local_clone/run-octave $1 $2 $3  
$4 $5 $6

I rarely use gdb or octave's debugger. What might I look for?

Ben


From jwe at octave.org  Mon Aug 31 10:24:59 2009
From: jwe at octave.org (John W. Eaton)
Date: Mon, 31 Aug 2009 11:24:59 -0400
Subject: IEEE floating point initialization
Message-ID: <19099.60235.363151.210914@segfault.lan>

Are there any objections to installing the following change?

diff --git a/liboctave/lo-ieee.cc b/liboctave/lo-ieee.cc
--- a/liboctave/lo-ieee.cc
+++ b/liboctave/lo-ieee.cc
@@ -155,15 +155,22 @@
       break;
 
     case oct_mach_info::flt_fmt_cray:
+      (*current_liboctave_warning_handler)
+	("lo_ieee_init: CRAY without IEEE floating point math: expect some problems...");
+      break;
+
     case oct_mach_info::flt_fmt_vax_d:
     case oct_mach_info::flt_fmt_vax_g:
+      (*current_liboctave_warning_handler)
+	("lo_ieee_init: VAX without IEEE floating point math: expect some problems...");
       break;
 
     default:
       // If the format is unknown, then you will probably not have a
-      // useful system, but we will just issue a warning and go on...
-      (*current_liboctave_warning_handler)
-	("lo_ieee_init: unrecognized floating point format!");
+      // useful system, so it is probably not worth continuing.
+      (*current_liboctave_error_handler)
+	("lo_ieee_init: unrecognized floating point format!  Maybe DLAMCH is miscompiled, or you are using some strange system without IEEE floating point math?");
+      abort ();
     }
 }
 
Since Octave won't really work properly on systems that don't have
IEEE floating point arithmetic, maybe we should just fail even on the
known systems?  I mean, I don't think anyone is using Octave on a VAX
without IEEE math.  Or on any old CRAY hardware, though  I was
semi-successful in getting Octave to run on one once.

jwe

From octave at phaselockedsystems.com  Mon Aug 31 12:15:46 2009
From: octave at phaselockedsystems.com (Robert T. Short)
Date: Mon, 31 Aug 2009 10:15:46 -0700
Subject: IEEE floating point initialization
In-Reply-To: <19099.60235.363151.210914@segfault.lan>
References: <19099.60235.363151.210914@segfault.lan>
Message-ID: <4A9C0542.6020809@phaselockedsystems.com>


It is certainly a friendly thing to to, but philosophically speaking, if 
it can't work, why carry the code around?  Just more stuff to have to 
manage.  Maybe even just put a "README.xxmachinexx" that says "octave 
can't work on this machine".  At that, the default seems to say it all 
anyway.


John W. Eaton wrote:
> Are there any objections to installing the following change?
>
> diff --git a/liboctave/lo-ieee.cc b/liboctave/lo-ieee.cc
> --- a/liboctave/lo-ieee.cc
> +++ b/liboctave/lo-ieee.cc
> @@ -155,15 +155,22 @@
>        break;
>  
>      case oct_mach_info::flt_fmt_cray:
> +      (*current_liboctave_warning_handler)
> +	("lo_ieee_init: CRAY without IEEE floating point math: expect some problems...");
> +      break;
> +
>      case oct_mach_info::flt_fmt_vax_d:
>      case oct_mach_info::flt_fmt_vax_g:
> +      (*current_liboctave_warning_handler)
> +	("lo_ieee_init: VAX without IEEE floating point math: expect some problems...");
>        break;
>  
>      default:
>        // If the format is unknown, then you will probably not have a
> -      // useful system, but we will just issue a warning and go on...
> -      (*current_liboctave_warning_handler)
> -	("lo_ieee_init: unrecognized floating point format!");
> +      // useful system, so it is probably not worth continuing.
> +      (*current_liboctave_error_handler)
> +	("lo_ieee_init: unrecognized floating point format!  Maybe DLAMCH is miscompiled, or you are using some strange system without IEEE floating point math?");
> +      abort ();
>      }
>  }
>  
> Since Octave won't really work properly on systems that don't have
> IEEE floating point arithmetic, maybe we should just fail even on the
> known systems?  I mean, I don't think anyone is using Octave on a VAX
> without IEEE math.  Or on any old CRAY hardware, though  I was
> semi-successful in getting Octave to run on one once.
>
> jwe
>
>
>   


From lindnerben at gmx.net  Mon Aug 31 13:59:31 2009
From: lindnerben at gmx.net (Benjamin Lindner)
Date: Mon, 31 Aug 2009 20:59:31 +0200
Subject: GCC for octave/mingw32 (and ,mingw64?) (was OctaveForWindows
	Wiki (CategoryInstall) is updated (2009-08-24))
In-Reply-To: <4A9A601E.6080500@gmx.net>
References: <20090826095810.95125.qmail@web3802.mail.bbt.yahoo.co.jp>
	<4A9A601E.6080500@gmx.net>
Message-ID: <4A9C1D93.3030809@gmx.net>

Benjamin Lindner wrote:
>> However, GCC-4.4.0-Official has the problem to use shared libstdc++ 
>> for dll and oct file building.
>> Please see
>>
>> http://www.nabble.com/octave-3.2.2-build-with-libstdc%2B%2B_s.a-by-GCC-4.4.0-(MinGW-Official)-td24662825.html#a24879769 
>>

Searching around the web I came across the following bug report
https://sourceforge.net/tracker/?func=detail&aid=2836185&group_id=2435&atid=102435

It suggests a patch for some of the shared libstd++ errors.
Ans indeed I at least can now successfully link graphicsmagick++ with 
shared libstd++ using mingw-gcc-4.4.0

Let's see if this is the only bug or others lurk somewhere along the road...

benjamin

From tmacchant at yahoo.co.jp  Mon Aug 31 17:48:08 2009
From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA)
Date: Tue, 1 Sep 2009 07:48:08 +0900 (JST)
Subject: GCC for octave/mingw32 (and ,
	mingw64?) (was OctaveForWindows Wiki (CategoryInstall) is updated
	(2009-08-24))
In-Reply-To: <4A9C1D93.3030809@gmx.net>
Message-ID: <20090831224808.20316.qmail@web3814.mail.bbt.yahoo.co.jp>

Hello

--- Benjamin Lindner wrote:

> Searching around the web I came across the following bug report
> https://sourceforge.net/tracker/?func=detail&aid=2836185&group_id=2435&atid=102435
> 
> It suggests a patch for some of the shared libstd++ errors.
> Ans indeed I at least can now successfully link graphicsmagick++ with 
> shared libstd++ using mingw-gcc-4.4.0
> 
> Let's see if this is the only bug or others lurk somewhere along the road...

Thank you for your information.  I will re-try non-tricky way to link with the shared libstdc++.

Regards

Tatsuro

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/