Menu
▾
▴
octave-dev — GNU Octave developers' list
This list is closed, nobody may subscribe to it.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
(10) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
(4) |
Mar
|
Apr
(3) |
May
(13) |
Jun
(2) |
Jul
(7) |
Aug
|
Sep
(2) |
Oct
(5) |
Nov
(8) |
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
(19) |
Apr
(8) |
May
(8) |
Jun
(8) |
Jul
(4) |
Aug
(8) |
Sep
(19) |
Oct
(13) |
Nov
(37) |
Dec
(2) |
| 2003 |
Jan
(7) |
Feb
(23) |
Mar
(16) |
Apr
(4) |
May
(18) |
Jun
(9) |
Jul
(7) |
Aug
(6) |
Sep
(7) |
Oct
|
Nov
(39) |
Dec
(57) |
| 2004 |
Jan
(21) |
Feb
(15) |
Mar
(17) |
Apr
(9) |
May
(17) |
Jun
(65) |
Jul
(33) |
Aug
(48) |
Sep
(93) |
Oct
(35) |
Nov
(18) |
Dec
(4) |
| 2005 |
Jan
(20) |
Feb
(59) |
Mar
(17) |
Apr
(59) |
May
(77) |
Jun
(32) |
Jul
(34) |
Aug
(8) |
Sep
(34) |
Oct
(26) |
Nov
(65) |
Dec
(66) |
| 2006 |
Jan
(45) |
Feb
(37) |
Mar
(50) |
Apr
(32) |
May
(48) |
Jun
(42) |
Jul
(12) |
Aug
(53) |
Sep
(51) |
Oct
(79) |
Nov
(46) |
Dec
(25) |
| 2007 |
Jan
(120) |
Feb
(78) |
Mar
(45) |
Apr
(91) |
May
(155) |
Jun
(66) |
Jul
(96) |
Aug
(110) |
Sep
(145) |
Oct
(189) |
Nov
(68) |
Dec
(160) |
| 2008 |
Jan
(163) |
Feb
(212) |
Mar
(209) |
Apr
(157) |
May
(216) |
Jun
(120) |
Jul
(80) |
Aug
(83) |
Sep
(98) |
Oct
(120) |
Nov
(80) |
Dec
(129) |
| 2009 |
Jan
(45) |
Feb
(80) |
Mar
(174) |
Apr
(142) |
May
(133) |
Jun
(191) |
Jul
(183) |
Aug
(138) |
Sep
(77) |
Oct
(141) |
Nov
(209) |
Dec
(131) |
| 2010 |
Jan
(85) |
Feb
(213) |
Mar
(245) |
Apr
(222) |
May
(168) |
Jun
(82) |
Jul
(50) |
Aug
(144) |
Sep
(92) |
Oct
(80) |
Nov
(64) |
Dec
(78) |
| 2011 |
Jan
(58) |
Feb
(98) |
Mar
(112) |
Apr
(98) |
May
(64) |
Jun
(150) |
Jul
(126) |
Aug
(59) |
Sep
(271) |
Oct
(154) |
Nov
(321) |
Dec
(183) |
| 2012 |
Jan
(146) |
Feb
(217) |
Mar
(426) |
Apr
(208) |
May
(206) |
Jun
(230) |
Jul
(158) |
Aug
(170) |
Sep
(237) |
Oct
(260) |
Nov
(178) |
Dec
|
|
From: Paul K. <pki...@us...> - 2003-07-29 22:45:24
|
Hans-Georg Beyer wrote: >Dear Paul Kienzle, > >If you are still active in the field, here is my problem report: > Yes, but I'm about to go away for a bit. Hopefully someone else on the list can look into this. Paul Kienzle pki...@us... >I compiled lp.cc and tried to use it with octave-2.1.50: > >octave-2.1.50:27> lp([1,1],[-1,0;0,-1;1,0;0,1],[-1,-1,3,3],[-10,-10],[10,10],0) >ans = > > 10 > 10 > >This is obviously wrong (solution is (1,1), constraints are just a rectangular >box [1,3]x[1,3]). > >Using only three arguments yields: > >octave-2.1.50:33> lp([1,1],[-1,0;0,-1;1,0;0,1],[-1,-1,3,3]) >error: lp: columns in the second argument do not match the fourth argument. > >Any idea how to fix this? > |
|
From: Paul K. <pki...@us...> - 2003-07-29 22:42:09
|
WJ Atsma wrote:
> I just synchronised with the cvs and make stalls at the start:
>
> # make
> Makeconf:49: *** missing separator. Stop.
>
I don't know if it will help, but you need to
do the following before make:
# ./autogen.sh
# ./configure
Paul Kienzle
pki...@us...
PS, please reply to the list as I will be away
for a bit.
|
|
From: WJ A. <oc...@wy...> - 2003-07-29 15:46:28
|
I just synchronised with the cvs and make stalls at the start: # make Makeconf:49: *** missing separator. Stop. The line in question: @DEFHAVE_X@ starts with @ and is interpreted as a target without a cause. Replacing=20 it with: HAVE_X=3D1 makes that step work. which probably should read something like @DEFHAVE_X@ Is this just me or does this happen to others? |
|
From: Andy A. <ad...@si...> - 2003-07-25 02:37:58
|
David Bateman wrote: > >splu(sparse([1 1], [1 2], [1 1], 3, 3)) > >also seg faults.... Thus the only real solution is a fix in SuperLU >itself.. I agree. I have a few other sparse bugs that need fixing. Essentially, SuperLU does not handly problems gracefully. Fixing this will require some modifications to SuperLU code (I've checked the relevant parts of SuperLU into octave-forge already, because I needed to make some mods to remove verbose printing) I'm planning to get to work on this soon, but if anyone else would like to help, tell me. Also, if someone knows of a really stable sparse library - it may still make sense to switch to that. Andy |
|
From: David B. <Dav...@mo...> - 2003-07-24 09:52:42
|
Sorry to reply to my own mail but the functions [dz]gscon need the LU factorization and splu(sparse([1 1], [1 2], [1 1], 3, 3)) also seg faults.... Thus the only real solution is a fix in SuperLU itself.. D. -- David Bateman Dav...@mo... Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |
|
From: David B. <Dav...@mo...> - 2003-07-24 09:25:38
|
Dear Ramine,
Firstly this is clearly an octave-forge problem and not one in octave
itself.
The problem is that SuperLU behaves badly if the matrix is singular,
as any matrix with only one element (as in your case) is. As a test
spinv(sparse([1 1], [1 2], [1 1], 3, 3))
will also crash. Using gdb on your case gives.
% gdb octave
(gdb) run
octave:1> b=sprand(3,3,.1);
octave:2> c=[1,1,1]'
c =
1
1
1
octave:3> b\c
Program received signal SIGSEGV, Segmentation fault.
0x41398d27 in dpivotL (jcol=1, u=1, usepr=0xbfffe340, perm_r=0x8b9c918,
iperm_r=0x0, iperm_c=0x8b90778, pivrow=0xbfffe344, Glu=0x413c2900)
at SuperLU/SRC/dpivotL.c:122
122 perm_r[*pivrow] = jcol;
(gdb) back
#0 0x41398d27 in dpivotL (jcol=1, u=1, usepr=0xbfffe340, perm_r=0x8b9c918,
iperm_r=0x0, iperm_c=0x8b90778, pivrow=0xbfffe344, Glu=0x413c2900)
at SuperLU/SRC/dpivotL.c:122
#1 0x41395e91 in dgstrf (refact=0xbfffe3fb "N\230\"<A\004", A=0xbfffe400,
diag_pivot_thresh=1, drop_tol=0, relax=5, panel_size=10, etree=0x8b9c968,
work=0x0, lwork=0, perm_r=0x8b9c918, perm_c=0x8b9c908, L=0xbfffe580,
U=0xbfffe560, info=0xbfffe47c) at SuperLU/SRC/dgstrf.c:308
#2 0x41395847 in dgssv (A=0xbfffe5c0, perm_c=0x8b9c908, perm_r=0x8b9c918,
L=0xbfffe580, U=0xbfffe560, B=0xbfffe540, info=0xbfffe47c)
at SuperLU/SRC/dgssv.c:175
#3 0x4137114a in oct_binop_s_f_ldiv(octave_value const&, octave_value const&)
(a1=@0x8bda570, a2=@0x8988c10) at sparse_ops.cc:1014
#4 0x4017a636 in do_binary_op(octave_value::binary_op, octave_value const&, octave_value const&) (op=op_ldiv, v1=@0xbfffe700, v2=@0xbfffe710) at ov.h:246
#5 0x4019382f in tree_binary_expression::rvalue() (this=0x8b9c860) at ov.h:246
#6 0x401932df in tree_binary_expression::rvalue(int) (this=0x8b9c860,
nargout=0) at oct-obj.h:50
#7 0x401b8a29 in tree_statement::eval(bool, int, bool) (this=0x8bc7d08,
silent=false, nargout=0, in_function_body=0) at oct-obj.h:78
#8 0x401b8f61 in tree_statement_list::eval(bool, int) (this=0x8b9c888,
silent=false, nargout=0) at oct-obj.h:78
#9 0x40140634 in main_loop(std::string const&) (fun_to_call=@0x40377f48)
at toplev.cc:155
#10 0x401d4ef2 in octave_main (argc=1, argv=0xbfffec44, embedded=0)
at octave.cc:612
#11 0x08049948 in main (argc=1, argv=0xbfffec44) at main.c:35
#12 0x40fe2280 in __libc_start_main () from /lib/libc.so.6
So *pivrow in dpivotL is greater than 2 in your case.... The only
real solution I can suggest is to write an oct-file that calls the
[dz]gscon function of SuperLU first to test the condition number before
trying a solution.
In the long run the only real solution is to modify SuperLU so that
it gracefully fails on badly conditioned matrices. Alternatively in
the ldiv and inverse functions of the octave-forge package call
[dz]gscon prior to the left-division or inverse to ensure a well
conditioned matrix..
Regards
David
--
David Bateman Dav...@mo...
Motorola CRM +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary
|
|
From: David B. <Dav...@mo...> - 2003-06-10 12:46:15
|
You are probably right. But in this case a test should be added for the version of perl to ensure that the file is compiled correctly. I have a 5.6.1 version installed and it works. On an old redhat 7.2 machine I have 5.005_03 and it has similar issues to what you have seen. At this point without know which version work, a warning should probably be given if the version in earlier than 5.6.0 cheers David According to Kay Lehmann <kay...@we...> (on 06/10/03): > On Tue, 2003-06-10 at 12:46, David Bateman wrote: > > Your file comms.txi is completely stuffed up as it has multiple versions > > of each section. It seems that there might have been a cvs checkout problem.. > > Can you remove it and do a cvs update to recover it. It also seems to be > > correct in the latest release... > > > > Cheers > > David > > > Hmm, > > this is a little bit weired. First of all I have to say that I use > latest release and comms.txi is exactly the same as in cvs. So I think > this is a problem with the mkdoc and mktexi scripts which are used in > the comm-module to create the texi-file. To be exactly: it seems to be a > problem with perl-version, which comes with FreeBSD4. Maybe it is to > old? It's version 5.00503. I have tested my theory with FreeBSD5.1, > which comes with perl5.6 and now it is working without any problems. > > So, thanks again for your help. > Greetings, > Kay > -- > Kay Lehmann <kay...@we...> -- David Bateman Dav...@mo... Motorola CRM +33 1 69 35 25 00 (Ph) Espace Technologique, Commune de St Aubin +33 1 69 35 25 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |
|
From: Kay L. <kay...@we...> - 2003-06-10 12:07:07
|
On Tue, 2003-06-10 at 12:46, David Bateman wrote: > Your file comms.txi is completely stuffed up as it has multiple versions > of each section. It seems that there might have been a cvs checkout problem.. > Can you remove it and do a cvs update to recover it. It also seems to be > correct in the latest release... > > Cheers > David > Hmm, this is a little bit weired. First of all I have to say that I use latest release and comms.txi is exactly the same as in cvs. So I think this is a problem with the mkdoc and mktexi scripts which are used in the comm-module to create the texi-file. To be exactly: it seems to be a problem with perl-version, which comes with FreeBSD4. Maybe it is to old? It's version 5.00503. I have tested my theory with FreeBSD5.1, which comes with perl5.6 and now it is working without any problems. So, thanks again for your help. Greetings, Kay -- Kay Lehmann <kay...@we...> |
|
From: David B. <Dav...@mo...> - 2003-06-10 10:48:41
|
Your file comms.txi is completely stuffed up as it has multiple versions of each section. It seems that there might have been a cvs checkout problem.. Can you remove it and do a cvs update to recover it. It also seems to be correct in the latest release... Cheers David According to Kay Lehmann <kay...@we...> (on 06/10/03): > Am Sa, 2003-05-10 um 11.22 schrieb David Bateman: > > This is weird.. Can you type "make comms.texi" in the main/comm directory > > and send me the comms.texi file it generates? I can't seem to generate the > > same problem. Could you also type "makeinfo --version" and tell me what version > > of makeinfo you have installed.. > > > > Cheers > > David > > > > > Hello, > > first of all I want to thank you for your answer. Here are the infos you > wanted: > > makeinfo --version: makeinfo (GNU texinfo) 4.2 > > comms.texi is attached (gziped). > > Thanks for your help. > Greetings, > Kay > -- > Kay Lehmann <kay...@we...> -- David Bateman Dav...@mo... Motorola CRM +33 1 69 35 25 00 (Ph) Espace Technologique, Commune de St Aubin +33 1 69 35 25 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |
|
From: Kay L. <kay...@we...> - 2003-06-10 10:29:16
|
Am Sa, 2003-05-10 um 11.22 schrieb David Bateman: > This is weird.. Can you type "make comms.texi" in the main/comm directory > and send me the comms.texi file it generates? I can't seem to generate the > same problem. Could you also type "makeinfo --version" and tell me what version > of makeinfo you have installed.. > > Cheers > David > > Hello, first of all I want to thank you for your answer. Here are the infos you wanted: makeinfo --version: makeinfo (GNU texinfo) 4.2 comms.texi is attached (gziped). Thanks for your help. Greetings, Kay -- Kay Lehmann <kay...@we...> |
|
From: David B. <Dav...@mo...> - 2003-06-10 09:23:33
|
This is weird.. Can you type "make comms.texi" in the main/comm directory and send me the comms.texi file it generates? I can't seem to generate the same problem. Could you also type "makeinfo --version" and tell me what version of makeinfo you have installed.. Cheers David According to Kay Lehmann <kay...@we...> (on 06/08/03): > Hello, > > I try to build a Port for Freebsd, but I have some problems building the > docs from the comm-package, which I don't know how to solve. The > Versions I use are: > octave-2.1.39 and octave-forge 2003.06.02 > Error messages are: > > Making texinfo comms.texi > Making info comms.info > comms.texi:2445: Node `Linear Algebra' previously defined at line 2099. > comms.texi:2499: Node `Signal Processing' previously defined at line > 2153. > comms.texi:2574: Node `Function Reference' previously defined at line > 2228. > comms.texi:2793: Node `Linear Algebra' previously defined at line 2099. > comms.texi:2847: Node `Signal Processing' previously defined at line > 2153. > comms.texi:2922: Node `Function Reference' previously defined at line > 2228. > comms.texi:3143: Node `Linear Algebra' previously defined at line 2099. > comms.texi:3197: Node `Signal Processing' previously defined at line > 2153. > comms.texi:3272: Node `Function Reference' previously defined at line > 2228. > comms.texi:3495: Node `Linear Algebra' previously defined at line 2099. > comms.texi:3549: Node `Signal Processing' previously defined at line > 2153. > .... > and so on. Everything else seems fine. Can somebody tell me how to fix > this? > > Thanks in advance. > Kay Lehmann > > -- > Kay Lehmann <kay...@we...> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The best > thread debugger on the planet. Designed with thread debugging features > you've never dreamed of, try TotalView 6 free at www.etnus.com. > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev -- David Bateman Dav...@mo... Motorola CRM +33 1 69 35 25 00 (Ph) Espace Technologique, Commune de St Aubin +33 1 69 35 25 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |
|
From: Quentin S. <qsp...@ie...> - 2003-06-10 06:05:19
|
I think I mentioned on one of the lists a while ago that I had written a spec file for generating RPM binaries, and I recall RPM binaries being mentioned recently by someone else. The file I currently have has two strings that will change from one build to the next: the current octave version and current octave-forge version. I would like to make it so these are taken care of automatically, but I'm trying to figure out when this should happen. The octave version is detected at the configure stage. The octave-forge version is not detected anywhere that I can tell, but it is set in release.sh. I suppose it may be possible to grep OCTAVE_FORGE_VERSION.m to find it out when configuring, but I'm not sure what makes the most sense and I'm not that familiar with the GNU autotools. Suggestions? Quentin Spencer |
|
From: Kay L. <kay...@we...> - 2003-06-08 16:50:44
|
Hello, I try to build a Port for Freebsd, but I have some problems building the docs from the comm-package, which I don't know how to solve. The Versions I use are: octave-2.1.39 and octave-forge 2003.06.02 Error messages are: Making texinfo comms.texi Making info comms.info comms.texi:2445: Node `Linear Algebra' previously defined at line 2099. comms.texi:2499: Node `Signal Processing' previously defined at line 2153. comms.texi:2574: Node `Function Reference' previously defined at line 2228. comms.texi:2793: Node `Linear Algebra' previously defined at line 2099. comms.texi:2847: Node `Signal Processing' previously defined at line 2153. comms.texi:2922: Node `Function Reference' previously defined at line 2228. comms.texi:3143: Node `Linear Algebra' previously defined at line 2099. comms.texi:3197: Node `Signal Processing' previously defined at line 2153. comms.texi:3272: Node `Function Reference' previously defined at line 2228. comms.texi:3495: Node `Linear Algebra' previously defined at line 2099. comms.texi:3549: Node `Signal Processing' previously defined at line 2153. .... and so on. Everything else seems fine. Can somebody tell me how to fix this? Thanks in advance. Kay Lehmann -- Kay Lehmann <kay...@we...> |
|
From: Paul K. <pki...@ja...> - 2003-06-02 15:05:13
|
Okay, I finally got a new release out. Our page views are still going up for some reason despite our inactivity. Maybe that's due to the categorical index being there. I'm amused to see that a google search for e.g., ellipke lists octave-forge in the first page. Someone with the time and the skills might want to make it look and feel better, because right now it is a bit awkward and ugly. We already display the source to the function if it is in octave-forge by linking directly to CVS page. We could do this for the octave functions as well using http://www.octave.org/cgi-bin/cvsweb.cgi/octave. Right now I have to manually rebuild the index which means it only gets done for octave-forge releases. We might be able to do this automatically on the source-forge server if the proper tools are available. Any takers? <Machiavellian> Moving the octave wiki to source forge could increase our page views (except we might have to put some content into it). As for download statistics, tracking new octave releases with binaries for windows and red hat would do it without too much real work. </Machiavellian> Paul Kienzle pki...@us... |
|
From: Paul K. <pki...@us...> - 2003-05-24 22:08:29
|
WJ Atsma wrote: > Hello, > > I added this segment to symbols.cc, findsymbols.cc in main/symbolic, > copied from sumterms.cc (thank you Paul) to let it compile with > 2.1.48. Can someone tell me where NEED_OCTAVE_QUIT is defined and what > the conditions are for it being defined (for my further education in > matters octave). octave-forge/configure adds -DNEED_OCTAVE_QUIT to the mkoctfile command for older versions of Octave which do not have quit.h. - Paul |
|
From: WJ A. <oc...@wy...> - 2003-05-24 16:51:02
|
Hello,
I added this segment to symbols.cc, findsymbols.cc in main/symbolic,=20
copied from sumterms.cc (thank you Paul) to let it compile with 2.1.48.=20
Can someone tell me where NEED_OCTAVE_QUIT is defined and what the=20
conditions are for it being defined (for my further education in=20
matters octave).
#ifdef NEED_OCTAVE_QUIT
#define OCTAVE_QUIT do {} while (0)
#else
#include <octave/quit.h>
#endif
The updates are in cvs.
cheers,
Willem Atsma
|
|
From: Per P. <per...@ma...> - 2003-05-22 15:06:39
|
I got (and commited) a patch from David Bateman that fixes the final issue on OS X. All set for a release! /Per |
|
From: Simon C. <si...@li...> - 2003-05-22 09:53:29
|
Greetings, I've recently noticed that is_vector(X) and is_matrix(X) both return true if X is a scalar. is_matrix(X) also returns true if X is vector. I found a message [1] reporting this problem in 1997 and a follow-up message claiming that the problem was fixed [2]. However, the problem seems to still exist in Octave 2.1.35. Is this how is_vector and is_matrix are meant to behave? I noticed the problem when calling mesh(X,Y,Z) with three vectors (i.e. while trying to plot the points <X(i),Y(i),Z(i)>). mesh complains because it attempts to interpret its input as if Z was a matrix (since is_matrix(Z) returns true). [1] http://www.octave.org/octave-lists/archive/bug-octave.1997/msg00153.html [2] http://www.octave.org/octave-lists/archive/bug-octave.1997/msg00159.html Schiavo Simon -- - - - - - - - - - - - - - - - - 4979 486 380 (llec) :leT 9383 056 120 (krow) ten.az.noulg@nomis :liam-E - - - - - - - - - - - - - - - - |
|
From: David B. <Dav...@mo...> - 2003-05-22 09:31:09
|
Ok, Try the attached patch. Unfortunately I can't commit this at the moment, so depending on the urgency of the release perhaps someone else might liek to commit it Cheers David According to Per Persson <per...@ma...> (on 05/22/03): > Nope, > that problem was with CVS as of yesterday. I have Makeinfo installed. > > The problem is with the install_doc target. > Reverting to the previous version fixes the problem. > > The problem is that when install_doc is executed, there is no > $(MPATH)/comm directory > I think you can reproduce the problem by removing $(MPATH)/comm and run > make install. > If you can't then something very fishy is going on. > > /P > > > On torsdag, maj 22, 2003, at 10:12 Europe/Stockholm, David Bateman > wrote: > > >Can you checkout or update your cvs and try against. About 4 days > >ago I updated the main/comm/ Makefile, configure.add and Makeconf.add > >so that if you don't have makeinfo installed it won't try to install > >the documentation. So I believe the problem you describe should now > >be fixed. -- David Bateman Dav...@mo... Motorola CRM +33 1 69 35 25 00 (Ph) Espace Technologique, Commune de St Aubin +33 1 69 35 25 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |
|
From: David B. <Dav...@mo...> - 2003-05-22 08:12:41
|
Can you checkout or update your cvs and try against. About 4 days ago I updated the main/comm/ Makefile, configure.add and Makeconf.add so that if you don't have makeinfo installed it won't try to install the documentation. So I believe the problem you describe should now be fixed. D. According to Per Persson <per...@ma...> (on 05/21/03): > So far the only problem I've had is with installing comm docs. > > The problem (I think) is the target install_doc, which assumes(?) that > $(MPATH)/comms/comms.info exists. > Install barfs at that point. Output from 'install -d': > [snip] > Considering target file `install_doc'. > File `install_doc' does not exist. > Finished prerequisites of target file `install_doc'. > Must remake target `install_doc'. > Putting child 0x000430e0 (install_doc) PID 14548 on the chain. > Live child 0x000430e0 (install_doc) PID 14548 > /usr/bin/install: > /usr/local/share/octave/2.1.48/site/m/octave-forge/comm/comms.info: No > such file or directory > Got a SIGCHLD; 1 unreaped children. > Reaping losing child 0x000430e0 PID 14548 > make: *** [install_doc] Error 71 > Removing child 0x000430e0 PID 14548 from chain. > > I really don't know what to do to fix it... > Hints?! > > If we could get this fixed together with the cp flags in octinst.sh OS > X would be all set for release. > > /P > > ------------ > Per Persson > Blekinge Institute of Technology > Dept. of Signal Processing and Telecommunications > > www: http://www.its.bth.se/staff/pee > e-mail: per...@bt... > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > Octave-dev mailing list > Oct...@li... > https://lists.sourceforge.net/lists/listinfo/octave-dev -- David Bateman Dav...@mo... Motorola CRM +33 1 69 35 25 00 (Ph) Espace Technologique, Commune de St Aubin +33 1 69 35 25 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |
|
From: Paul K. <pki...@ja...> - 2003-05-21 20:47:51
|
On Wed, May 21, 2003 at 09:08:32PM +0200, Per Persson wrote: > On Thursday, May 15, 2003, at 11:34 PM, Paul Kienzle wrote: > > > > * administration: > > - target specific build instructions (MacOSX, windows, Irix) > > > > Could someone confirm that the following patches are OK on non-OSX > systems (and generally acceptable)? They look fine (but I haven't tested them) and are acceptable short term. Longer term I should figure out a better way of indicating which links to make at install time rather than trying to copy the linked files. Really long term, Octave should have a better way to indicate that routine xxx is located in object file yyy rather than relying on symbolic links in the file system, but that's a topic for another list. - Paul |
|
From: Per P. <per...@ma...> - 2003-05-21 19:10:15
|
On Thursday, May 15, 2003, at 11:34 PM, Paul Kienzle wrote:
> * Communications:
> - sqrt over Galois field
> - BCH code, modulator
> - bug fixes and documentation improvements
I'm still having a problem with the install_doc target in
main/comms/Makefile on OS X (described in a previous mail).
>
> * administration:
> - target specific build instructions (MacOSX, windows, Irix)
>
Could someone confirm that the following patches are OK on non-OSX
systems (and generally acceptable)?
/Per
Index: configure.base
===================================================================
RCS file: /cvsroot/octave/octave-forge/configure.base,v
retrieving revision 1.14
diff -u -w -r1.14 configure.base
--- configure.base 15 May 2003 16:05:50 -0000 1.14
+++ configure.base 21 May 2003 18:31:12 -0000
@@ -224,6 +224,15 @@
AC_PROG_INSTALL
AC_PROG_RANLIB
+dnl Use $(COPY_FLAGS) to set options for cp when installing .oct files.
+COPY_FLAGS="-fdp"
+case "$canonical_host_type" in
+ powerpc-apple-darwin*)
+ COPY_FLAGS="-Rfp"
+ ;;
+esac
+AC_SUBST(COPY_FLAGS)
+
dnl Use $(STRIP) in the makefile to strip executables. If not found,
dnl STRIP expands to ':', which in the makefile does nothing.
dnl Don't need this for .oct files since mkoctfile handles them
directly
Index: octinst.sh.in
===================================================================
RCS file: /cvsroot/octave/octave-forge/octinst.sh.in,v
retrieving revision 1.4
diff -u -w -r1.4 octinst.sh.in
--- octinst.sh.in 9 Mar 2003 02:34:44 -0000 1.4
+++ octinst.sh.in 21 May 2003 18:56:57 -0000
@@ -21,6 +21,7 @@
INSTALL_DATA="@INSTALL_DATA@"
INSTALL_PROGRAM="@INSTALL_PROGRAM@"
MKPKGADD="@TOPDIR@/admin/mkpkgadd"
+COPY_FLAGS="@COPY_FLAGS@"
# grab the m-files
files=`echo $source/*.m`
@@ -34,7 +35,7 @@
if test "$files" != "$source/*.oct" ; then
$INSTALL -d $opath
## Grrr... install doesn't preserve links. Hope this works.
- cp -fdp $files $opath
+ cp $COPY_FLAGS $files $opath
fi
# create PKG_ADD
------------
Per Persson
Blekinge Institute of Technology
Dept. of Signal Processing and Telecommunications
www: http://www.its.bth.se/staff/pee
e-mail: per...@bt...
|
|
From: Per P. <per...@ma...> - 2003-05-21 17:12:59
|
So far the only problem I've had is with installing comm docs. The problem (I think) is the target install_doc, which assumes(?) that $(MPATH)/comms/comms.info exists. Install barfs at that point. Output from 'install -d': [snip] Considering target file `install_doc'. File `install_doc' does not exist. Finished prerequisites of target file `install_doc'. Must remake target `install_doc'. Putting child 0x000430e0 (install_doc) PID 14548 on the chain. Live child 0x000430e0 (install_doc) PID 14548 /usr/bin/install: /usr/local/share/octave/2.1.48/site/m/octave-forge/comm/comms.info: No such file or directory Got a SIGCHLD; 1 unreaped children. Reaping losing child 0x000430e0 PID 14548 make: *** [install_doc] Error 71 Removing child 0x000430e0 PID 14548 from chain. I really don't know what to do to fix it... Hints?! If we could get this fixed together with the cp flags in octinst.sh OS X would be all set for release. /P ------------ Per Persson Blekinge Institute of Technology Dept. of Signal Processing and Telecommunications www: http://www.its.bth.se/staff/pee e-mail: per...@bt... |
|
From: Chris C. <ch...@ch...> - 2003-05-21 16:42:20
|
On Tue May 20 2003 10:53 am, David Bateman wrote:
> Please don't do this!!! comms.texi is made from comms.txi
> texi2html and texinfo programs. These require texinfo and tex to be
> installed.
I had managed to get tex installed without texinfo. The build failed out
with an obscure error message ("error 141"), but after I checked all the
requirements you listed I realized that texinfo was missing.
Everything built OK after installing texinfo.
thanks,
Chris Caudle
|
|
From: David B. <Dav...@mo...> - 2003-05-21 07:50:01
|
According to Paul Kienzle <pki...@us...> (on 05/21/03): > David Bateman wrote: > > >At this point I haven't made a test to see whether perl is installed, > >but if it isn't you are bound to have other problems in the admin > >directory... Is it worth disabling the build of comms.texi from > >comms.txi if perl is not found? If so shoudl the test for perl be > >made in configure.base or in main/comm/configure.add? > > > I'm inclined to assume perl for now, but minimize its use. > The only systems that won't have perl readily available > are probably windows systems, and most of those folks > will be using prebuilt octave/octave-forge. In this case a test for perl should be added to configure.base, with a configure error resulting in its absence..... Cheers David -- David Bateman Dav...@mo... Motorola CRM +33 1 69 35 25 00 (Ph) Espace Technologique, Commune de St Aubin +33 1 69 35 25 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary |
541 messages has been excluded from this view by a project administrator.
