headers
Thomas Weber | 1 Nov 2009 12:18
Picon

Re: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink())

On Thu, Oct 22, 2009 at 11:30:43AM -0400, John W. Eaton wrote:
> On 22-Oct-2009, S,Aibastien Villemot wrote:
> 
> | Le mercredi 21 octobre 2009 ,b` 10:01 -0400, John W. Eaton a ,bicrit :
> | > OK, this seems better than forcing all of the directories in the load
> | > path to be read again.  So how about the following change?  It seems
> | > to work for me.
> | > 
> | >   http://hg.savannah.gnu.org/hgweb/octave/rev/d6b2b708b6b0
> | 
> | Applied on Octave 3.2.3, this patch solves the problem, in particular
> | with Dynare.
> 
> The patch modifies the interfaces of some classes, so I'm not sure
> whether it is OK for a future 3.2.x release.

I'm trying to get a solution for this on 3.2, but I have a question:

In src/load-path.cc, the method load_path::dir_info::update()
has an 
	if (is_relative)
part, in which the cache of already visited directories is checked. Why
is this check only done for relative directories?

	Thomas
Permalink | Reply | 1 comment |
headers
John W. Eaton | 1 Nov 2009 18:45

Re: Updating load-path cache based on modification times probably a bad idea (was: Race condition between Octave 3.2.3 and unlink())

On  1-Nov-2009, Thomas Weber wrote:

| On Thu, Oct 22, 2009 at 11:30:43AM -0400, John W. Eaton wrote:
| > On 22-Oct-2009, S,Aibastien Villemot wrote:
| > 
| > | Le mercredi 21 octobre 2009 ,b` 10:01 -0400, John W. Eaton a ,bicrit :
| > | > OK, this seems better than forcing all of the directories in the load
| > | > path to be read again.  So how about the following change?  It seems
| > | > to work for me.
| > | > 
| > | >   http://hg.savannah.gnu.org/hgweb/octave/rev/d6b2b708b6b0
| > | 
| > | Applied on Octave 3.2.3, this patch solves the problem, in particular
| > | with Dynare.
| > 
| > The patch modifies the interfaces of some classes, so I'm not sure
| > whether it is OK for a future 3.2.x release.
| 
| I'm trying to get a solution for this on 3.2, but I have a question:
| 
| 
| In src/load-path.cc, the method load_path::dir_info::update()
| has an 
| 	if (is_relative)
| part, in which the cache of already visited directories is checked. Why
| is this check only done for relative directories?

Lookups are done by whatever name is in the path.  We don't want to
have to read the directory contents for relative directories unless we
haven't seen them before, so we also keep a list of directory
(Continue reading)

Permalink | Reply | 0 comments |
headers
John W. Eaton | 1 Nov 2009 20:01

Re: issorted incompatibility

On 31-Oct-2009, Carlo de Falco wrote:

| On 30 Oct 2009, at 20:33, Thomas Treichl wrote:
| 
| > Carlo de Falco schrieb:
| >> --------
| >> Bug report for Octave 3.2.3 configured for i386-apple-darwin8.11.1
| >
| > Can somebody on a Linux box please check this, too?
| > Thanks,
| >  Thomas
| 
| The behaviour is the same on Fedora 11

I checked in the following change.

  http://hg.savannah.gnu.org/hgweb/octave/rev/7fc1c8c47b86

This change should provide compatibility while also allowing the user
to specify the sort mode.

jwe
Permalink | Reply | 0 comments |
headers
Jaroslav Hajek | 2 Nov 2009 10:52
Picon

Re: no match operator on mx-inlines.cc

On Fri, Oct 23, 2009 at 2:46 PM, Marco Atzeri <marco_atzeri <at> yahoo.it> wrote:
> Hi,
> on latest
>
> $ hg tip
> changeset:   9757:95ad9c2a27e2
> tag:         tip
> user:        Jaroslav Hajek <highegg <at> gmail.com>
> date:        Fri Oct 23 10:35:59 2009 +0200
> summary:     fix idx_vector construction checks
>
> building with gcc-4.3.4-1 on cygwin 1.7
>
> g++ -c     -I. -I../../octave/liboctave -I.. -I../liboctave -I../src -I../libcruft/misc
-I../../octave -I../../octave/liboctave -I../../octave/src -I../../octave/libcruft/misc
 -DHAVE_CONFIG_H -mieee-fp   -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2
 ../../octave/liboctave/CNDArray.cc -o CNDArray.o
> ../../octave/liboctave/mx-inlines.cc: In function ‘void twosum_accum(T&, T&, const T&) [with T = std::complex<double>]’:
> ../../octave/liboctave/mx-inlines.cc:1263:   instantiated from ‘T mx_inline_xsum(const T*,
octave_idx_type) [with T = std::complex<double>]’
> ../../octave/liboctave/mx-inlines.cc:1289:   instantiated from ‘void mx_inline_xsum(const
T*, T*, octave_idx_type, octave_idx_type, octave_idx_type) [with T = std::complex<double>]’
> ../../octave/liboctave/CNDArray.cc:669:   instantiated from here
>
>
> ../../octave/liboctave/mx-inlines.cc:1252: error: no match for ‘operator-’ in ‘s1 - s’
>
>
> ../../octave/liboctave/CMatrix.h:439: note: candidates are: ComplexMatrix operator-(const ComplexMatrix&)
> ../../octave/liboctave/CMatrix.h:439: note:                 ComplexMatrix operator-(const
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jaroslav Hajek | 2 Nov 2009 10:54
Picon

Re: base class assignment problem (was: Re: very strange bug)

On Fri, Oct 30, 2009 at 6:38 PM, John W. Eaton <jwe <at> octave.org> wrote:
> On 30-Oct-2009, Lukas Reichlin wrote:
>
> | control-oo is here:
> | http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo/
> |
> | Download the package with:
> | http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/control-oo.tar.gz?view=tar
> |
> | Make sure that the "legacy" control package is not in your Octave
> | path, because some functions have identical names (Matlab
> | compatibility).
> |
> | I reduced the example as good as possible. If it is still too
> | complicated to understand, you will have to wait until Robert posts
> | his example next weekend.
>
> I'm attaching a minimal example.  Unpack the oo-bug.tar.gz file, cd to
> the oo-bug directory and run the bug.m script.
>
> The problem seems to be that the base class objects are not properly
> copied when their fields are modified inside methods.  I don't have a
> solution so it would be great if someone else would like to take a
> shot a fixing this problem.
>
> jwe
>
>

How about this?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jaroslav Hajek | 2 Nov 2009 10:58
Picon

Re: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so

On Thu, Oct 29, 2009 at 3:40 PM, Georgi D. Sotirov <gdsotirov <at> dir.bg> wrote:
> Hello,
>
> I encounter the following problem on Slackware Linux 13.0 with LAPACK 3.2.1
> and Octave 3.2.3. When I run octave it uses almost the whole CPU time on the
> machine, without being able to finish. I've traced the problem to the
> following:
>
> # gdb /usr/bin/octave
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i486-slackware-linux"...
> (no debugging symbols found)
> (gdb) r
> Starting program: /usr/bin/octave
> (no debugging symbols found)
> [Thread debugging using libthread_db enabled]
> (no debugging symbols found)
> [New Thread 0xb599e8e0 (LWP 3266)]
> (no debugging symbols found)
> ^C
> Program received signal SIGINT, Interrupt.
> [Switching to Thread 0xb599e8e0 (LWP 3266)]
> 0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1
> (gdb) bt
> #0  0xb66bb908 in dlamc3_ () from /usr/lib/liblapack.so.3.2.1
(Continue reading)

Permalink | Reply | 23 comments |
headers
Marco Atzeri | 2 Nov 2009 11:07
Picon
Favicon

Re: no match operator on mx-inlines.cc


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

> Da: Jaroslav Hajek <highegg <at> gmail.com>
> Oggetto: Re: no match operator on mx-inlines.cc
> A: "Marco Atzeri" <marco_atzeri <at> yahoo.it>
> Cc: bug <at> octave.org
> Data: Lunedì 2 novembre 2009, 10:52
> On Fri, Oct 23, 2009 at 2:46 PM,
> Marco Atzeri <marco_atzeri <at> yahoo.it>
> wrote:
> > Hi,
> > on latest
> >
> > $ hg tip
> > changeset:   9757:95ad9c2a27e2
> > tag:         tip
> > user:        Jaroslav Hajek <highegg <at> gmail.com>
> > date:        Fri Oct 23 10:35:59 2009 +0200
> > summary:     fix idx_vector construction checks
> >
> > building with gcc-4.3.4-1 on cygwin 1.7
> >
> > g++ -c     -I. -I../../octave/liboctave -I..
> -I../liboctave -I../src -I../libcruft/misc -I../../octave
> -I../../octave/liboctave -I../../octave/src
> -I../../octave/libcruft/misc  -DHAVE_CONFIG_H -mieee-fp  
> -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2
>  ../../octave/liboctave/CNDArray.cc -o CNDArray.o
> > ../../octave/liboctave/mx-inlines.cc: In function
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jaroslav Hajek | 2 Nov 2009 11:10
Picon

Re: no match operator on mx-inlines.cc

On Mon, Nov 2, 2009 at 11:07 AM, Marco Atzeri <marco_atzeri <at> yahoo.it> wrote:
>
>
> --- Lun 2/11/09, Jaroslav Hajek <highegg <at> gmail.com> ha scritto:
>
>> Da: Jaroslav Hajek <highegg <at> gmail.com>
>> Oggetto: Re: no match operator on mx-inlines.cc
>> A: "Marco Atzeri" <marco_atzeri <at> yahoo.it>
>> Cc: bug <at> octave.org
>> Data: Lunedì 2 novembre 2009, 10:52
>> On Fri, Oct 23, 2009 at 2:46 PM,
>> Marco Atzeri <marco_atzeri <at> yahoo.it>
>> wrote:
>> > Hi,
>> > on latest
>> >
>> > $ hg tip
>> > changeset:   9757:95ad9c2a27e2
>> > tag:         tip
>> > user:        Jaroslav Hajek <highegg <at> gmail.com>
>> > date:        Fri Oct 23 10:35:59 2009 +0200
>> > summary:     fix idx_vector construction checks
>> >
>> > building with gcc-4.3.4-1 on cygwin 1.7
>> >
>> > g++ -c     -I. -I../../octave/liboctave -I..
>> -I../liboctave -I../src -I../libcruft/misc -I../../octave
>> -I../../octave/liboctave -I../../octave/src
>> -I../../octave/libcruft/misc  -DHAVE_CONFIG_H -mieee-fp
>> -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Goffioul | 2 Nov 2009 11:22
Picon

Re: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so

On Mon, Nov 2, 2009 at 9:58 AM, Jaroslav Hajek <highegg <at> gmail.com> wrote:
> the SLAMCH and DLAMCH routines are sensitive to compiler
> optimizations. I use the settings (in make.inc from LAPACK tarball)
> NOOPT    = -mieee-fp -ffloat-store -fPIC
> and it works well. I think that in future releases these routines will
> be replaced by querying Fortran 90 internals.

Will this still be F77 compatible or will it definitely require a F90
compiler?

Michael.
Permalink | Reply | 20 comments |
headers
Jaroslav Hajek | 2 Nov 2009 11:24
Picon

Re: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so

On Mon, Nov 2, 2009 at 11:22 AM, Michael Goffioul
<michael.goffioul <at> gmail.com> wrote:
> On Mon, Nov 2, 2009 at 9:58 AM, Jaroslav Hajek <highegg <at> gmail.com> wrote:
>> the SLAMCH and DLAMCH routines are sensitive to compiler
>> optimizations. I use the settings (in make.inc from LAPACK tarball)
>> NOOPT    = -mieee-fp -ffloat-store -fPIC
>> and it works well. I think that in future releases these routines will
>> be replaced by querying Fortran 90 internals.
>
> Will this still be F77 compatible or will it definitely require a F90
> compiler?
>
> Michael.
>

See
http://www.netlib.org/lapack/lapack-3.2.html#_7_install_procedure

--

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

Gmane