From lindnerben at gmx.net Mon Nov 2 14:04:44 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Mon, 02 Nov 2009 21:04:44 +0100 Subject: gnulib and automake In-Reply-To: <4AEC90A2.5000909@gmx.net> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> Message-ID: <4AEF3B5C.201@gmx.net> Benjamin Lindner wrote: > John W. Eaton wrote: >> I updated the patch here: >> >> http://jweaton.org/automake-diffs.gz >> >> Please start with this newer version of the patch if you decide to try >> any further debugging. >> > > sure, > I'll start a new clean trial and report back. > It seems that one prerequisite to get shared libraries built using libtool, one has to specify "-no-undefined" as libtool's link options. See e.g. http://readlist.com/lists/lists.sourceforge.net/mingw-users/0/3404.html What it the correct way in automake to get this flag into the link options (preferably only for the *-*-mingw* platform)? I now patch all makefile.in files, but these are generated (by automake I guess). I couldn't find the source for the link commands as libcruft_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \ $(CXXFLAGS) $(libcruft_la_LDFLAGS) $(LDFLAGS) -o $@ which I modified to libcruft_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CXXLD) -no-undefined $(AM_CXXFLAGS) \ $(CXXFLAGS) $(libcruft_la_LDFLAGS) $(LDFLAGS) -o $@ but that's not really a nice solution. Is there an additional libtool makefile variable, something like $(libtool_LDFLAGS) ? Or can one define an additional individual variable like $(libtool_NOUNDEFINED) which is empty by default, and set to "-no-undefined" for mingw platform? benjamin From jwe at octave.org Mon Nov 2 15:08:59 2009 From: jwe at octave.org (John W. Eaton) Date: Mon, 2 Nov 2009 16:08:59 -0500 Subject: gnulib and automake In-Reply-To: <4AEF3B5C.201@gmx.net> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> Message-ID: <19183.19051.712300.979144@segfault.lan> On 2-Nov-2009, Benjamin Lindner wrote: | Benjamin Lindner wrote: | > John W. Eaton wrote: | >> I updated the patch here: | >> | >> http://jweaton.org/automake-diffs.gz | >> | >> Please start with this newer version of the patch if you decide to try | >> any further debugging. | >> | > | > sure, | > I'll start a new clean trial and report back. | > | | It seems that one prerequisite to get shared libraries built using | libtool, one has to specify "-no-undefined" as libtool's link options. | See e.g. | http://readlist.com/lists/lists.sourceforge.net/mingw-users/0/3404.html | | What it the correct way in automake to get this flag into the link | options (preferably only for the *-*-mingw* platform)? | | I now patch all makefile.in files, but these are generated (by automake | I guess). I couldn't find the source for the link commands as | | libcruft_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \ | $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \ | $(CXXFLAGS) $(libcruft_la_LDFLAGS) $(LDFLAGS) -o $@ | | which I modified to | | libcruft_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \ | $(LIBTOOLFLAGS) --mode=link $(CXXLD) -no-undefined $(AM_CXXFLAGS) \ | $(CXXFLAGS) $(libcruft_la_LDFLAGS) $(LDFLAGS) -o $@ | | but that's not really a nice solution. | | Is there an additional libtool makefile variable, something like | $(libtool_LDFLAGS) ? | Or can one define an additional individual variable like | $(libtool_NOUNDEFINED) which is empty by default, and set to | "-no-undefined" for mingw platform? Does the following change work for you? 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/20091102/dcb43c6f/attachment.ksh From jwe at octave.org Mon Nov 2 15:29:08 2009 From: jwe at octave.org (John W. Eaton) Date: Mon, 2 Nov 2009 16:29:08 -0500 Subject: libtool and mkoctfile Message-ID: <19183.20260.190284.974800@segfault.lan> I would like to make the mkoctfile script use libtool to create .oct files, the same as we will soon be using in the Makefiles that build the .oct files that are part of Octave. I think I have most of the details worked out, but one problem remains. Libtool is a Unix shell script, so we will need to do something for Windows systems. Is it reasonable for Octave to require a Unix command shell and the associated commands that libtool requires for building .oct files? If not, then I suppose that when Octave is built, we could try to extract from libtool the commands that it would run, and embed those in the mkoctfile script/program, though I'm not sure how to do that in a reliable way. If we do go this route, then I would like to consider again eliminating the mkoctfile script and keeping only the C++ program. Having both seems like asking for trouble as the two are likely to get out of sync. It seems easier to me to just package a Unix shelland the necessary commands for Windows systems, then eliminate the C++ version of mkoctfile. If you object to including a Unix shell, why? Suppose that libtool were written in Perl. Would you also object to including perl in the distribution so that Octave could run the libtool script? Octave already includes a perl function. Do we distribute a copy of Perl with Octave on Windows systems so that the perl function can work? Comments? jwe From thomas.weber.mail at gmail.com Tue Nov 3 01:49:33 2009 From: thomas.weber.mail at gmail.com (Thomas Weber) Date: Tue, 3 Nov 2009 08:49:33 +0100 Subject: libtool and mkoctfile In-Reply-To: <19183.20260.190284.974800@segfault.lan> References: <19183.20260.190284.974800@segfault.lan> Message-ID: <20091103074933.GB9652@atlan> On Mon, Nov 02, 2009 at 04:29:08PM -0500, John W. Eaton wrote: > I would like to make the mkoctfile script use libtool to create .oct > files, the same as we will soon be using in the Makefiles that build > the .oct files that are part of Octave. I think I have most of the > details worked out, but one problem remains. Libtool is a Unix shell > script, so we will need to do something for Windows systems. Is it > reasonable for Octave to require a Unix command shell and the > associated commands that libtool requires for building .oct files? http://gnuwin32.sourceforge.net/packages/libtool.htm Or is this the wrong program? Thomas From godfrey at isl.stanford.edu Tue Nov 3 08:59:30 2009 From: godfrey at isl.stanford.edu (Michael D. Godfrey) Date: Tue, 03 Nov 2009 06:59:30 -0800 Subject: automake on Fedora FC11 x86_64 Message-ID: <4AF04552.3040203@isl.stanford.edu> I tried the current source with the automake patch on my Fedora x86_64 system. It compiled and passed make check without problems. Congratulations. Michael From jwe at octave.org Tue Nov 3 09:35:11 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 3 Nov 2009 10:35:11 -0500 Subject: libtool and mkoctfile In-Reply-To: <20091103074933.GB9652@atlan> References: <19183.20260.190284.974800@segfault.lan> <20091103074933.GB9652@atlan> Message-ID: <19184.19887.614106.260044@segfault.lan> On 3-Nov-2009, Thomas Weber wrote: | On Mon, Nov 02, 2009 at 04:29:08PM -0500, John W. Eaton wrote: | > I would like to make the mkoctfile script use libtool to create .oct | > files, the same as we will soon be using in the Makefiles that build | > the .oct files that are part of Octave. I think I have most of the | > details worked out, but one problem remains. Libtool is a Unix shell | > script, so we will need to do something for Windows systems. Is it | > reasonable for Octave to require a Unix command shell and the | > associated commands that libtool requires for building .oct files? | | http://gnuwin32.sourceforge.net/packages/libtool.htm | | Or is this the wrong program? That version is too old. But it still appears to be a Unix shell script, which requires a Unix shell interpreter to work. jwe From jwe at octave.org Tue Nov 3 09:42:57 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 3 Nov 2009 10:42:57 -0500 Subject: crashes when exiting octave and loading swig-wrapped code In-Reply-To: <69d8d540911030446t6493a000m263448ccb4c0cb81@mail.gmail.com> References: <1256107637.2953.67.camel@no> <19170.24794.771836.23727@segfault.lan> <69d8d540911030446t6493a000m263448ccb4c0cb81@mail.gmail.com> Message-ID: <19184.20353.765070.530354@segfault.lan> On 3-Nov-2009, Jaroslav Hajek wrote: | I inspected the code a bit, and the basic obstacle I see is the | octave_shlib::close method, which runs a hook function for each | registered function, and then forces dlclose() (or equivalent), even | though there may still be references to the shlib object. | | John, can you give me a clue why this is so? It was probably just a mistake caused by originally thinking that the only thing that would be loaded would be some functions that didn't create global or otherwise persistent data structures. In that case, I think it would always be OK to unload/reload without worrying about reference counts. | I would imagine a more straightforward implementation of octave_shlib, | being merely a reference-counted pointer to the library handle (or | zero). Then, dlclose would simply be called when the reference count | drops to zero - similar to array and all the other reference-counted | stuff. | | If this were true, classes defined via .oct files could simply attach | a copy of the originating octave_shlib into the class, ensuring that | the library won't be unloaded. Seems OK to me. | This could result in multiple loads of the same file into memory, if | it was modified after loading, but I didn't find any information that | this is not possible. If there is some global state created, I think it could cause trouble to load multiple copies. So maybe it would be better to simply refuse to reload unless the previous copy can be safely unloaded (i.e., the reference count is zero?). jwe From jwe at octave.org Tue Nov 3 14:33:36 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 3 Nov 2009 15:33:36 -0500 Subject: new file, oct-mem.h Message-ID: <19184.37792.960152.199370@segfault.lan> In the new file liboctave/oct-mem.h: // Fill by value, with a check for zero. This boils down to memset if value is // a POD zero. template inline void octave_fill (octave_idx_type n, const T& value, T *dest) { std::fill_n (dest, n, value); } template inline bool octave_fill_iszero (const T& value) { return value == T(); } template inline bool octave_fill_iszero (const std::complex& value) { return value.real () == T() && value.imag () == T(); } template inline bool octave_fill_iszero (const octave_int& value) { return value.value () == T(); } #define DEFINE_POD_FILL(T) \ inline void octave_fill (octave_idx_type n, const T& value, T *dest) \ { \ if (octave_fill_iszero (value)) \ std::memset (dest, 0, n * sizeof (T)); \ else \ std::fill_n (dest, n, value); \ } These rely on zero-valued floating point numbers having all bits zero, which is not guaranteed by C/C++. But it is guaranteed by the IEEE 754 format. I don't think it is a bad thing to require IEEE 754 (many things in Octave won't work properly without IEEE floating point math), but maybe we should state that assumption clearly with a configure test? Oh, OK, this requirement is more or less enforced now in octave_ieee_init. So maybe this is OK as it is, though I guess I would prefer to have a comment stating the assumption here, and perhaps also an easy way to disable this optimization if someone wanted to experiment with Octave on a system with a different floating point format. // Uninitialized allocation. Will not initialize memory for complex and octave_int. // Memory allocated by octave_new should be freed by octave_delete. template inline T *octave_new (octave_idx_type n) { return new T[n]; } template inline void octave_delete (T *ptr) { delete [] ptr; } #define DEFINE_POD_NEW_DELETE(T) \ template <> \ inline T *octave_new (octave_idx_type n) \ { return reinterpret_cast (new char[n * sizeof (T)]); } \ template <> \ inline void octave_delete (T *ptr) \ { delete [] reinterpret_cast (ptr); } Maybe a better name for this function would be "uninitialized_new" or "no_ctor_new" or something similar that states more clearly what the intent is? Otherwise, I think it will be easy to confuse them as just being wrappers around new/delete. jwe From lindnerben at gmx.net Wed Nov 4 02:50:58 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Wed, 04 Nov 2009 09:50:58 +0100 Subject: libtool and mkoctfile In-Reply-To: <19183.20260.190284.974800@segfault.lan> References: <19183.20260.190284.974800@segfault.lan> Message-ID: <20091104085058.227470@gmx.net> > I would like to make the mkoctfile script use libtool to create .oct > files, the same as we will soon be using in the Makefiles that build > the .oct files that are part of Octave. I think I have most of the > details worked out, but one problem remains. Libtool is a Unix shell > script, so we will need to do something for Windows systems. Is it > reasonable for Octave to require a Unix command shell and the > associated commands that libtool requires for building .oct files? Frankly, no. I'd like to return the question by asking is it *really* necessary to rely on a unix-sh-interpreter? I see mkoctfile as an integral part of Octave an if mkoctfile requires a unix-layer to run, then, well, you won't have a native windows binary any more. And I wouldn't see the point in providing mingw binaries with the additional necessity of a unix shell, when there's cygwin available which does exactly all this, and I guess much better. And what about msvc? There are no 'official' binaries, but octave can still be built with ms compilers I guess and run as native binary. What about the future development, what about e.g. x64 binaries? I'm not sure about unix-shells-for-win64-which-are-not-cygwin. Possibly cygwin is the better choice as unix layer - and then I'll end up again at the question, why provide mingw32/64 along with a unix shell interpreter when there is cygwin? Aside from the question of unix-sh-interpreter yes or no, I disagree to using libtool, at least for windows platform. Simply because libtool does not work properly for windows. There are problems creating shared libs, there are problems with compiler flags, there are problems with libtool dropping libraries from the command line at own gusto, there are problems with shared libstdc++. So I would most probably end up packaging a patched (i.e. hacked) version of libtool which I honestly could not support because i simply don't understand it myself. Using libtool for building octave is using it in a controlled, and kind of encapsuled environment where one knows the odds and ends and where you have a bunch of workaround tricks in your pocket. But distributing it and depending on it in open space, I believe will end up with many reports of "mkoctfile does not work for me" and us saying, "yes, we know, this is libtool". > If not, then I suppose that when Octave is built, we could try to > extract from libtool the commands that it would run, and embed those > in the mkoctfile script/program, though I'm not sure how to do that in > a reliable way. If we do go this route, then I would like to consider > again eliminating the mkoctfile script and keeping only the C++ > program. Having both seems like asking for trouble as the two are > likely to get out of sync. > > It seems easier to me to just package a Unix shelland the necessary > commands for Windows systems, then eliminate the C++ version of > mkoctfile. I'd like to stick to the C++ version of mkoctfile and I would have no problem with having a (windows) C++ version alongside the (common) shell version. You are right about having two versions and them possibly diverging, but how much development in the future do you honstly see in mkoctfile? How much new features do you plan to add to mkoctfile? I think that the additional effort of keeping the C++ version in pace with the shell version small compared to forcing a shell/libtool version for windows and maintaining it. I'd rather be one step behind with the C++ version than requiring a unix shell for it. To me, the C++ interface is octave's biggest bonus aside of it being free software. And to be able to use the C++ interface natively with a free compiler available on windows, I wouldn't want to miss that. > If you object to including a Unix shell, why? I'd object to having a unix shell as runtime requirement for octave. It'd end up in a windows binary depending on a unix layer, and that's cygwin. > Suppose that libtool > were written in Perl. Would you also object to including perl in the > distribution so that Octave could run the libtool script? Possibly. I have no experience with perl distributions for windows, so I cannot estimate the amount of effort it would require to include it. I'd probably stick to a C++ version of mkoctfile anyway. This is also getting a bit philosophical. At the current stage, windows binaries of octave do not require any privileges for installing a default user (who is not administrator) on windows doesn't have. It even doesn't require being "installed" at all, you can just copy it and run it off a usb stick, if you like. It doesn't need to fiddle with windows registry and it can be cleanly uninstalled or removed by simply deleting the directory tree it was installed to. Now beginning to add dependencies that don't follow this philosophy, may mean that octave is no longer portable, and octave must strictly be installed with administrative privileges. And this is IMO the wrong way to go. > Octave > already includes a perl function. Do we distribute a copy of Perl > with Octave on Windows systems so that the perl function can work? No, perl's not included. Now I'm curious. Which octave function is that? 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 Wed Nov 4 03:52:56 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 4 Nov 2009 10:52:56 +0100 Subject: libtool and mkoctfile In-Reply-To: <20091104085058.227470@gmx.net> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> Message-ID: <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> On Wed, Nov 4, 2009 at 9:50 AM, Benjamin Lindner wrote: > >> I would like to make the mkoctfile script use libtool to create .oct >> files, the same as we will soon be using in the Makefiles that build >> the .oct files that are part of Octave. ?I think I have most of the >> details worked out, but one problem remains. ?Libtool is a Unix shell >> script, so we will need to do something for Windows systems. ?Is it >> reasonable for Octave to require a Unix command shell and the >> associated commands that libtool requires for building .oct files? > > Frankly, no. I'd like to return the question by asking is it *really* necessary to rely on a unix-sh-interpreter? > I see mkoctfile as an integral part of Octave an if mkoctfile requires a unix-layer to run, then, well, you won't have a native windows binary any more. > And I wouldn't see the point in providing mingw binaries with the additional necessity of a unix shell, when there's cygwin available which does exactly all this, and I guess much better. > And what about msvc? There are no 'official' binaries, but octave can still be built with ms compilers I guess and run as native binary. > > What about the future development, what about e.g. x64 binaries? > I'm not sure about unix-shells-for-win64-which-are-not-cygwin. Possibly cygwin is the better choice as unix layer - and then I'll end up again at the question, why provide mingw32/64 along with a unix shell interpreter when there is cygwin? > > Aside from the question of unix-sh-interpreter yes or no, I disagree to using libtool, at least for windows platform. Simply because libtool does not work properly for windows. > There are problems creating shared libs, there are problems with compiler flags, there are problems with libtool dropping libraries from the command line at own gusto, there are problems with shared libstdc++. > So I would most probably end up packaging a patched (i.e. hacked) version of libtool which I honestly could not support because i simply don't understand it myself. > Using libtool for building octave is using it in a controlled, and kind of encapsuled environment where one knows the odds and ends and where you have a bunch of workaround tricks in your pocket. > But distributing it and depending on it in open space, I believe will end up with many reports of "mkoctfile does not work for me" and us saying, "yes, we know, this is libtool". > >> If not, then I suppose that when Octave is built, we could try to >> extract from libtool the commands that it would run, and embed those >> in the mkoctfile script/program, though I'm not sure how to do that in >> a reliable way. ?If we do go this route, then I would like to consider >> again eliminating the mkoctfile script and keeping only the C++ >> program. ?Having both seems like asking for trouble as the two are >> likely to get out of sync. >> >> It seems easier to me to just package a Unix shelland the necessary >> commands for Windows systems, then eliminate the C++ version of >> mkoctfile. > > I'd like to stick to the C++ version of mkoctfile and I would have no problem with having a (windows) C++ version alongside the (common) shell version. You are right about having two versions and them possibly diverging, but how much development in the future do you honstly see in mkoctfile? How much new features do you plan to add to mkoctfile? I think that the additional effort of keeping the C++ version in pace with the shell version small compared to forcing a shell/libtool version for windows and maintaining it. > I'd rather be one step behind with the C++ version than requiring a unix shell for it. > > To me, the C++ interface is octave's biggest bonus aside of it being free software. And to be able to use the C++ interface natively with a free compiler available on windows, I wouldn't want to miss that. > >> If you object to including a Unix shell, why? > > I'd object to having a unix shell as runtime requirement for octave. It'd end up in a windows binary depending on a unix layer, and that's cygwin. > >> Suppose that libtool >> were written in Perl. ?Would you also object to including perl in the >> distribution so that Octave could run the libtool script? > > Possibly. I have no experience with perl distributions for windows, so I cannot estimate the amount of effort it would require to include it. > I'd probably stick to a C++ version of mkoctfile anyway. > > This is also getting a bit philosophical. > > At the current stage, windows binaries of octave do not require any privileges for installing a default user (who is not administrator) on windows doesn't have. > It even doesn't require being "installed" at all, you can just copy it and run it off a usb stick, if you like. It doesn't need to fiddle with windows registry and it can be cleanly uninstalled or removed by simply deleting the directory tree it was installed to. > > Now beginning to add dependencies that don't follow this philosophy, may mean that octave is no longer portable, and octave must strictly be installed with administrative privileges. And this is IMO the wrong way to go. > >> Octave >> already includes a perl function. ?Do we distribute a copy of Perl >> with Octave on Windows systems so that the perl function can work? > > No, perl's not included. Now I'm curious. Which octave function is that? > > benjamin > -- The only perl script is octave/mk-opts.pl, and it is only used to recreate the option handlers DASPK-opts and similar. I think that like awk, bison, flex and gperf, perl is only needed to build from plain repo, but not from the distribution tarball. If libtool was only required for generating distrib tarballs, it would make little difference, but making it a requirement for mkoctfile would mean a significant change. Not just for Windows; unless I'm missing something, it would mean that dependency on libtool would be required for Octave packages in GNU/Linux distros as well. Regarding the question alone (whether to do this or not) I'm yet undecided. I need yet to read carefully John's rationale for the move to gnulib. -- 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 Wed Nov 4 09:39:18 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 4 Nov 2009 10:39:18 -0500 Subject: libtool and mkoctfile In-Reply-To: <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> Message-ID: <19185.40998.634807.594456@segfault.lan> On 4-Nov-2009, Jaroslav Hajek wrote: | The only perl script is octave/mk-opts.pl, and it is only used to | recreate the option handlers DASPK-opts and similar. I think that like | awk, bison, flex and gperf, perl is only needed to build from plain | repo, but not from the distribution tarball. There is also the perl function in the interpreter: `perl' is a function from the file /usr/share/octave/3.2.3/m/miscellaneous/perl.m -- Function File: [OUTPUT, STATUS] = perl (SCRIPTFILE) -- Function File: [OUTPUT, STATUS] = perl (SCRIPTFILE, ARGUMENT1, ARGUMENT2, ...) Invoke perl script SCRIPTFILE with possibly a list of command line arguments. Returns output in OUTPUT and status in STATUS. See also: system Other functions like tar/untar, zip/unzip, gzip/gunzip, etc. also depend on external programs. Are these all "native Windows" programs? If you say yes, then what makes something a "native Windows" program? A POSIX shell interpreter is just another program that interprets a particular command language. Isn't the Msys shell a "native Windows" program? Is a program written to depend on it not? I guess I don't understand where you draw the ine. In any case, we would not be exposing libtool or the shell to the Octave user. So I don't see the problem as anything other than having to distribute and install some additional programs with binary Octave distributions. People installing from source already have all of these tools. And you already need extra programs to be able to compile .oct or .mex files. | If libtool was only required for generating distrib tarballs, it would | make little difference, but making it a requirement for mkoctfile | would mean a significant change. Not just for Windows; unless I'm | missing something, it would mean that dependency on libtool would be | required for Octave packages in GNU/Linux distros as well. Yes, but libtool is just shell script. | Regarding the question alone (whether to do this or not) I'm yet | undecided. I need yet to read carefully John's rationale for the move | to gnulib. We currently use an odd mixture of old and homegrown code to replace missing functionality (things like fnmatch, glob, readdir, strftime, etc.). Mostly, we've picked up these functions from other packages at random points in time and rarely update them. The functions in gnulib are at least maintained and updated, and mostly better than versions that we might write ourselves. By using gnulib, the portability and replacement functions in Octave will be kept up to date automatically with little effort on our part. If there are bugs in these functions, then we will fix them in gnulib, and then all the users of gnulib will benefit, not just the users of Octave. Using gnulib without automake and libtool is just too much effort, so we really need to switch Octave's build system to use these tools. There are other benefits to using automake and libtool. First, we get correct dependency generation, and it is done simultaneously when compiling. Obsolete dependencies are also handled properly, so that will fix a longstanding bug in Octave's Makefiles. We get dist and clean targets in the Makefiles mostly for free. Dependency tracking for the configure script and Makefiles is handled correctly. With a little more effort, we could also have a build system that doesn't depend on GNU Make, but I don't see that as a high priority. Using libtool also has similar advantages to using gnulib. Rather than having to reinvent how to deal with shared libraries, we can take advantage of the knowledge built in to libtool. If mkoctfile does not use libtool, then we will still have to maintain the code in Octave's configure script that deals with building shared libraries. I'd rather delete all that and avoid duplicating what is already done by libtool. jwe From jwe at octave.org Wed Nov 4 09:49:20 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 4 Nov 2009 10:49:20 -0500 Subject: libtool and mkoctfile In-Reply-To: <20091104085058.227470@gmx.net> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> Message-ID: <19185.41600.307841.666569@segfault.lan> On 4-Nov-2009, Benjamin Lindner wrote: | Aside from the question of unix-sh-interpreter yes or no, I disagree | to using libtool, at least for windows platform. Simply because | libtool does not work properly for windows. If there are problems with libtool, then I think we should report them and try to get the problems fixed. That way everyone using libtool benefits. | At the current stage, windows binaries of octave do not require any | privileges for installing a default user (who is not administrator) | on windows doesn't have. Does installing the Msys shell and associated utilities (cp, mv, rm, etc.) require administrator privileges? | No, perl's not included. Now I'm curious. Which octave function is that? The perl function. jwe From soren at hauberg.org Wed Nov 4 11:39:36 2009 From: soren at hauberg.org (=?ISO-8859-1?Q?S=F8ren?= Hauberg) Date: Wed, 04 Nov 2009 18:39:36 +0100 Subject: libtool and mkoctfile In-Reply-To: <19183.20260.190284.974800@segfault.lan> References: <19183.20260.190284.974800@segfault.lan> Message-ID: <1257356376.3955.11.camel@sh-t400> man, 02 11 2009 kl. 16:29 -0500, skrev John W. Eaton: > I would like to make the mkoctfile script use libtool to create .oct > files, the same as we will soon be using in the Makefiles that build > the .oct files that are part of Octave. I think I have most of the > details worked out, but one problem remains. Libtool is a Unix shell > script, so we will need to do something for Windows systems. Is it > reasonable for Octave to require a Unix command shell and the > associated commands that libtool requires for building .oct files? I'm just following this from the side-line, so this is probably a stupid question... What is 'libtool' supposed to do here? Is it just supposed generate a set of compiler and linker flags that ensures that the .oct file can be generated? If so, are these flags the same every time 'mkoctfile' is called? If so, can't we just generate these flags when Octave is compiled instead of generating them at run-time? S?ren From highegg at gmail.com Wed Nov 4 11:44:00 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 4 Nov 2009 18:44:00 +0100 Subject: libtool and mkoctfile In-Reply-To: <19185.40998.634807.594456@segfault.lan> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <19185.40998.634807.594456@segfault.lan> Message-ID: <69d8d540911040944t5adcadb8mc39438e7056e36d3@mail.gmail.com> On Wed, Nov 4, 2009 at 4:39 PM, John W. Eaton wrote: > On ?4-Nov-2009, Jaroslav Hajek wrote: > > | The only perl script is octave/mk-opts.pl, and it is only used to > | recreate the option handlers DASPK-opts and similar. I think that like > | awk, bison, flex and gperf, perl is only needed to build from plain > | repo, but not from the distribution tarball. > > There is also the perl function in the interpreter: > > ?`perl' is a function from the file /usr/share/octave/3.2.3/m/miscellaneous/perl.m > > ? -- Function File: [OUTPUT, STATUS] = perl (SCRIPTFILE) > ? -- Function File: [OUTPUT, STATUS] = perl (SCRIPTFILE, ARGUMENT1, > ? ? ? ? ? ?ARGUMENT2, ...) > ? ? ? Invoke perl script SCRIPTFILE with possibly a list of command line > ? ? ? arguments. ?Returns output in OUTPUT and status in STATUS. > > ? ? ? See also: system > > Other functions like tar/untar, zip/unzip, gzip/gunzip, etc. also > depend on external programs. ?Are these all "native Windows" programs? > If you say yes, then what makes something a "native Windows" program? > A POSIX shell interpreter is just another program that interprets a > particular command language. ?Isn't the Msys shell a "native Windows" > program? ?Is a program written to depend on it not? ?I guess I don't > understand where you draw the ine. > Still, I daresay mkoctfile is usually much more important for most people. People won't expect "zip" to work unless zip is installed. > > In any case, we would not be exposing libtool or the shell to the > Octave user. ?So I don't see the problem as anything other than having > to distribute and install some additional programs with binary Octave > distributions. ?People installing from source already have all of these > tools. ?And you already need extra programs to be able to compile .oct > or .mex files. > > | If libtool was only required for generating distrib tarballs, it would > | make little difference, but making it a requirement for mkoctfile > | would mean a significant change. Not just for Windows; unless I'm > | missing something, it would mean that dependency on libtool would be > | required for Octave packages in GNU/Linux distros as well. > > Yes, but libtool is just shell script. > > | Regarding the question alone (whether to do this or not) I'm yet > | undecided. I need yet to read carefully John's rationale for the move > | to gnulib. > > We currently use an odd mixture of old and homegrown code to replace > missing functionality (things like fnmatch, glob, readdir, strftime, > etc.). ?Mostly, we've picked up these functions from other packages at > random points in time and rarely update them. ?The functions in gnulib > are at least maintained and updated, and mostly better than versions > that we might write ourselves. ?By using gnulib, the portability and > replacement functions in Octave will be kept up to date automatically > with little effort on our part. ?If there are bugs in these functions, > then we will fix them in gnulib, and then all the users of gnulib will > benefit, not just the users of Octave. > > Using gnulib without automake and libtool is just too much effort, so > we really need to switch Octave's build system to use these tools. > There are other benefits to using automake and libtool. ?First, we get > correct dependency generation, and it is done simultaneously when > compiling. ?Obsolete dependencies are also handled properly, so that > will fix a longstanding bug in Octave's Makefiles. ?We get dist and > clean targets in the Makefiles mostly for free. ?Dependency tracking > for the configure script and Makefiles is handled correctly. ?With a > little more effort, we could also have a build system that doesn't > depend on GNU Make, but I don't see that as a high priority. > > Using libtool also has similar advantages to using gnulib. ?Rather > than having to reinvent how to deal with shared libraries, we can take > advantage of the knowledge built in to libtool. > > If mkoctfile does not use libtool, then we will still have to maintain > the code in Octave's configure script that deals with building shared > libraries. ? I'd rather delete all that and avoid duplicating what is > already done by libtool. > If thanks to these changes Octave's code will become cleaner and more portable, then I suppose that justifies them well. I never knew of gnulib before, so I can't justify that. I hope it's no problem use libtool and gnulib with other compilers. One problem I see with gnulib is that it is C-centric rather than C++-centric. Have you also considered Boost? FSF recognizes the Boost software license as free and GPL compatible. Boost likewise provides portable I/O and memory facilities, special functions etc... Boost is extensively developed and maintained, and very portable. Some portions of Boost made it into the C++ standard, and some are planned in the future. Maybe Boost would be a better option for Octave? -- 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 Wed Nov 4 12:02:02 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 4 Nov 2009 13:02:02 -0500 Subject: libtool and mkoctfile In-Reply-To: <1257356376.3955.11.camel@sh-t400> References: <19183.20260.190284.974800@segfault.lan> <1257356376.3955.11.camel@sh-t400> Message-ID: <19185.49562.641185.158843@segfault.lan> On 4-Nov-2009, S?ren Hauberg wrote: | I'm just following this from the side-line, so this is probably a stupid | question... What is 'libtool' supposed to do here? Is it just supposed | generate a set of compiler and linker flags that ensures that the .oct | file can be generated? If so, are these flags the same every time | 'mkoctfile' is called? If so, can't we just generate these flags when | Octave is compiled instead of generating them at run-time? I don't know the reasoning behind the design choices that resulted in rules like LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) .c.lo: depbase=`echo $@ | sed 's|[^/]*$$|$(DEPDIR)/&|;s|\.lo$$||'`;\ $(LTCOMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ $< &&\ $(am__mv) $$depbase.Tpo $$depbase.Plo etc., and embedding the logic for precisely how to compile a source file or assemble a library inside the libtool script instead of exposing that logic directly in the Makefile (via apropriate automake/autoconf macros, for example). I don't see that this question is directly answered in the libtool documentation. Maybe this question should be directed tothe autoconf/automake/libtool developers? However, consider the alternative of eliminating the libtool script in favor of having the logic of the libtool script exposed in the Makefile itself. Then to use that logic in the mkoctfile script, we would have to duplicate it. But the Makefile rules would not be exactly what we need. This is the situation we have now with Octave's current build system. So it makes some sense to avoid the duplication and just put the logic in a single script that can be called from a Makefile or some other script. jwe From jwe at octave.org Wed Nov 4 12:23:43 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 4 Nov 2009 13:23:43 -0500 Subject: libtool and mkoctfile In-Reply-To: <69d8d540911040944t5adcadb8mc39438e7056e36d3@mail.gmail.com> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <19185.40998.634807.594456@segfault.lan> <69d8d540911040944t5adcadb8mc39438e7056e36d3@mail.gmail.com> Message-ID: <19185.50863.316733.700063@segfault.lan> On 4-Nov-2009, Jaroslav Hajek wrote: | If thanks to these changes Octave's code will become cleaner and more | portable, then I suppose that justifies them well. I never knew of | gnulib before, so I can't justify that. I hope it's no problem use | libtool and gnulib with other compilers. As far as I know, libtool and gnulib are not aimed only at GCC. | One problem I see with gnulib is that it is C-centric rather than | C++-centric. What I'm looking for is something that will handle replacing the core POSIX functions on systems that don't have them, or that have broken versions. Most often these days, that is Windows, isn't it? And these are relatively low-level functions defined with C language interfaces. So I don't see this as a problem. | Have you also considered Boost? FSF recognizes the Boost software | license as free and GPL compatible. | Boost likewise provides portable I/O and memory facilities, special | functions etc... | Boost is extensively developed and maintained, and very portable. Some | portions of Boost made it into the C++ standard, and some are planned | in the future. Maybe Boost would be a better option for Octave? I suppose Boost would be OK for higher level things. But it doesn't aim to provide replacements for readdir or strftime on systems that lack them, does it? jwe From octave at nomad.inbox5.com Wed Nov 4 12:39:46 2009 From: octave at nomad.inbox5.com (Rik) Date: Wed, 04 Nov 2009 10:39:46 -0800 Subject: new file, oct-mem.h In-Reply-To: References: Message-ID: > > These rely on zero-valued floating point numbers having all bits zero, > which is not guaranteed by C/C++. But it is guaranteed by the IEEE > 754 format. I don't think it is a bad thing to require IEEE 754 (many > things in Octave won't work properly without IEEE floating point > math), but maybe we should state that assumption clearly with a > configure test? Oh, OK, this requirement is more or less enforced now > in octave_ieee_init. So maybe this is OK as it is, though I guess I > would prefer to have a comment stating the assumption here, and perhaps > also an easy way to disable this optimization if someone wanted to > experiment with Octave on a system with a different floating point > format. > Isn't the configure check preferable in that it catches the assumption at compile time rather than run time? It would be annoying to spend 45 minutes compiling the sources only to have octave complain and demand to be re-compiled with the correct IEEE flags. But, perhaps I'm not understanding the situation. --Rik From tmacchant at yahoo.co.jp Wed Nov 4 14:45:24 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Thu, 5 Nov 2009 05:45:24 +0900 (JST) Subject: libtool and mkoctfile In-Reply-To: <19185.41600.307841.666569@segfault.lan> Message-ID: <20091104204524.42090.qmail@web3807.mail.bbt.yahoo.co.jp> Hello --- "John W. Eaton"wrote: > Does installing the Msys shell and associated utilities (cp, mv, rm, > etc.) require administrator privileges? Installing Msys with Msys1.0.11.exe requires administrator privileges. However this is perhaps for clean uninstalling by windows control panel. Msys+MinGW (with GCC) can work in a USB stick, if the drive name of USB drive is properly set in the ..../etc/fstab setting. I sometimes use Msys+MinGW in usb for use unixy commands and GCC in other computer. It requires to modify drive name in ..../etc/fstab e:/MinGW/ /mingw , f:/MinGW /mingw or g:/MinGW /mingw : : I always set the above manually. It is possible to get current drive with small program and modify it by sed of non-msys version. However I did not try it. Regards Tatsuro Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From lindnerben at gmx.net Wed Nov 4 15:38:47 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Wed, 04 Nov 2009 22:38:47 +0100 Subject: libtool and mkoctfile In-Reply-To: <19185.49562.641185.158843@segfault.lan> References: <19183.20260.190284.974800@segfault.lan> <1257356376.3955.11.camel@sh-t400> <19185.49562.641185.158843@segfault.lan> Message-ID: <4AF1F467.5030509@gmx.net> John W. Eaton wrote: > On 4-Nov-2009, S?ren Hauberg wrote: > > | I'm just following this from the side-line, so this is probably a stupid > | question... What is 'libtool' supposed to do here? Is it just supposed > | generate a set of compiler and linker flags that ensures that the .oct > | file can be generated? If so, are these flags the same every time > | 'mkoctfile' is called? If so, can't we just generate these flags when > | Octave is compiled instead of generating them at run-time? > > I don't know the reasoning behind the design choices that resulted in > rules like > > LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ > --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ > $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) > > .c.lo: > depbase=`echo $@ | sed 's|[^/]*$$|$(DEPDIR)/&|;s|\.lo$$||'`;\ > $(LTCOMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ $< &&\ > $(am__mv) $$depbase.Tpo $$depbase.Plo > > etc., and embedding the logic for precisely how to compile a source > file or assemble a library inside the libtool script instead of > exposing that logic directly in the Makefile (via apropriate > automake/autoconf macros, for example). I don't see that this > question is directly answered in the libtool documentation. Maybe > this question should be directed tothe autoconf/automake/libtool > developers? With all due respect, but at this point I'd like to re-raise the question, why are you trying to switch to libtool in the first place? What's so complex about compiling a source file and linking a library supposing for simplicity one is using the gnu compiler/linker suite? (Does libtool even support different compilers?) You have to tell libtool which additional libraries to link to, you have to tell libtool which {C|CPP|CXX|LD}FLAGS to use, you have to tell libtool via -I and -L where to search for files. So it does not ease your work here, and instead of a makefile rule like %.c : %.o $(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $< foo.dll : $(FOO_OBJ) $(CC) -shared $(LDFLAGS) $(LIBS) -o $@ $^ you end up with makefile rules which are fairly more complex and hard to reason. Besides, did you actually take a look at the code in libtool? I find it utterly confusing, complex, hard to understand and even harder to use. If I compare it to octave's current makefiles, then these are much cleaner, clearer and easier to adapt and maintain. They do not require any of the confusing logic embedded in libtool. And - most important of all - they work! > However, consider the alternative of eliminating the libtool script in > favor of having the logic of the libtool script exposed in the > Makefile itself. Then to use that logic in the mkoctfile script, we > would have to duplicate it. But the Makefile rules would not be > exactly what we need. This is the situation we have now with Octave's > current build system. So it makes some sense to avoid the duplication > and just put the logic in a single script that can be called from a > Makefile or some other script. Ok, my view is surely limited to windows platform, but I don't see the necessity to use all the logic that libtool uses (logic? what logic?), so there's no need in duplicating it, so that is not really a good argument to promote the use of libtool, IMO. Libtool actually complicates matters, not simplifies them. The mingw port of the gnu compiler is resposible for taking care of providing the correct flags to GNU ld, collecting the right crt libraries and system-specific object files. There is no extra compiler flag necesary to build a shared library, and there is no extra link flag execpt for "-shared". The gcc/binutils suite does a good job at this. libtool does not add anything there so I fail to see the gain in its use. benjamin From lindnerben at gmx.net Wed Nov 4 15:41:16 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Wed, 04 Nov 2009 22:41:16 +0100 Subject: libtool and mkoctfile In-Reply-To: <19185.40998.634807.594456@segfault.lan> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <19185.40998.634807.594456@segfault.lan> Message-ID: <4AF1F4FC.4050400@gmx.net> John W. Eaton wrote: > On 4-Nov-2009, Jaroslav Hajek wrote: > > | The only perl script is octave/mk-opts.pl, and it is only used to > | recreate the option handlers DASPK-opts and similar. I think that like > | awk, bison, flex and gperf, perl is only needed to build from plain > | repo, but not from the distribution tarball. > > There is also the perl function in the interpreter: > > `perl' is a function from the file /usr/share/octave/3.2.3/m/miscellaneous/perl.m > > -- Function File: [OUTPUT, STATUS] = perl (SCRIPTFILE) > -- Function File: [OUTPUT, STATUS] = perl (SCRIPTFILE, ARGUMENT1, > ARGUMENT2, ...) > Invoke perl script SCRIPTFILE with possibly a list of command line > arguments. Returns output in OUTPUT and status in STATUS. > > See also: system Well, it's a wrapper for "system". I cannot really expect octave to include a binary of every program a user might call using "system", can I? > Other functions like tar/untar, zip/unzip, gzip/gunzip, etc. also > depend on external programs. Are these all "native Windows" programs? That depends on which flavor of tar you have installed. Cygwin tar? Msys Tar? No these are not native versions. gnuwin32 tar? (don't know if such a thing exists) This would be a native version. > If you say yes, then what makes something a "native Windows" program? > A POSIX shell interpreter is just another program that interprets a > particular command language. Isn't the Msys shell a "native Windows" > program? Is a program written to depend on it not? I guess I don't > understand where you draw the ine. If an executable does not call native windows api but instead calls e.g. a posix intermediate layer which translates these calls to windows api calls, then this executable is not native. Cygwin provides a posix layer for windows, so a cygwin application is not native in this sense. Msys provides a posix layer for windows, so a msys application is again not native in this sense. Wine is a native unix application, but the application requiring wine to run isn't. > In any case, we would not be exposing libtool or the shell to the > Octave user. So I don't see the problem as anything other than having > to distribute and install some additional programs with binary Octave > distributions. People installing from source already have all of these > tools. And you already need extra programs to be able to compile .oct > or .mex files. No you don't. You need a compiler/linker, but you cannot get past that. But you don't need anything else. And creating an oct file is basically a simple one-line statement, which - given the experience - a user can call himself. mkoctfile.exe adds some convenience, as adding octave's include and library directories and provides octave's numerical libraries if you need them, and supports you when creating mex files. So it makes life a bit easier for the user. > | If libtool was only required for generating distrib tarballs, it would > | make little difference, but making it a requirement for mkoctfile > | would mean a significant change. Not just for Windows; unless I'm > | missing something, it would mean that dependency on libtool would be > | required for Octave packages in GNU/Linux distros as well. > > Yes, but libtool is just shell script. Yes, but to execute it, you need a shell interpreter, which you don't have in the first place in windows. If I distribute a batch script, then it's also "just a batch script", but you won't be able to execute it on a *nix system unless you get a window command line interpreter. > | Regarding the question alone (whether to do this or not) I'm yet > | undecided. I need yet to read carefully John's rationale for the move > | to gnulib. > > We currently use an odd mixture of old and homegrown code to replace > missing functionality (things like fnmatch, glob, readdir, strftime, > etc.). Mostly, we've picked up these functions from other packages at > random points in time and rarely update them. The functions in gnulib > are at least maintained and updated, and mostly better than versions > that we might write ourselves. By using gnulib, the portability and > replacement functions in Octave will be kept up to date automatically > with little effort on our part. If there are bugs in these functions, > then we will fix them in gnulib, and then all the users of gnulib will > benefit, not just the users of Octave. > > Using gnulib without automake and libtool is just too much effort, so > we really need to switch Octave's build system to use these tools. > There are other benefits to using automake and libtool. First, we get > correct dependency generation, and it is done simultaneously when > compiling. Obsolete dependencies are also handled properly, so that > will fix a longstanding bug in Octave's Makefiles. We get dist and > clean targets in the Makefiles mostly for free. Dependency tracking > for the configure script and Makefiles is handled correctly. With a > little more effort, we could also have a build system that doesn't > depend on GNU Make, but I don't see that as a high priority. But none of these points are necessary for mkoctfile, are they? Isn't it rather sarcastic, that a library as gnulib which aims at portability requires you to use libtool to get it built, which is anyting but portable? We are always assuming that one builds octave with a gcc compiler. How about msvc or e.g. the intel compilers? Are they supported by libtool? benjamin From lindnerben at gmx.net Wed Nov 4 15:44:30 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Wed, 04 Nov 2009 22:44:30 +0100 Subject: libtool and mkoctfile In-Reply-To: <19185.50863.316733.700063@segfault.lan> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <19185.40998.634807.594456@segfault.lan> <69d8d540911040944t5adcadb8mc39438e7056e36d3@mail.gmail.com> <19185.50863.316733.700063@segfault.lan> Message-ID: <4AF1F5BE.8010504@gmx.net> > > | One problem I see with gnulib is that it is C-centric rather than > | C++-centric. > > What I'm looking for is something that will handle replacing the core > POSIX functions on systems that don't have them, or that have broken > versions. Most often these days, that is Windows, isn't it? And > these are relatively low-level functions defined with C language > interfaces. So I don't see this as a problem. If you aim octave to rely on a posix base, then I guess at the end of the day, the only reasonable choice for windows platform is cygwin. benjamin From lindnerben at gmx.net Wed Nov 4 16:07:04 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Wed, 04 Nov 2009 23:07:04 +0100 Subject: libtool and mkoctfile In-Reply-To: <19185.41600.307841.666569@segfault.lan> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <19185.41600.307841.666569@segfault.lan> Message-ID: <4AF1FB08.7010504@gmx.net> John W. Eaton wrote: > On 4-Nov-2009, Benjamin Lindner wrote: > > | Aside from the question of unix-sh-interpreter yes or no, I disagree > | to using libtool, at least for windows platform. Simply because > | libtool does not work properly for windows. > > If there are problems with libtool, then I think we should report them > and try to get the problems fixed. That way everyone using libtool > benefits. I don't know what expereriences other developers have had, but I am tending to the other solution: don't use it, if it doesn't *really* help you and you can get where you want to anyway without it. For windows it simply doesn't make any sense to use it, just to get source code compiled and linked. Creating an oct file is a one-liner with the gnu compiler, and using a nearly-300K sized shell script to do the job seems - well - strange? As I said, requiring it for building octave is one thing, I wouldn't choose it as tool, but I respect your decision, and I think I can get it working somehow. Not OOTB, but with some hacking. But I don't see any reasonable point in having it a runtime requirement. > | At the current stage, windows binaries of octave do not require any > | privileges for installing a default user (who is not administrator) > | on windows doesn't have. > > Does installing the Msys shell and associated utilities (cp, mv, rm, > etc.) require administrator privileges? No, because they do not need to be "installed" in the windows-sense, but are distributed as binary archives which you can simply unzip and copy. There is also an installer available which might require administrative privileges, but I confess I never used it. I download the parts I need, unpack them and there you are. benjamin From jwe at octave.org Wed Nov 4 16:07:37 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 4 Nov 2009 17:07:37 -0500 Subject: libtool and mkoctfile In-Reply-To: <4AF1F467.5030509@gmx.net> References: <19183.20260.190284.974800@segfault.lan> <1257356376.3955.11.camel@sh-t400> <19185.49562.641185.158843@segfault.lan> <4AF1F467.5030509@gmx.net> Message-ID: <19185.64297.527396.220894@segfault.lan> On 4-Nov-2009, Benjamin Lindner wrote: | With all due respect, but at this point I'd like to re-raise the | question, why are you trying to switch to libtool in the first | place? In part because it makes it simpler to use gnulib, and I think that replacing parts of Octave with gnulib equivalents will be helpful and make Octave more portable and more reliable. | What's so complex about compiling a source file and linking a library | supposing for simplicity one is using the gnu compiler/linker suite? If we were only using GCC on say, GNU/Linux x86 systems, the task would be far simpler. But we are not, and I think using libtool is better than rediscovering all the possible options and methods for building share libraries on all the systems Octave can run on. | (Does libtool even support different compilers?) Yes. One of the points of libtool is to hide the complexity of building shared libraries on different systems. | You have to tell libtool which additional libraries to link to, you have | to tell libtool which {C|CPP|CXX|LD}FLAGS to use, The only options I think that you need to specify are the -L, -I, and -l options (i.e., where are the header files and libraries, and what are the names of the libraries). You don't have to know whether the compiler taks +Z or -fPIC or -Bshareable or -bundle -bundle_loader or wether the libraries are named .dll or .so or .sl or whatever. Libtool hides all of those details. I think that's a good thing. | you end up with makefile rules which are fairly more complex and hard to | reason. But I shouldn't need to look at those because they are generated by automake. The files I edit are the input files for automake, which are somewhat simpler. | don't need to lo | Besides, did you actually take a look at the code in libtool? | I find it utterly confusing, complex, hard to understand and even harder | to use. If I compare it to octave's current makefiles, then these are | much cleaner, clearer and easier to adapt and maintain. They do not | require any of the confusing logic embedded in libtool. And - most | important of all - they work! I'm sorry that you have such a negative attitude about this change. I have offered to help with the transition, but to do that, I will need some precise instructions about how to construct the same build environment that you have on a Windows system. So far, no one has posted any instructions that would help me do that, or pointed me to an existing document that clearly describes how to build Octave on a Windows system. | Libtool actually complicates matters, not simplifies them. >From my point of view, it does simplify things, because it will allow us to remove some fragile code from Octave's configuration script. | The mingw port of the gnu compiler is resposible for taking care of | providing the correct flags to GNU ld, collecting the right crt | libraries and system-specific object files. All the compiler front ends I know of do this job. | There is no extra compiler flag necesary to build a shared library, and | there is no extra link flag execpt for "-shared". The gcc/binutils suite | does a good job at this. Yet we still have *-*-mingw*) CPICFLAG= CXXPICFLAG= FPICFLAG= SHLEXT=dll SHLLIB=dll.a SHLBIN=dll DL_LDFLAGS="-shared -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc" SH_LDFLAGS="-shared -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--enable-auto-image-base" SONAME_FLAGS='-Wl,--out-implib=$@.a' library_path_var=PATH SCRIPTS_EXE_SUFFIX='$(EXEEXT)' ;; and *-*-msdosmsvc) DL_LDFLAGS="-shared" CPICFLAG= CXXPICFLAG= FPICFLAG= SHLEXT=dll SHLLIB=lib SHLBIN=dll LIBPRE= SHLPRE= SHLLIBPRE= SHLBINPRE= SH_LDFLAGS="-shared" if test -n "`echo $CFLAGS | grep -e '-g'`" -o -n "`echo $CXXFLAGS | grep -e '-g'`"; then DL_LDFLAGS="$DL_LDFLAGS -g" SH_LDFLAGS="$SH_LDFLAGS -g" fi NO_OCT_FILE_STRIP=true library_path_var=PATH NO_OCT_FILE_STRIP=true ## Extra compilation flags. CRUFT_DLL_DEFS="-DCRUFT_DLL" OCTAVE_DLL_DEFS="-DOCTAVE_DLL" OCTINTERP_DLL_DEFS="-DOCTINTERP_DLL" OCTGRAPHICS_DLL_DEFS="-DOCTGRAPHICS_DLL" SCRIPTS_EXE_SUFFIX='$(EXEEXT)' in the Octave configure script. All of this complexity would be gone. In a recent message, you said that you were able to build some parts of Octave with libtool, but that some things were still not working. What is not working? Again, I am willing to help with the transition, but I need to have some precise directions for setting up a build environment that is the same as yours so I can try to build Octave and see what the problems are. jwe From marco_atzeri at yahoo.it Wed Nov 4 16:00:19 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Wed, 4 Nov 2009 22:00:19 +0000 (GMT) Subject: libtool and mkoctfile In-Reply-To: <4AF1F5BE.8010504@gmx.net> Message-ID: <593845.54389.qm@web25502.mail.ukl.yahoo.com> --- Mer 4/11/09, Benjamin Lindner ha scritto: > Da: Benjamin Lindner > Oggetto: Re: libtool and mkoctfile > A: "John W. Eaton" > Cc: maintainers at octave.org > Data: Mercoled? 4 novembre 2009, 22:44 > > > > | One problem I see with gnulib is that it is > C-centric rather than > > | C++-centric. > > > > What I'm looking for is something that will handle > replacing the core > > POSIX functions on systems that don't have them, or > that have broken > > versions.? Most often these days, that is > Windows, isn't it?? And > > these are relatively low-level functions defined with > C language > > interfaces.? So I don't see this as a problem. > > If you aim octave to rely on a posix base, then I guess at > the end of the day, the only reasonable choice for windows > platform is cygwin. > > benjamin > I start to be worried...to much stress on the windows horizon. Just for your info I have not yet succeded to build octave with the new libtool stuff. I am currently investigating on: ------------------------------------------------------- *** Warning: This system can not link to static lib archive /bin/../lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. libtool: link: rm -fr .libs/liboctave.la.lnkscript *** Warning: linker path does not have real file for library -lcholmod. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libcholmod and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/lib/libcholmod.a ---------------------------------------------------------- Any other platform with similar issue ? It looks that libtool is wrongly guessing what to do. Marco From lindnerben at gmx.net Wed Nov 4 16:17:01 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Wed, 04 Nov 2009 23:17:01 +0100 Subject: libtool and mkoctfile In-Reply-To: <593845.54389.qm@web25502.mail.ukl.yahoo.com> References: <593845.54389.qm@web25502.mail.ukl.yahoo.com> Message-ID: <4AF1FD5D.6030908@gmx.net> Marco Atzeri wrote: > --- Mer 4/11/09, Benjamin Lindner ha scritto: > >> Da: Benjamin Lindner >> Oggetto: Re: libtool and mkoctfile >> A: "John W. Eaton" >> Cc: maintainers at octave.org >> Data: Mercoled? 4 novembre 2009, 22:44 >>> | One problem I see with gnulib is that it is >> C-centric rather than >>> | C++-centric. >>> >>> What I'm looking for is something that will handle >> replacing the core >>> POSIX functions on systems that don't have them, or >> that have broken >>> versions. Most often these days, that is >> Windows, isn't it? And >>> these are relatively low-level functions defined with >> C language >>> interfaces. So I don't see this as a problem. >> If you aim octave to rely on a posix base, then I guess at >> the end of the day, the only reasonable choice for windows >> platform is cygwin. >> >> benjamin >> > > I start to be worried...to much stress on the windows horizon. > > Just for your info I have not yet succeded to build octave > with the new libtool stuff. > I am currently investigating on: > ------------------------------------------------------- > *** Warning: This system can not link to static lib archive /bin/../lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.la. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > libtool: link: rm -fr .libs/liboctave.la.lnkscript > > *** Warning: linker path does not have real file for library -lcholmod. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have > *** because I did check the linker path looking for a file starting > *** with libcholmod and none of the candidates passed a file format test > *** using a file magic. Last file checked: /usr/lib/libcholmod.a > ---------------------------------------------------------- > > Any other platform with similar issue ? > It looks that libtool is wrongly guessing what to do. :) (sorry for me grinning - it's just I see that I am not the only one having problems with libtool) Yes I see the same issue. Only for me libtool is mocking about gcc's -liberty. I found the following ml thread http://lists.cairographics.org/archives/cairo/2009-July/017683.html and I also find, that patching (hacking?) libtool according to the answer here http://lists.cairographics.org/archives/cairo/2009-July/017684.html helps around this issue. benjamin From jwe at octave.org Wed Nov 4 16:17:59 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 4 Nov 2009 17:17:59 -0500 Subject: libtool and mkoctfile In-Reply-To: <4AF1F5BE.8010504@gmx.net> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <19185.40998.634807.594456@segfault.lan> <69d8d540911040944t5adcadb8mc39438e7056e36d3@mail.gmail.com> <19185.50863.316733.700063@segfault.lan> <4AF1F5BE.8010504@gmx.net> Message-ID: <19185.64919.940635.145570@segfault.lan> On 4-Nov-2009, Benjamin Lindner wrote: | If you aim octave to rely on a posix base, then I guess at the end of | the day, the only reasonable choice for windows platform is cygwin. No, I don't see it that way. It makes sense to me to write things like strftime (...); and then provide an strftime function on systems that do not have it rather than do something like #if defined (_MSVC) MSVC-spefic code here #elif defined (VMS) ... #elif defined (AMIGA) ... #elif defined (HAVE_STRFTIME) strftime (); #else #error BARF #endif everywhere the functionality of strftime is needed. Or even to encapsulate this myself. Why reinvent these interfaces? jwe From jwe at octave.org Wed Nov 4 16:24:35 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 4 Nov 2009 17:24:35 -0500 Subject: libtool and mkoctfile In-Reply-To: <4AF1F4FC.4050400@gmx.net> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <19185.40998.634807.594456@segfault.lan> <4AF1F4FC.4050400@gmx.net> Message-ID: <19185.65315.2155.637928@segfault.lan> On 4-Nov-2009, Benjamin Lindner wrote: | If an executable does not call native windows api but instead calls e.g. | a posix intermediate layer which translates these calls to windows api | calls, then this executable is not native. For MinGW or MSVC with POSIX library functions that ultimately calls the Windows API, I don't see the distinction. It's just a library that provides an interface. It doesn't somehow change the fact that the program runs on a Windows system. If I write my own (not POSIX) wrappers around the Windows API that provide a convenient interface to me, and then avoid using the Windows API directly, does that somehow make my program not a native Windows program? In the case of Cygwin, I do see a difference, because Cygwin programs assume that the view of the filesystem is POSIX (/cygdrive/c/foo/bar), not Windows (C:/foo/bar). So if these things are exposed users notice a difference when they can't open files using the names they are familiar with. jwe From marco_atzeri at yahoo.it Thu Nov 5 06:41:05 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Thu, 5 Nov 2009 12:41:05 +0000 (GMT) Subject: libtool and mkoctfile In-Reply-To: <4AF1FD5D.6030908@gmx.net> Message-ID: <573139.20555.qm@web25508.mail.ukl.yahoo.com> --- Mer 4/11/09, Benjamin Lindner ha scritto: > Da: Benjamin Lindner > Oggetto: Re: libtool and mkoctfile > A: "Marco Atzeri" > Cc: "John W. Eaton" , maintainers at octave.org > Data: Mercoled? 4 novembre 2009, 23:17 > Marco Atzeri wrote: > > --- Mer 4/11/09, Benjamin Lindner > ha scritto: > > > >> Da: Benjamin Lindner > >> Oggetto: Re: libtool and mkoctfile > >> A: "John W. Eaton" > >> Cc: maintainers at octave.org > >> Data: Mercoled? 4 novembre 2009, 22:44 > >>> | One problem I see with gnulib is that it is > >> C-centric rather than > >>> | C++-centric. > >>> > >>> What I'm looking for is something that will > handle > >> replacing the core > >>> POSIX functions on systems that don't have > them, or > >> that have broken > >>> versions.? Most often these days, that > is > >> Windows, isn't it?? And > >>> these are relatively low-level functions > defined with > >> C language > >>> interfaces.? So I don't see this as a > problem. > >> If you aim octave to rely on a posix base, then I > guess at > >> the end of the day, the only reasonable choice for > windows > >> platform is cygwin. > >> > >> benjamin > >> > > > > I start to be worried...to much stress on the windows > horizon. > > > > Just for your info I have not yet succeded to build > octave > > with the new libtool stuff. I am currently > investigating on: > > > ------------------------------------------------------- > > *** Warning: This system can not link to static lib > archive > /bin/../lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.la. > > *** I have the capability to make that library > automatically link in when > > *** you link to this library.? But I can only do > this if you have a > > *** shared version of the library, which you do not > appear to have. > > libtool: link: rm -fr? > .libs/liboctave.la.lnkscript > > > > *** Warning: linker path does not have real file for > library -lcholmod. > > *** I have the capability to make that library > automatically link in when > > *** you link to this library.? But I can only do > this if you have a > > *** shared version of the library, which you do not > appear to have > > *** because I did check the linker path looking for a > file starting > > *** with libcholmod and none of the candidates passed > a file format test > > *** using a file magic. Last file checked: > /usr/lib/libcholmod.a > > > ---------------------------------------------------------- > > > > Any other platform with similar issue ? It looks that > libtool is wrongly guessing what to do. > > :) > > (sorry for me grinning - it's just I see that I am not the > only one having problems with libtool) > > Yes I see the same issue. Only for me libtool is mocking > about gcc's -liberty. > > I found the following ml thread > http://lists.cairographics.org/archives/cairo/2009-July/017683.html > and I also find, that patching (hacking?) libtool according > to the answer here > http://lists.cairographics.org/archives/cairo/2009-July/017684.html > helps around this issue. > > benjamin Hi Benjamin, I think I catched the issue, at least on cygwin but probably it is similar on mingw. When linking with real static libs as for me suitsparse, I need to replace AMD_LIBS = -lamd with AMD_LIBS = -Wc,-lamd to advise libtool to forward the lib directly to the compiler for the linking. As there is a precedence issue I need also to add something more at the last of the Suitesparse libs. CXSPARSE_LIBS = -Wc,-lcxsparse -Wc,-llapack -Wc,-lblas -Wc,-lcygwin otherwise I have some undefined reference. I am still in the process to build the things, but at least the first roadblock seems gone. Marco From godfrey at isl.stanford.edu Thu Nov 5 07:02:50 2009 From: godfrey at isl.stanford.edu (Michael Godfrey) Date: Thu, 05 Nov 2009 14:02:50 +0100 Subject: Build error: __init_fltk__ missing Message-ID: <4AF2CCFA.5070203@isl.stanford.edu> Latest build using automake gives: error: feval: function `__init_fltk__' not found error: called from: error: /usr/local/share/octave/3.3.50+/m/plot/backend.m at line 56, column 5 error: /home/godfrey/.octaverc at line 1, column 0 ================================== after: backend("fltk"); From lindnerben at gmx.net Thu Nov 5 07:28:28 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Thu, 05 Nov 2009 14:28:28 +0100 Subject: libtool and mkoctfile In-Reply-To: <573139.20555.qm@web25508.mail.ukl.yahoo.com> References: <573139.20555.qm@web25508.mail.ukl.yahoo.com> Message-ID: <4AF2D2FC.3040708@gmx.net> > > Hi Benjamin, > I think I catched the issue, at least on cygwin but > probably it is similar on mingw. > > When linking with real static libs as for me suitsparse, > I need to replace > > AMD_LIBS = -lamd > > with > > AMD_LIBS = -Wc,-lamd > > to advise libtool to forward the lib directly to the compiler for the linking. Thanks for this information. I'll check if this also helps for mingw and the -liberty issue. Oh, I don't understand libtool and its philosophy at all. Now why do I need to tell libtool to pass-through a library to the compiler to get it linked. I simply don't understand it. The whole story boils down to subverting all the logic libtool with great effort tries to have, to just get the job done right. benjamin From godfrey at isl.stanford.edu Thu Nov 5 08:19:06 2009 From: godfrey at isl.stanford.edu (Michael Godfrey) Date: Thu, 05 Nov 2009 15:19:06 +0100 Subject: Build error: __init_fltk__ missing In-Reply-To: <4AF2CCFA.5070203@isl.stanford.edu> References: <4AF2CCFA.5070203@isl.stanford.edu> Message-ID: <4AF2DEDA.1090704@isl.stanford.edu> Build from same source without the automake patch runs OK. This is using Fedora FC11 x86_64. Michael From jwe at octave.org Thu Nov 5 08:30:47 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 5 Nov 2009 09:30:47 -0500 Subject: Build error: __init_fltk__ missing In-Reply-To: <4AF2DEDA.1090704@isl.stanford.edu> References: <4AF2CCFA.5070203@isl.stanford.edu> <4AF2DEDA.1090704@isl.stanford.edu> Message-ID: <19186.57751.558379.14011@segfault.lan> On 5-Nov-2009, Michael Godfrey wrote: | Build from same source without the automake patch | runs OK. | | This is using Fedora FC11 x86_64. It works for me on a Debian system. Is HAVE_FLTK defined in your config.h file with the patched version? If not, what does config.log tell you about FLTK library detection? jwe From jwe at octave.org Thu Nov 5 08:35:21 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 5 Nov 2009 09:35:21 -0500 Subject: Build error: __init_fltk__ missing In-Reply-To: <19186.57751.558379.14011@segfault.lan> References: <4AF2CCFA.5070203@isl.stanford.edu> <4AF2DEDA.1090704@isl.stanford.edu> <19186.57751.558379.14011@segfault.lan> Message-ID: <19186.58025.897219.693990@segfault.lan> On 5-Nov-2009, John W. Eaton wrote: | On 5-Nov-2009, Michael Godfrey wrote: | | | Build from same source without the automake patch | | runs OK. | | | | This is using Fedora FC11 x86_64. | | It works for me on a Debian system. Is HAVE_FLTK defined in your | config.h file with the patched version? If not, what does config.log | tell you about FLTK library detection? Oops, sorry, I see the problem now. The file src/DLD-FUNCTIONS/PKG_ADD is missing some entries. I'll see if I can fix that. jwe From jwe at octave.org Thu Nov 5 09:06:33 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 5 Nov 2009 10:06:33 -0500 Subject: Build error: __init_fltk__ missing In-Reply-To: <19186.58025.897219.693990@segfault.lan> References: <4AF2CCFA.5070203@isl.stanford.edu> <4AF2DEDA.1090704@isl.stanford.edu> <19186.57751.558379.14011@segfault.lan> <19186.58025.897219.693990@segfault.lan> Message-ID: <19186.59897.227311.279573@segfault.lan> On 5-Nov-2009, John W. Eaton wrote: | On 5-Nov-2009, John W. Eaton wrote: | | | On 5-Nov-2009, Michael Godfrey wrote: | | | | | Build from same source without the automake patch | | | runs OK. | | | | | | This is using Fedora FC11 x86_64. | | | | It works for me on a Debian system. Is HAVE_FLTK defined in your | | config.h file with the patched version? If not, what does config.log | | tell you about FLTK library detection? | | Oops, sorry, I see the problem now. The file | src/DLD-FUNCTIONS/PKG_ADD is missing some entries. I'll see if I can | fix that. Try the following change. You may also need to remove the src/DLD-FUNCTIONS/fltk_backend.df file from your build tree because the .df files don't list the Makefile as a dependency. 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/20091105/62054c46/attachment.ksh From highegg at gmail.com Thu Nov 5 14:19:40 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Thu, 5 Nov 2009 21:19:40 +0100 Subject: new file, oct-mem.h In-Reply-To: <19184.37792.960152.199370@segfault.lan> References: <19184.37792.960152.199370@segfault.lan> Message-ID: <69d8d540911051219x1eaa81ebl3ac38ba29ae6389@mail.gmail.com> On Tue, Nov 3, 2009 at 9:33 PM, John W. Eaton wrote: > In the new file liboctave/oct-mem.h: > > ?// Fill by value, with a check for zero. This boils down to memset if value is > ?// a POD zero. > ?template > ?inline void octave_fill (octave_idx_type n, const T& value, T *dest) > ?{ std::fill_n (dest, n, value); } > > ?template > ?inline bool octave_fill_iszero (const T& value) > ?{ return value == T(); } > > ?template > ?inline bool octave_fill_iszero (const std::complex& value) > ?{ return value.real () == T() && value.imag () == T(); } > > ?template > ?inline bool octave_fill_iszero (const octave_int& value) > ?{ return value.value () == T(); } > > ?#define DEFINE_POD_FILL(T) \ > ?inline void octave_fill (octave_idx_type n, const T& value, T *dest) \ > ?{ \ > ? ?if (octave_fill_iszero (value)) \ > ? ? ?std::memset (dest, 0, n * sizeof (T)); \ > ? ?else \ > ? ? ?std::fill_n (dest, n, value); \ > ?} > > These rely on zero-valued floating point numbers having all bits zero, > which is not guaranteed by C/C++. ?But it is guaranteed by the IEEE > 754 format. ?I don't think it is a bad thing to require IEEE 754 (many > things in Octave won't work properly without IEEE floating point > math), but maybe we should state that assumption clearly with a > configure test? ?Oh, OK, this requirement is more or less enforced now > in octave_ieee_init. ?So maybe this is OK as it is, though I guess I > would prefer to have a comment stating the assumption here, and perhaps > also an easy way to disable this optimization if someone wanted to > experiment with Octave on a system with a different floating point > format. > > ?// Uninitialized allocation. Will not initialize memory for complex and octave_int. > ?// Memory allocated by octave_new should be freed by octave_delete. > ?template > ?inline T *octave_new (octave_idx_type n) > ?{ return new T[n]; } > ?template > ?inline void octave_delete (T *ptr) > ?{ delete [] ptr; } > > ?#define DEFINE_POD_NEW_DELETE(T) \ > ?template <> \ > ?inline T *octave_new (octave_idx_type n) \ > ?{ return reinterpret_cast (new char[n * sizeof (T)]); } \ > ?template <> \ > ?inline void octave_delete (T *ptr) \ > ?{ delete [] reinterpret_cast (ptr); } > > Maybe a better name for this function would be "uninitialized_new" or > "no_ctor_new" or something similar that states more clearly what the > intent is? ?Otherwise, I think it will be easy to confuse them as just > being wrappers around new/delete. > > jwe > OK, I renamed the functions to more descriptive names: no_ctor_new, no_ctor_delete, copy_or_memcpy, fill_or_memset. I also changed the test for zero to use reinterpret_cast to a suitable unsigned integer type, so that it is does not actually rely on IEEE, even though it may be unnecessary. Here, it makes good sense because what one actually wants to test for is whether the fill-in value has zero memory pattern (which is typically true when arrays are resized). These changes speed up some indexing, indexed assignment and permuting for integer & complex types: memcpy is used instead of plain loops and memory is not uselessly zeroed after allocation. For single & double real matrices, sometimes no speed-up is visible, sometimes some 30%. The C++ standard library supplied with GCC optimizes std::copy to memmove for POD types. So it appears that using memmove to do a non-overlapping memory copy is sometimes equally fast as memcpy, but sometimes slower. It seems really interesting. In any case, indexing is somewhat more efficient again... -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz From thomas.weber.mail at gmail.com Thu Nov 5 16:48:28 2009 From: thomas.weber.mail at gmail.com (Thomas Weber) Date: Thu, 5 Nov 2009 23:48:28 +0100 Subject: libtool and mkoctfile In-Reply-To: <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> Message-ID: <20091105224828.GA6226@atlan> Hi, I'm picking Jaroslav's message for answering, but I hope I've added everybody currently involved into the CC. On Wed, Nov 04, 2009 at 10:52:56AM +0100, Jaroslav Hajek wrote: > On Wed, Nov 4, 2009 at 9:50 AM, Benjamin Lindner wrote: > > > >> I would like to make the mkoctfile script use libtool to create .oct > >> files, the same as we will soon be using in the Makefiles that build > >> the .oct files that are part of Octave. ?I think I have most of the > >> details worked out, but one problem remains. ?Libtool is a Unix shell > >> script, so we will need to do something for Windows systems. ?Is it > >> reasonable for Octave to require a Unix command shell and the > >> associated commands that libtool requires for building .oct files? > > > > Frankly, no. I'd like to return the question by asking is it *really* necessary to rely on a unix-sh-interpreter? > > I see mkoctfile as an integral part of Octave an if mkoctfile requires a unix-layer to run, then, well, you won't have a native windows binary any more. > > And I wouldn't see the point in providing mingw binaries with the additional necessity of a unix shell, when there's cygwin available which does exactly all this, and I guess much better. > > And what about msvc? There are no 'official' binaries, but octave can still be built with ms compilers I guess and run as native binary. > > > > What about the future development, what about e.g. x64 binaries? > > I'm not sure about unix-shells-for-win64-which-are-not-cygwin. Possibly cygwin is the better choice as unix layer - and then I'll end up again at the question, why provide mingw32/64 along with a unix shell interpreter when there is cygwin? > > > > Aside from the question of unix-sh-interpreter yes or no, I disagree to using libtool, at least for windows platform. Simply because libtool does not work properly for windows. > > There are problems creating shared libs, there are problems with compiler flags, there are problems with libtool dropping libraries from the command line at own gusto, there are problems with shared libstdc++. > > So I would most probably end up packaging a patched (i.e. hacked) version of libtool which I honestly could not support because i simply don't understand it myself. > > Using libtool for building octave is using it in a controlled, and kind of encapsuled environment where one knows the odds and ends and where you have a bunch of workaround tricks in your pocket. > > But distributing it and depending on it in open space, I believe will end up with many reports of "mkoctfile does not work for me" and us saying, "yes, we know, this is libtool". > > > >> If not, then I suppose that when Octave is built, we could try to > >> extract from libtool the commands that it would run, and embed those > >> in the mkoctfile script/program, though I'm not sure how to do that in > >> a reliable way. ?If we do go this route, then I would like to consider > >> again eliminating the mkoctfile script and keeping only the C++ > >> program. ?Having both seems like asking for trouble as the two are > >> likely to get out of sync. > >> > >> It seems easier to me to just package a Unix shelland the necessary > >> commands for Windows systems, then eliminate the C++ version of > >> mkoctfile. > > > > I'd like to stick to the C++ version of mkoctfile and I would have no problem with having a (windows) C++ version alongside the (common) shell version. You are right about having two versions and them possibly diverging, but how much development in the future do you honstly see in mkoctfile? How much new features do you plan to add to mkoctfile? I think that the additional effort of keeping the C++ version in pace with the shell version small compared to forcing a shell/libtool version for windows and maintaining it. > > I'd rather be one step behind with the C++ version than requiring a unix shell for it. > > > > To me, the C++ interface is octave's biggest bonus aside of it being free software. And to be able to use the C++ interface natively with a free compiler available on windows, I wouldn't want to miss that. > > > >> If you object to including a Unix shell, why? > > > > I'd object to having a unix shell as runtime requirement for octave. It'd end up in a windows binary depending on a unix layer, and that's cygwin. > > > >> Suppose that libtool > >> were written in Perl. ?Would you also object to including perl in the > >> distribution so that Octave could run the libtool script? > > > > Possibly. I have no experience with perl distributions for windows, so I cannot estimate the amount of effort it would require to include it. > > I'd probably stick to a C++ version of mkoctfile anyway. > > > > This is also getting a bit philosophical. > > > > At the current stage, windows binaries of octave do not require any privileges for installing a default user (who is not administrator) on windows doesn't have. > > It even doesn't require being "installed" at all, you can just copy it and run it off a usb stick, if you like. It doesn't need to fiddle with windows registry and it can be cleanly uninstalled or removed by simply deleting the directory tree it was installed to. > > > > Now beginning to add dependencies that don't follow this philosophy, may mean that octave is no longer portable, and octave must strictly be installed with administrative privileges. And this is IMO the wrong way to go. > > > >> Octave > >> already includes a perl function. ?Do we distribute a copy of Perl > >> with Octave on Windows systems so that the perl function can work? > > > > No, perl's not included. Now I'm curious. Which octave function is that? > > > > benjamin > > -- > > The only perl script is octave/mk-opts.pl, and it is only used to > recreate the option handlers DASPK-opts and similar. I think that like > awk, bison, flex and gperf, perl is only needed to build from plain > repo, but not from the distribution tarball. > > If libtool was only required for generating distrib tarballs, it would > make little difference, but making it a requirement for mkoctfile > would mean a significant change. Not just for Windows; unless I'm > missing something, it would mean that dependency on libtool would be > required for Octave packages in GNU/Linux distros as well. Okay, from my viewpoint of Debian maintainer: I would jump for joy when Octave uses libtool. In fact, two or three years ago I looked into adding libtool to Octave, but I gave up when I realized that Octave didn't use automake (which is not strictly necessary, but the libtool manual only documents the automake use case). libtool is not some esoteric tool, but sort of standard for libraries in the Unix-like world. Using such a tool means you can ask on normal distribution lists and there will be literally hundreds of people with experience on this topic. Whereas currently it means asking on the Octave lists and hoping that the few people here have an idea. Which, I might add, usually boils down to John in use cases like Solaris. Thus, I'd actually expect people to give him free reign in his decision or stand up and help the next time a question about Solaris comes up. Now, some things that came up in different mails in the thread, by different people: | For windows it simply doesn't make any sense to use it, just to get | source code compiled and linked. Creating an oct file is a one-liner | with the gnu compiler, and using a nearly-300K sized shell script to do | the job seems - well - strange? Yes, it takes one line. And it takes one line on Linux. And one line on Solaris. And one line on HP-UX. Unfortunately, these lines might differ on all of these systems. They might differ when using a different compiler. They might differ when using a different toolchain. Does anybody on this list know how to compile a shared library on VMS? I don't. But libtool does. http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html to get an idea of the fiddling required. | If libtool was only required for generating distrib tarballs, it would | make little difference, but making it a requirement for mkoctfile | would mean a significant change. Not just for Windows; unless I'm | missing something, it would mean that dependency on libtool would be | required for Octave packages in GNU/Linux distros as well. I already had to patch mkoctfile to make it work reliable in Debian (it hardcodes paths when building Octave, which makes up for problems when the compiler is updated). So, no, mkoctfile is not a simple one-size-fits-all solution. Is libtool better? I don't know. But there are certainly more people with knowledge about libtool than there are with knowledge about mkoctfile and compiler flags. | With all due respect, but at this point I'd like to re-raise the | question, why are you trying to switch to libtool in the first place? | What's so complex about compiling a source file and linking a library | supposing for simplicity one is using the gnu compiler/linker suite? | (Does libtool even support different compilers?) I can only wonder that people argue about portability in one sentence, yet don't care about totally different compilers and platforms in the other sentences. You want portability? Use proven tools. And yes, libtool is complex and actually pretty slow when run. The fact that it's still around after all these years should however be a sign that somehow, it's deemed useful. Thomas From lindnerben at gmx.net Fri Nov 6 03:44:38 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Fri, 06 Nov 2009 10:44:38 +0100 Subject: libtool and mkoctfile In-Reply-To: <20091105224828.GA6226@atlan> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <20091105224828.GA6226@atlan> Message-ID: <20091106094438.202040@gmx.net> > > Okay, from my viewpoint of Debian maintainer: I would jump for joy when > Octave uses libtool. > > In fact, two or three years ago I looked into adding libtool to Octave, > but I gave up when I realized that Octave didn't use automake (which is > not strictly necessary, but the libtool manual only documents the > automake use case). > > libtool is not some esoteric tool, but sort of standard for libraries in > the Unix-like world. Using such a tool means you can ask on normal > distribution lists and there will be literally hundreds of people with > experience on this topic. Whereas currently it means asking on the > Octave lists and hoping that the few people here have an idea. Which, I > might add, usually boils down to John in use cases like Solaris. Thus, > I'd actually expect people to give him free reign in his decision or > stand up and help the next time a question about Solaris comes up. I believe I stated that it's John's decision to move octave's build system to libtool and I'll respect his decision. I will try to walk along for the windows platform. I cannot yet tell if it will work, and I am not sure if I'd want to support the (maybe exclusively for windows) increased complexity, when cygwin provides much better supported posix compatibility and unix-way-of-life for windows. In a way libtool appeared esoteric to me. It does all sorts of strage things, complexly interwoven internally, supports some of gcc's flags, some not, decides which libraries to accept and which not (at own gusto?), doesn't tell you really what it's thinking, and then presents you with its decision not to create the library you asked for. And that happening for a gnu compiler and for a gnu compiler's library. That's were it is getting strange, and I haven't been able to follow libtool's resoning yet. Perhaps if one understands the internals, one will quickly know where to intercept. I admit that I do not rejoyce if octave moves to libtool. For the windows platform it adds complexity, and currently does not work. But hey that's only me, so be it. > Now, some things that came up in different mails in the thread, by > different people: > > | For windows it simply doesn't make any sense to use it, just to get > | source code compiled and linked. Creating an oct file is a one-liner > | with the gnu compiler, and using a nearly-300K sized shell script to do > | the job seems - well - strange? > > Yes, it takes one line. And it takes one line on Linux. And one line on > Solaris. And one line on HP-UX. > Unfortunately, these lines might differ on all of these systems. They > might differ when using a different compiler. They might differ when > using a different toolchain. Does anybody on this list know how to > compile a shared library on VMS? I don't. But libtool does. > > http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html > to get an idea of the fiddling required. Granted. Neither do I know. But this is - and I realise that this is a very egocentric point of view - no real bonus if for the one platform I use it does not. And it's some fiddling to get it working on windows. It's a cool tool if it works, but if it doesn't it is getting really complex. > | If libtool was only required for generating distrib tarballs, it would > | make little difference, but making it a requirement for mkoctfile > | would mean a significant change. Not just for Windows; unless I'm > | missing something, it would mean that dependency on libtool would be > | required for Octave packages in GNU/Linux distros as well. > > I already had to patch mkoctfile to make it work reliable in Debian (it > hardcodes paths when building Octave, which makes up for problems when > the compiler is updated). So, no, mkoctfile is not a simple > one-size-fits-all solution. > > Is libtool better? I don't know. But there are certainly more people > with knowledge about libtool than there are with knowledge about > mkoctfile and compiler flags. > > | With all due respect, but at this point I'd like to re-raise the > | question, why are you trying to switch to libtool in the first place? > | What's so complex about compiling a source file and linking a library > | supposing for simplicity one is using the gnu compiler/linker suite? > | (Does libtool even support different compilers?) > > I can only wonder that people argue about portability in one sentence, > yet don't care about totally different compilers and platforms in the > other sentences. You want portability? Use proven tools. And yes, > libtool is complex and actually pretty slow when run. The fact that it's > still around after all these years should however be a sign that > somehow, it's deemed useful. Yes that may be so. libtool's mingw history is short - the first release for msys environment is from august this year. gnuwin32's version is 1.5.26 (feb-2008) and there have been no updates yet. Maybe for good reason, I don't know. So if it wouldn't be for msys's version I'd probably had to build it myself, and I'm not sure I'd call it proven then. I realise that my view is rather narrow-focused with respect to interoperability and different platforms. And that my reactions have been - well - emotional. I apologize, I did not intend to discredit either persons or platforms. I guess windows is the one system which is out of line. Wouldn't be the first time for that. And it's also still around after all these years. libtool appears like a big multifunctional too which aims to support many or possibly all types of screws, ones commonly used, other maybe more exotic or rare. It comes highly recommended for its plurality and I see that many people use it. And now I find that for the particular type of screw I use, it does not fit. And I play around a bit, at the end of the day I get a bit irritated. And I start to ask myself why use this tool when there is a nice adapter available, or a small screwdriver at hand which does very nicely. Again: I'm not exactly a fan of libtool on windows. I respect John's decision, I will try to get it working. It doesn't make it easier, rather the other way round. I am honestly not sure about mkoctfile as shell script with libtool for windows. 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 Fri Nov 6 04:17:02 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 6 Nov 2009 11:17:02 +0100 Subject: libtool and mkoctfile In-Reply-To: <20091105224828.GA6226@atlan> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <20091105224828.GA6226@atlan> Message-ID: <69d8d540911060217l2f0c0d12gce8072930280cbbc@mail.gmail.com> On Thu, Nov 5, 2009 at 11:48 PM, Thomas Weber wrote: > Hi, > > I'm picking Jaroslav's message for answering, but I hope I've added > everybody currently involved into the CC. > > On Wed, Nov 04, 2009 at 10:52:56AM +0100, Jaroslav Hajek wrote: >> On Wed, Nov 4, 2009 at 9:50 AM, Benjamin Lindner wrote: >> > >> >> I would like to make the mkoctfile script use libtool to create .oct >> >> files, the same as we will soon be using in the Makefiles that build >> >> the .oct files that are part of Octave. ?I think I have most of the >> >> details worked out, but one problem remains. ?Libtool is a Unix shell >> >> script, so we will need to do something for Windows systems. ?Is it >> >> reasonable for Octave to require a Unix command shell and the >> >> associated commands that libtool requires for building .oct files? >> > >> > Frankly, no. I'd like to return the question by asking is it *really* necessary to rely on a unix-sh-interpreter? >> > I see mkoctfile as an integral part of Octave an if mkoctfile requires a unix-layer to run, then, well, you won't have a native windows binary any more. >> > And I wouldn't see the point in providing mingw binaries with the additional necessity of a unix shell, when there's cygwin available which does exactly all this, and I guess much better. >> > And what about msvc? There are no 'official' binaries, but octave can still be built with ms compilers I guess and run as native binary. >> > >> > What about the future development, what about e.g. x64 binaries? >> > I'm not sure about unix-shells-for-win64-which-are-not-cygwin. Possibly cygwin is the better choice as unix layer - and then I'll end up again at the question, why provide mingw32/64 along with a unix shell interpreter when there is cygwin? >> > >> > Aside from the question of unix-sh-interpreter yes or no, I disagree to using libtool, at least for windows platform. Simply because libtool does not work properly for windows. >> > There are problems creating shared libs, there are problems with compiler flags, there are problems with libtool dropping libraries from the command line at own gusto, there are problems with shared libstdc++. >> > So I would most probably end up packaging a patched (i.e. hacked) version of libtool which I honestly could not support because i simply don't understand it myself. >> > Using libtool for building octave is using it in a controlled, and kind of encapsuled environment where one knows the odds and ends and where you have a bunch of workaround tricks in your pocket. >> > But distributing it and depending on it in open space, I believe will end up with many reports of "mkoctfile does not work for me" and us saying, "yes, we know, this is libtool". >> > >> >> If not, then I suppose that when Octave is built, we could try to >> >> extract from libtool the commands that it would run, and embed those >> >> in the mkoctfile script/program, though I'm not sure how to do that in >> >> a reliable way. ?If we do go this route, then I would like to consider >> >> again eliminating the mkoctfile script and keeping only the C++ >> >> program. ?Having both seems like asking for trouble as the two are >> >> likely to get out of sync. >> >> >> >> It seems easier to me to just package a Unix shelland the necessary >> >> commands for Windows systems, then eliminate the C++ version of >> >> mkoctfile. >> > >> > I'd like to stick to the C++ version of mkoctfile and I would have no problem with having a (windows) C++ version alongside the (common) shell version. You are right about having two versions and them possibly diverging, but how much development in the future do you honstly see in mkoctfile? How much new features do you plan to add to mkoctfile? I think that the additional effort of keeping the C++ version in pace with the shell version small compared to forcing a shell/libtool version for windows and maintaining it. >> > I'd rather be one step behind with the C++ version than requiring a unix shell for it. >> > >> > To me, the C++ interface is octave's biggest bonus aside of it being free software. And to be able to use the C++ interface natively with a free compiler available on windows, I wouldn't want to miss that. >> > >> >> If you object to including a Unix shell, why? >> > >> > I'd object to having a unix shell as runtime requirement for octave. It'd end up in a windows binary depending on a unix layer, and that's cygwin. >> > >> >> Suppose that libtool >> >> were written in Perl. ?Would you also object to including perl in the >> >> distribution so that Octave could run the libtool script? >> > >> > Possibly. I have no experience with perl distributions for windows, so I cannot estimate the amount of effort it would require to include it. >> > I'd probably stick to a C++ version of mkoctfile anyway. >> > >> > This is also getting a bit philosophical. >> > >> > At the current stage, windows binaries of octave do not require any privileges for installing a default user (who is not administrator) on windows doesn't have. >> > It even doesn't require being "installed" at all, you can just copy it and run it off a usb stick, if you like. It doesn't need to fiddle with windows registry and it can be cleanly uninstalled or removed by simply deleting the directory tree it was installed to. >> > >> > Now beginning to add dependencies that don't follow this philosophy, may mean that octave is no longer portable, and octave must strictly be installed with administrative privileges. And this is IMO the wrong way to go. >> > >> >> Octave >> >> already includes a perl function. ?Do we distribute a copy of Perl >> >> with Octave on Windows systems so that the perl function can work? >> > >> > No, perl's not included. Now I'm curious. Which octave function is that? >> > >> > benjamin >> > -- >> >> The only perl script is octave/mk-opts.pl, and it is only used to >> recreate the option handlers DASPK-opts and similar. I think that like >> awk, bison, flex and gperf, perl is only needed to build from plain >> repo, but not from the distribution tarball. >> >> If libtool was only required for generating distrib tarballs, it would >> make little difference, but making it a requirement for mkoctfile >> would mean a significant change. Not just for Windows; unless I'm >> missing something, it would mean that dependency on libtool would be >> required for Octave packages in GNU/Linux distros as well. > > Okay, from my viewpoint of Debian maintainer: I would jump for joy when > Octave uses libtool. > > In fact, two or three years ago I looked into adding libtool to Octave, > but I gave up when I realized that Octave didn't use automake (which is > not strictly necessary, but the libtool manual only documents the > automake use case). > > libtool is not some esoteric tool, but sort of standard for libraries in > the Unix-like world. Using such a tool means you can ask on normal > distribution lists and there will be literally hundreds of people with > experience on this topic. ?Whereas currently it means asking on the > Octave lists and hoping that the few people here have an idea. Which, I > might add, usually boils down to John in use cases like Solaris. Thus, > I'd actually expect people to give him free reign in his decision or > stand up and help the next time a question about Solaris comes up. > > Now, some things that came up in different mails in the thread, by > different people: > > | For windows it simply doesn't make any sense to use it, just to get > | source code compiled and linked. Creating an oct file is a one-liner > | with the gnu compiler, and using a nearly-300K sized shell script to do > | the job seems - well - strange? > > Yes, it takes one line. And it takes one line on Linux. And one line on > Solaris. And one line on HP-UX. > Unfortunately, these lines might differ on all of these systems. They > might differ when using a different compiler. They might differ when > using a different toolchain. Does anybody on this list know how to > compile a shared library on VMS? I don't. But libtool does. > > http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html > to get an idea of the fiddling required. > > | If libtool was only required for generating distrib tarballs, it would > | make little difference, but making it a requirement for mkoctfile > | would mean a significant change. Not just for Windows; unless I'm > | missing something, it would mean that dependency on libtool would be > | required for Octave packages in GNU/Linux distros as well. > > I already had to patch mkoctfile to make it work reliable in Debian (it > hardcodes paths when building Octave, which makes up for problems when > the compiler is updated). So, no, mkoctfile is not a simple > one-size-fits-all solution. > > Is libtool better? I don't know. But there are certainly more people > with knowledge about libtool than there are with knowledge about > mkoctfile and compiler flags. > > | With all due respect, but at this point I'd like to re-raise the > | question, why are you trying to switch to libtool in the first place? > | What's so complex about compiling a source file and linking a library > | supposing for simplicity one is using the gnu compiler/linker suite? > | (Does libtool even support different compilers?) > > I can only wonder that people argue about portability in one sentence, > yet don't care about totally different compilers and platforms in the > other sentences. You want portability? Use proven tools. And yes, > libtool is complex and actually pretty slow when run. This might be a drawback. How slow? Some packages require mkoctfile to be run a dozen times to build ... -- 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 Nov 6 05:15:50 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 6 Nov 2009 12:15:50 +0100 Subject: libtool and mkoctfile In-Reply-To: <20091106094438.202040@gmx.net> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <20091105224828.GA6226@atlan> <20091106094438.202040@gmx.net> Message-ID: <69d8d540911060315q45558c7es3b42b982f32cdaf7@mail.gmail.com> On Fri, Nov 6, 2009 at 10:44 AM, Benjamin Lindner wrote: >> >> Okay, from my viewpoint of Debian maintainer: I would jump for joy when >> Octave uses libtool. >> >> In fact, two or three years ago I looked into adding libtool to Octave, >> but I gave up when I realized that Octave didn't use automake (which is >> not strictly necessary, but the libtool manual only documents the >> automake use case). >> >> libtool is not some esoteric tool, but sort of standard for libraries in >> the Unix-like world. Using such a tool means you can ask on normal >> distribution lists and there will be literally hundreds of people with >> experience on this topic. ?Whereas currently it means asking on the >> Octave lists and hoping that the few people here have an idea. Which, I >> might add, usually boils down to John in use cases like Solaris. Thus, >> I'd actually expect people to give him free reign in his decision or >> stand up and help the next time a question about Solaris comes up. > > I believe I stated that it's John's decision > to move octave's build system to libtool and I'll respect > his decision. > I will try to walk along for the windows platform. > I cannot yet tell if it will work, and I am not sure if > I'd want to support the (maybe exclusively for windows) > increased complexity, when cygwin provides much better > supported posix compatibility and unix-way-of-life for > windows. > > In a way libtool appeared esoteric to me. It does all sorts > of strage things, complexly interwoven internally, > supports some of gcc's flags, some not, decides which > libraries to accept and which not (at own gusto?), doesn't > tell you really what it's thinking, and then presents > you with its decision not to create the library > you asked for. And that happening for a gnu compiler and for > a gnu compiler's library. That's were it is getting strange, > and I haven't been able to follow libtool's resoning yet. > Perhaps if one understands the internals, one will > quickly know where to intercept. > > I admit that I do not rejoyce if octave moves to libtool. > For the windows platform it adds complexity, and currently > does not work. > But hey that's only me, so be it. > >> Now, some things that came up in different mails in the thread, by >> different people: >> >> | For windows it simply doesn't make any sense to use it, just to get >> | source code compiled and linked. Creating an oct file is a one-liner >> | with the gnu compiler, and using a nearly-300K sized shell script to do >> | the job seems - well - strange? >> >> Yes, it takes one line. And it takes one line on Linux. And one line on >> Solaris. And one line on HP-UX. >> Unfortunately, these lines might differ on all of these systems. They >> might differ when using a different compiler. They might differ when >> using a different toolchain. Does anybody on this list know how to >> compile a shared library on VMS? I don't. But libtool does. >> >> http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html >> to get an idea of the fiddling required. > > Granted. Neither do I know. > But this is - and I realise that this is a very egocentric > point of view - no real bonus if for the one platform I use > it does not. And it's some fiddling to get it working on > windows. > It's a cool tool if it works, but if it doesn't > it is getting really complex. > >> | If libtool was only required for generating distrib tarballs, it would >> | make little difference, but making it a requirement for mkoctfile >> | would mean a significant change. Not just for Windows; unless I'm >> | missing something, it would mean that dependency on libtool would be >> | required for Octave packages in GNU/Linux distros as well. >> >> I already had to patch mkoctfile to make it work reliable in Debian (it >> hardcodes paths when building Octave, which makes up for problems when >> the compiler is updated). So, no, mkoctfile is not a simple >> one-size-fits-all solution. >> >> Is libtool better? I don't know. But there are certainly more people >> with knowledge about libtool than there are with knowledge about >> mkoctfile and compiler flags. >> >> | With all due respect, but at this point I'd like to re-raise the >> | question, why are you trying to switch to libtool in the first place? >> | What's so complex about compiling a source file and linking a library >> | supposing for simplicity one is using the gnu compiler/linker suite? >> | (Does libtool even support different compilers?) >> >> I can only wonder that people argue about portability in one sentence, >> yet don't care about totally different compilers and platforms in the >> other sentences. You want portability? Use proven tools. And yes, >> libtool is complex and actually pretty slow when run. The fact that it's >> still around after all these years should however be a sign that >> somehow, it's deemed useful. > > Yes that may be so. > > libtool's mingw history is short - the first release for > msys environment is from august this year. gnuwin32's > version is 1.5.26 (feb-2008) and there have been no > updates yet. Maybe for good reason, I don't know. > > So if it wouldn't be for msys's version I'd probably had > to build it myself, and I'm not sure I'd call it proven then. > > I realise that my view is rather narrow-focused with > respect to interoperability and different platforms. > And that my reactions have been - well - emotional. > I apologize, I did not intend to discredit either persons > or platforms. > > I guess windows is the one system which is out of line. > Wouldn't be the first time for that. > And it's also still around after all these years. > > libtool appears like a big multifunctional too which > aims to support many or possibly all types of screws, > ones commonly used, other maybe more exotic or rare. > It comes highly recommended for its plurality and > I see that many people use it. > > And now I find that for the particular type of screw I > use, it does not fit. And I play around a bit, > at the end of the day I get a bit irritated. > And I start to ask myself why use this tool when > there is a nice adapter available, or a small > screwdriver at hand which does very nicely. > > Again: I'm not exactly a fan of libtool on windows. > I respect John's decision, I will try to get it working. > It doesn't make it easier, rather the other way round. > I am honestly not sure about mkoctfile as shell script > with libtool for windows. > > benjamin > > -- > GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > Hi Benjamin, I'd like to put the problem into the following perspective: Octave has certain portability needs - it needs to work with stuff that is platform-dependent. There is a free, GPLed source library that aims to solve such needs. The library is actively maintained and open to contributions (I don't actually know if this is true, but I suppose so). If the library doesn't work perfectly, we have either the option to a) use our own approach b) contribute and improve the library Of course, and especially because gnulib is also part of GNU, b) is a much better approach given the general philosophy of Octave and GNU. So in the long term, I think Octave should go with gnulib. Imagine Octave in place of gnulib, a) standing for "buy Matlab license" (or, as is often the case in this country, get a pirated copy). We're all those who chose b) for Octave. Why not for gnulib? The practical viewpoint is that a release of Octave 3.4 using libtool that won't build on windows wouldn't do any good for windows users. Maybe we should postpone the change until you get it to at least build and work reasonably, though maybe not perfectly. If it proves to be too hard, then we will really have a dilemmatic decision. regards -- 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 Nov 6 05:16:45 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 6 Nov 2009 06:16:45 -0500 Subject: libtool and mkoctfile In-Reply-To: <20091106094438.202040@gmx.net> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <20091105224828.GA6226@atlan> <20091106094438.202040@gmx.net> Message-ID: <19188.1437.749308.174811@segfault.lan> On 6-Nov-2009, Benjamin Lindner wrote: | I am honestly not sure about mkoctfile as shell script | with libtool for windows. I'm not sure about it either, which is why I asked whether it would cause a lot of trouble to require a sh interpreter for this purpose. Here's my current plan: * Use libtool and automake for building Octave. This is non-negotiable at this point, because I want to use gnulib, and using automake and libtool seems to be pretty much a requirement for doing that. I see a lot of benefit to using gnulib instead of our current oddball collection of replacement/portability functions grabbed from various sources at random points in time. * Leave the current configure hacks in place to set variables for mkoctfile. * We'll keep the mkoctfile script and program. If anything, we'll eliminate the script and keep the program, so that we can avoid the problem of having them diverge from one another. * Eventually use libtool to replace the homegrown configure hacks. My idea is to hook into the libtool LT_INIT macro that is used in configure.ac to generate the libtool script and modify/extend it in some way so that it can also be used to generate mkoctfile. The logic of choosing what compiler flags and methods for building shared libraries is in the configure script magic generated by LT_INIT, not the libtool shell script that it produces. jwe From jwe at octave.org Fri Nov 6 05:31:51 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 6 Nov 2009 06:31:51 -0500 Subject: libtool and mkoctfile In-Reply-To: <69d8d540911060315q45558c7es3b42b982f32cdaf7@mail.gmail.com> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <20091105224828.GA6226@atlan> <20091106094438.202040@gmx.net> <69d8d540911060315q45558c7es3b42b982f32cdaf7@mail.gmail.com> Message-ID: <19188.2343.424820.396608@segfault.lan> On 6-Nov-2009, Jaroslav Hajek wrote: | The practical viewpoint is that a release of Octave 3.4 using libtool | that won't build on windows wouldn't do any good for windows users. | Maybe we should postpone the change until you get it to at least build | and work reasonably, though maybe not perfectly. | If it proves to be too hard, then we will really have a dilemmatic decision. Please remember that I've offered to help debug the problems, but I need some precise directions about how to set up a proper build environment on a Windows system so I can duplicate whatever problems Benjamin is seeing. If there is already such a document, then point me to it. If there are problems with libtool, then we should also ask for help or report bugs on the libtool mailing lists. You can find them here: http://savannah.gnu.org/mail/?group=libtool Judging from the archives of the discussion list, the people there seem friendly and willing to help. A number of the threads I looked at dealt with various issues on Windows systems and there were responses with various people offering solutions. So we don't have to be completely on our own here... jwe From jwe at octave.org Fri Nov 6 06:17:06 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 6 Nov 2009 07:17:06 -0500 Subject: libtool and mkoctfile In-Reply-To: <69d8d540911060217l2f0c0d12gce8072930280cbbc@mail.gmail.com> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <20091105224828.GA6226@atlan> <69d8d540911060217l2f0c0d12gce8072930280cbbc@mail.gmail.com> Message-ID: <19188.5058.805627.90998@segfault.lan> On 6-Nov-2009, Jaroslav Hajek wrote: | On Thu, Nov 5, 2009 at 11:48 PM, Thomas Weber | wrote: | | > I can only wonder that people argue about portability in one sentence, | > yet don't care about totally different compilers and platforms in the | > other sentences. You want portability? Use proven tools. And yes, | > libtool is complex and actually pretty slow when run. | | This might be a drawback. How slow? Some packages require mkoctfile to | be run a dozen times to build ... I just timed two separate builds of Octave, one with the automake patch and one without. I see (CPU seconds, approximately): 2900 user, 280 system without automake/libtool 2910 user, 300 system with That includes 1175 invocations of "libtool: compile:" and 311 of "libtool: link:". So the change is really not significant, at least on a system where running a shell script is fast. I don't know what the current state of that is with the Msys shell on a Windows system. jwe From godfrey at isl.stanford.edu Fri Nov 6 07:05:20 2009 From: godfrey at isl.stanford.edu (Michael Godfrey) Date: Fri, 06 Nov 2009 14:05:20 +0100 Subject: Build error: __init_fltk__ missing In-Reply-To: <19188.1875.346441.911065@segfault.lan> References: <4AF2CCFA.5070203@isl.stanford.edu> <4AF2DEDA.1090704@isl.stanford.edu> <19186.57751.558379.14011@segfault.lan> <19186.58025.897219.693990@segfault.lan> <19186.59897.227311.279573@segfault.lan> <4AF3616B.6060501@isl.stanford.edu> <19187.62960.832559.843295@segfault.lan> <4AF402D6.8080807@isl.stanford.edu> <19188.1875.346441.911065@segfault.lan> Message-ID: <4AF41F10.3080405@isl.stanford.edu> > > I'm attaching an updated version of the patch that accounts for his > recent changes. This works much better. But, I have noticed a backend('fltk') problem which was not present, as far as I know, until recently: With backend('fltk'); in .octaverc file: lt-octave:1> plot([1:200]) lt-octave:2> quit panic: Segmentation fault -- stopping myself... attempting to save variables to `octave-core'... *** glibc detected *** /home/godfrey/mdg/software/octave/devel/hg/octave/src/.libs/lt-octave: corrupted double-linked list: 0x00000000024f2460 *** ===================================== Without invoking fltk octave quits normally. This may not be enough information to work from, but I am not able right now (in Zurich) to do much more. Michael From marco_atzeri at yahoo.it Fri Nov 6 07:05:49 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Fri, 6 Nov 2009 13:05:49 +0000 (GMT) Subject: libtool and mkoctfile In-Reply-To: <19188.5058.805627.90998@segfault.lan> Message-ID: <710612.44241.qm@web25501.mail.ukl.yahoo.com> --- Ven 6/11/09, John W. Eaton ha scritto: > Da: John W. Eaton > Oggetto: Re: libtool and mkoctfile > A: "Jaroslav Hajek" > Cc: maintainers at octave.org > Data: Venerd? 6 novembre 2009, 13:17 > On? 6-Nov-2009, Jaroslav Hajek > wrote: > > | On Thu, Nov 5, 2009 at 11:48 PM, Thomas Weber > | > wrote: > | > | > I can only wonder that people argue about > portability in one sentence, > | > yet don't care about totally different compilers and > platforms in the > | > other sentences. You want portability? Use proven > tools. And yes, > | > libtool is complex and actually pretty slow when > run. > | > | This might be a drawback. How slow? Some packages require > mkoctfile to > | be run a dozen times to build ... > > I just timed two separate builds of Octave, one with the > automake > patch and one without.? I see (CPU seconds, > approximately): > > ? 2900 user, 280 system???without > automake/libtool > ? 2910 user, 300 system???with > > That includes 1175 invocations of "libtool: compile:" and > 311 of > "libtool: link:". > > So the change is really not significant, at least on a > system where > running a shell script is fast.? I don't know what the > current state > of that is with the Msys shell on a Windows system. > > jwe > Probably the slower case is cygwin, but it is a general script speed issue not specific to our case. In cygwin we are already using automake/libtool for a lot of packages and usually it works fine. >From my recent experience porting the other packages, with automake/libtool the things are usually simpler. I need just to clarify me the details of mixing static and dynamic libraries, but I do not expect unbreakable issues. Regards Marco From jwe at octave.org Fri Nov 6 07:12:24 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 6 Nov 2009 08:12:24 -0500 Subject: Build error: __init_fltk__ missing In-Reply-To: <4AF41F10.3080405@isl.stanford.edu> References: <4AF2CCFA.5070203@isl.stanford.edu> <4AF2DEDA.1090704@isl.stanford.edu> <19186.57751.558379.14011@segfault.lan> <19186.58025.897219.693990@segfault.lan> <19186.59897.227311.279573@segfault.lan> <4AF3616B.6060501@isl.stanford.edu> <19187.62960.832559.843295@segfault.lan> <4AF402D6.8080807@isl.stanford.edu> <19188.1875.346441.911065@segfault.lan> <4AF41F10.3080405@isl.stanford.edu> Message-ID: <19188.8376.562594.144064@segfault.lan> On 6-Nov-2009, Michael Godfrey wrote: | > | > I'm attaching an updated version of the patch that accounts for his | > recent changes. | This works much better. But, I have noticed a backend('fltk') | problem which was not present, as far as I know, until | recently: | With backend('fltk'); in .octaverc file: | lt-octave:1> plot([1:200]) | lt-octave:2> quit | | panic: Segmentation fault -- stopping myself... | attempting to save variables to `octave-core'... | *** glibc detected *** | /home/godfrey/mdg/software/octave/devel/hg/octave/src/.libs/lt-octave: | corrupted double-linked list: 0x00000000024f2460 *** I can't duplicate this problem here, so I don't know what to debug. If you want to try debugging a little, can you try doing the above with "run-octave -g" and then seeing where it crashes? jwe From godfrey at isl.stanford.edu Fri Nov 6 07:25:13 2009 From: godfrey at isl.stanford.edu (Michael Godfrey) Date: Fri, 06 Nov 2009 14:25:13 +0100 Subject: Build error: __init_fltk__ missing In-Reply-To: <19188.8376.562594.144064@segfault.lan> References: <4AF2CCFA.5070203@isl.stanford.edu> <4AF2DEDA.1090704@isl.stanford.edu> <19186.57751.558379.14011@segfault.lan> <19186.58025.897219.693990@segfault.lan> <19186.59897.227311.279573@segfault.lan> <4AF3616B.6060501@isl.stanford.edu> <19187.62960.832559.843295@segfault.lan> <4AF402D6.8080807@isl.stanford.edu> <19188.1875.346441.911065@segfault.lan> <4AF41F10.3080405@isl.stanford.edu> <19188.8376.562594.144064@segfault.lan> Message-ID: <4AF423B9.9070908@isl.stanford.edu> I tried ./run-octave -g and got: Program received signal SIGSEGV, Segmentation fault. 0x000000396727f440 in ?? () from /usr/lib64/nvidia/libGL.so.1 Missing separate debuginfos, use: debuginfo-install arpack-2.1-11.fc11.x86_64 atlas-3.8.3-9.fc11.x86_64 blas-3.2.1-3.fc11.x86_64 expat-2.0.1-6.fc11.1.x86_64 fftw-3.2.1-2.fc11.x86_64 fltk-1.1.9-4.fc11.x86_64 fontconfig-2.7.1-1.fc11.x86_64 freetype-2.3.9-5.fc11.x86_64 ftgl-2.1.2-10.fc11.x86_64 glibc-2.10.1-5.x86_64 hdf5-1.8.3-1.fc11.x86_64 libX11-1.2.2-1.fc11.x86_64 libXau-1.0.4-5.fc11.x86_64 libXcursor-1.1.9-4.fc11.x86_64 libXext-1.0.99.1-3.fc11.x86_64 libXfixes-4.0.3-5.fc11.x86_64 libXft-2.1.13-2.fc11.x86_64 libXinerama-1.0.3-4.fc11.x86_64 libXrender-0.9.4-5.fc11.x86_64 libgcc-4.4.1-2.fc11.x86_64 libgfortran-4.4.1-2.fc11.x86_64 libstdc++-4.4.1-2.fc11.x86_64 libxcb-1.2-4.fc11.x86_64 mesa-libGLU-7.6-0.1.fc11.x86_64 ncurses-libs-5.7-2.20090207.fc11.x86_64 pcre-7.8-2.fc11.x86_64 readline-5.2-14.fc11.x86_64 suitesparse-3.2.0-6.fc11.x86_64 zlib-1.2.3-22.fc11.x86_64 (gdb) bt #0 0x000000396727f440 in ?? () from /usr/lib64/nvidia/libGL.so.1 #1 0x00000039672704e5 in _fini () from /usr/lib64/nvidia/libGL.so.1 #2 0x0000003ed5a0f0cc in _dl_fini () from /lib64/ld-linux-x86-64.so.2 #3 0x0000003ed5e367f2 in exit () from /lib64/libc.so.6 #4 0x00007ffff75e90f8 in clean_up_and_exit (retval=0) at toplev.cc:679 #5 0x00007ffff75e9727 in main_loop () at toplev.cc:626 #6 0x00007ffff759728d in octave_main (argc=, argv=0x7fffffffcc58, embedded=) at octave.cc:887 #7 0x0000003ed5e1ea2d in __libc_start_main () from /lib64/libc.so.6 #8 0x00000000004007c9 in _start () (gdb) ================================================ This appears to be specific to nvidia driver, so it probably does not deserve high priority. However, some recent change has caused this. This happens even if I close the plot window before "quit." From lindnerben at gmx.net Fri Nov 6 12:55:18 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Fri, 06 Nov 2009 19:55:18 +0100 Subject: libtool and mkoctfile In-Reply-To: <19188.5058.805627.90998@segfault.lan> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <20091105224828.GA6226@atlan> <69d8d540911060217l2f0c0d12gce8072930280cbbc@mail.gmail.com> <19188.5058.805627.90998@segfault.lan> Message-ID: <4AF47116.2000405@gmx.net> John W. Eaton wrote: > On 6-Nov-2009, Jaroslav Hajek wrote: > > | On Thu, Nov 5, 2009 at 11:48 PM, Thomas Weber > | wrote: > | > | > I can only wonder that people argue about portability in one sentence, > | > yet don't care about totally different compilers and platforms in the > | > other sentences. You want portability? Use proven tools. And yes, > | > libtool is complex and actually pretty slow when run. > | > | This might be a drawback. How slow? Some packages require mkoctfile to > | be run a dozen times to build ... > > I just timed two separate builds of Octave, one with the automake > patch and one without. I see (CPU seconds, approximately): > > 2900 user, 280 system without automake/libtool > 2910 user, 300 system with > > That includes 1175 invocations of "libtool: compile:" and 311 of > "libtool: link:". > > So the change is really not significant, at least on a system where > running a shell script is fast. I don't know what the current state > of that is with the Msys shell on a Windows system. > It's slow on msys. But that's because running scripts in general is slow. I don't think libtool is a particularily slow script in this case. Anyway speed is not an issue here. Then it takes longer, so what? As long as it works. benjamin From lindnerben at gmx.net Fri Nov 6 13:00:42 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Fri, 06 Nov 2009 20:00:42 +0100 Subject: libtool and mkoctfile In-Reply-To: <69d8d540911060315q45558c7es3b42b982f32cdaf7@mail.gmail.com> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <20091105224828.GA6226@atlan> <20091106094438.202040@gmx.net> <69d8d540911060315q45558c7es3b42b982f32cdaf7@mail.gmail.com> Message-ID: <4AF4725A.4070904@gmx.net> > Hi Benjamin, > > I'd like to put the problem into the following perspective: > > Octave has certain portability needs - it needs to work with stuff > that is platform-dependent. There is a free, GPLed source library that > aims to solve such needs. The library is actively maintained and open > to contributions (I don't actually know if this is true, but I suppose > so). > > If the library doesn't work perfectly, we have either the option to > a) use our own approach > b) contribute and improve the library > > Of course, and especially because gnulib is also part of GNU, b) is a > much better approach given the general philosophy of Octave and GNU. > So in the long term, I think Octave should go with gnulib. Imagine > Octave in place of gnulib, a) standing for "buy Matlab license" (or, > as is often the case in this country, get a pirated copy). We're all > those who chose b) for Octave. Why not for gnulib? True, you got me there. And I agree. Octave for windows wouldn't be where it is now if you hadn't taken the approach you hadn't taken - you get my meaning. benjamin From lindnerben at gmx.net Fri Nov 6 13:00:50 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Fri, 06 Nov 2009 20:00:50 +0100 Subject: libtool and mkoctfile In-Reply-To: <19185.64297.527396.220894@segfault.lan> References: <19183.20260.190284.974800@segfault.lan> <1257356376.3955.11.camel@sh-t400> <19185.49562.641185.158843@segfault.lan> <4AF1F467.5030509@gmx.net> <19185.64297.527396.220894@segfault.lan> Message-ID: <4AF47262.4030804@gmx.net> John W. Eaton wrote: > On 4-Nov-2009, Benjamin Lindner wrote: > > | With all due respect, but at this point I'd like to re-raise the > | question, why are you trying to switch to libtool in the first > | place? > > In part because it makes it simpler to use gnulib, and I think that > replacing parts of Octave with gnulib equivalents will be helpful and > make Octave more portable and more reliable. Fair enough. I see that you also reponded in this sense to the wifexited() issue on windows. OK, I get the point. > I have offered to help with the transition, but to do that, I will > need some precise instructions about how to construct the same build > environment that you have on a Windows system. So far, no one has > posted any instructions that would help me do that, or pointed me to > an existing document that clearly describes how to build Octave on a > Windows system. True, I am sorry I did not respond to this immediately. You are right there is no howto for octave on windows. There should be one. There should also be a readme.mingw for all reasons. I had it on my todo list, and not yet time to write them. > In a recent message, you said that you were able to build some parts > of Octave with libtool, but that some things were still not working. > What is not working? We had a therad on the list, I'll pick it up there where I left ok? > Again, I am willing to help with the transition, but I need to have > some precise directions for setting up a build environment that is the > same as yours so I can try to build Octave and see what the problems > are. Again, thanks for the offer. Yes, I'd like a second pair of eyes and possibly a different approach to the build process. Maybe I'm getting too blind already. Let's see, since I'd actually like to start writing a howto for octave on windows anyway. Would you be willing to play test subject? benjamin From lindnerben at gmx.net Fri Nov 6 13:09:10 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Fri, 06 Nov 2009 20:09:10 +0100 Subject: libtool and mkoctfile In-Reply-To: <19185.65315.2155.637928@segfault.lan> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <19185.40998.634807.594456@segfault.lan> <4AF1F4FC.4050400@gmx.net> <19185.65315.2155.637928@segfault.lan> Message-ID: <4AF47456.9030309@gmx.net> John W. Eaton wrote: > On 4-Nov-2009, Benjamin Lindner wrote: > > | If an executable does not call native windows api but instead calls e.g. > | a posix intermediate layer which translates these calls to windows api > | calls, then this executable is not native. > > For MinGW or MSVC with POSIX library functions that ultimately calls > the Windows API, I don't see the distinction. It's just a library > that provides an interface. It doesn't somehow change the fact that > the program runs on a Windows system. If I write my own (not POSIX) > wrappers around the Windows API that provide a convenient interface to > me, and then avoid using the Windows API directly, does that somehow > make my program not a native Windows program? Yes, this - of course - depends on where you draw the line. Is using posix threads making an application not native? Or wxwidgets? I don't know what a good distinction would be. I was thinking of cygwin/msys and wanted to specify the distinction in one short sentence, and came up with the above. > In the case of Cygwin, I do see a difference, because Cygwin programs > assume that the view of the filesystem is POSIX (/cygdrive/c/foo/bar), > not Windows (C:/foo/bar). So if these things are exposed users > notice a difference when they can't open files using the names they > are familiar with. So does msys (/c/foo/bar), and I would not call an msys application native. But in the end they also call native win api. But even an emulation software does this. So, yes, where does one draw the line? benjamn From storrsjm at email.uc.edu Fri Nov 6 13:23:28 2009 From: storrsjm at email.uc.edu (Judd Storrs) Date: Fri, 6 Nov 2009 14:23:28 -0500 Subject: libtool and mkoctfile In-Reply-To: <4AF47262.4030804@gmx.net> References: <19183.20260.190284.974800@segfault.lan> <1257356376.3955.11.camel@sh-t400> <19185.49562.641185.158843@segfault.lan> <4AF1F467.5030509@gmx.net> <19185.64297.527396.220894@segfault.lan> <4AF47262.4030804@gmx.net> Message-ID: On Fri, Nov 6, 2009 at 2:00 PM, Benjamin Lindner wrote: > Let's see, since I'd actually like to start writing a howto for octave > on windows anyway. Would you be willing to play test subject? I'll play, too. I've got a fresh Windows XP VM to play with. --judd From lindnerben at gmx.net Fri Nov 6 13:27:57 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Fri, 06 Nov 2009 20:27:57 +0100 Subject: gnulib and automake In-Reply-To: <19183.19051.712300.979144@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> Message-ID: <4AF478BD.1060507@gmx.net> > > Does the following change work for you? > Yes it does. thanks. I am now failing at make[3]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src' rm -f DLD-FUNCTIONS/__convn__.oct ln -s .libs/`sed -n -e "s/dlname='\([^']*\)'/\1/p" < DLD-FUNCTIONS/lib__convn__.la` DLD-FUNCTIONS/__convn__.oct ln: creating symbolic link `DLD-FUNCTIONS/__convn__.oct' to `.libs': No such file or directory make[3]: *** [DLD-FUNCTIONS/__convn__.oct] Error 1 The -no-undefined flag I guess must also be specified for all dld-functions .la objects, otherwise no shared libs are created /bin/sh ../libtool --tag=CXX --mode=link mingw32-g++-4.4.0-dw2 -shared-libgcc -march=i686 -mtune=generic -O3 -Wall -DHAVE_CONFIG_H -mieee-fp -Wall -W -Wshadow -Wold-style-cast -Wformat -march=i686 -mtune=generic -O3 -Wall -march=i686 -mtune=generic -O3 -Wall -shared-libgcc -Wl,--allow-multiple-definition -o DLD-FUNCTIONS/lib__contourc__.la -rpath /usr/local/octmgw32_gcc-4.4.0-dw2/octave/tip-automake-4/lib/octave-3.3.50+ DLD-FUNCTIONS/__contourc__.lo -shared-libgcc -Wl,--allow-multiple-definition ./liboctinterp.la ../liboctave/liboctave.la ../libcruft/libcruft.la -liberty -lm -lgdi32 -lws2_32 -luser32 -lkernel32 libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries libtool: link: rm -fr DLD-FUNCTIONS/.libs/lib__contourc__.a DLD-FUNCTIONS/.libs/lib__contourc__.lai libtool: link: ar cru DLD-FUNCTIONS/.libs/lib__contourc__.a DLD-FUNCTIONS/.libs/__contourc__.o libtool: link: ranlib DLD-FUNCTIONS/.libs/lib__contourc__.a libtool: link: ( cd "DLD-FUNCTIONS/.libs" && rm -f "lib__contourc__.la" && ln -s "../lib__contourc__.la" "lib__contourc__.la" ) and the corresponding .la files read # The name that we can dlopen(3). dlname='' and this makes the above ln call fail. Again I am not sure where to best add this in the autoconf sources. I see that in the makefile every .oct file has it's own link make rule, but these seem to be generated, as there are none in the .mk sources. benjamin From lindnerben at gmx.net Fri Nov 6 13:49:52 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Fri, 06 Nov 2009 20:49:52 +0100 Subject: gnulib and automake In-Reply-To: <4AF478BD.1060507@gmx.net> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> Message-ID: <4AF47DE0.2090402@gmx.net> Benjamin Lindner wrote: >> >> Does the following change work for you? >> > > Yes it does. > thanks. > I forgot: I had to add the follwing patch to define the necessary dependency libraries for all dld-functions which do not have any additional external dependendcies. Otherwise I am seing undefined reference link failures. diff -r 43e97dbafb42 -r eb2ee3d80ca8 src/Makefile.am --- a/src/Makefile.am Fri Nov 06 19:18:41 2009 +0100 +++ b/src/Makefile.am Fri Nov 06 19:21:04 2009 +0100 @@ -719,6 +721,61 @@ display.df display.lo: CPPFLAGS += $(X11_FLAGS) +DLD_FUNCTIONS_lib__contourc___la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_lib__convn___la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_lib__dsearchn___la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_lib__lin_interpn___la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_lib__pchip_deriv___la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_lib__qp___la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libbalance_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libbesselj_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libbetainc_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libbsxfun_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libcellfun_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libcolloc_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libconv2_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libdaspk_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libdasrt_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libdassl_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libdet_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libdispatch_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libdlmread_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libeig_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libfilter_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libfind_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libgammainc_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libgcd_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libgetgrent_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libgetpwent_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libgetrusage_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libgivens_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libhess_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libhex2num_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libinv_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libkron_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_liblookup_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_liblsode_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_liblu_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libluinc_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libmatrix_type_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libmax_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libmd5sum_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libpinv_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libquad_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_librand_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_librcond_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libschur_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libsparse_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libspparms_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libsqrtm_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libsub2ind_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libsvd_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libsyl_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libtime_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libtril_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libtsearch_la_LIBADD = $(OCT_LINK_DEPS) +DLD_FUNCTIONS_libtypecast_la_LIBADD = $(OCT_LINK_DEPS) + DLD-FUNCTIONS/__magick_read__.df: CPPFLAGS += $(MAGICK_CPPFLAGS) DLD_FUNCTIONS_lib__magick_read___la_CPPFLAGS = $(AM_CPPFLAGS) $(MAGICK_CPPFLAGS) DLD_FUNCTIONS_lib__magick_read___la_LIBADD = $(OCT_LINK_DEPS) $(MAGICK_LDFLAGS) $(MAGICK_LIBS) From jwe at octave.org Fri Nov 6 13:53:37 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 6 Nov 2009 14:53:37 -0500 Subject: gnulib and automake In-Reply-To: <4AF478BD.1060507@gmx.net> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> Message-ID: <19188.32449.963957.318005@segfault.lan> On 6-Nov-2009, Benjamin Lindner wrote: | I am now failing at | | make[3]: Entering directory | `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src' | rm -f DLD-FUNCTIONS/__convn__.oct | ln -s .libs/`sed -n -e "s/dlname='\([^']*\)'/\1/p" < | DLD-FUNCTIONS/lib__convn__.la` DLD-FUNCTIONS/__convn__.oct | ln: creating symbolic link `DLD-FUNCTIONS/__convn__.oct' to `.libs': No | such file or directory | make[3]: *** [DLD-FUNCTIONS/__convn__.oct] Error 1 | | | The -no-undefined flag I guess must also be specified for all | dld-functions .la objects, otherwise no shared libs are created | | /bin/sh ../libtool --tag=CXX --mode=link mingw32-g++-4.4.0-dw2 | -shared-libgcc -march=i686 -mtune=generic -O3 -Wall -DHAVE_CONFIG_H | -mieee-fp -Wall -W -Wshadow -Wold-style-cast -Wformat -march=i686 | -mtune=generic -O3 -Wall -march=i686 -mtune=generic -O3 -Wall | -shared-libgcc -Wl,--allow-multiple-definition -o | DLD-FUNCTIONS/lib__contourc__.la -rpath | /usr/local/octmgw32_gcc-4.4.0-dw2/octave/tip-automake-4/lib/octave-3.3.50+ | DLD-FUNCTIONS/__contourc__.lo -shared-libgcc | -Wl,--allow-multiple-definition ./liboctinterp.la | ../liboctave/liboctave.la ../libcruft/libcruft.la -liberty -lm -lgdi32 | -lws2_32 -luser32 -lkernel32 | libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 | shared libraries | libtool: link: rm -fr DLD-FUNCTIONS/.libs/lib__contourc__.a | DLD-FUNCTIONS/.libs/lib__contourc__.lai | libtool: link: ar cru DLD-FUNCTIONS/.libs/lib__contourc__.a | DLD-FUNCTIONS/.libs/__contourc__.o | libtool: link: ranlib DLD-FUNCTIONS/.libs/lib__contourc__.a | libtool: link: ( cd "DLD-FUNCTIONS/.libs" && rm -f "lib__contourc__.la" | && ln -s "../lib__contourc__.la" "lib__contourc__.la" ) | | and the corresponding .la files read | | # The name that we can dlopen(3). | dlname='' | | and this makes the above ln call fail. | | Again I am not sure where to best add this in the autoconf sources. | I see that in the makefile every .oct file has it's own link make rule, | but these seem to be generated, as there are none in the .mk sources. The problem here is that dlname is empty in the .la file. So we need to find out why that is happening. I've since discovered the -module option for libtool, which is supposed to tell it to build something that can be opened with dlopen. Of course you don't have dlopen, but I don't know precisely what "dlopen" means here. If it strictly means "use the dlopen library call", then we need another approach. But if it means "dynamically link in some way that works for the given system", then I think this approach should work. Looking at the code generated by LT_INIT in the configure script, I see case $host_os in ... mingw* | pw32* | cegcc*) lt_cv_dlopen="LoadLibrary" lt_cv_dlopen_libs= ;; but for this to be enabled, we have to specify "dlopen" as an option to the LT_INIT macro. I've put a new changeset at http://jweaton.org/automake-diffs.gz that includes these changes and is updated for the latest Octave sources, so should apply cleanly to a fresh clone of the current hg archive. Could you try a build with these recent changes? Thanks, jwe From lindnerben at gmx.net Fri Nov 6 14:01:15 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Fri, 06 Nov 2009 21:01:15 +0100 Subject: gnulib and automake In-Reply-To: <19188.32449.963957.318005@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> Message-ID: <4AF4808B.7010703@gmx.net> John W. Eaton wrote: > On 6-Nov-2009, Benjamin Lindner wrote: > > | I am now failing at > | > | make[3]: Entering directory > | `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src' > | rm -f DLD-FUNCTIONS/__convn__.oct > | ln -s .libs/`sed -n -e "s/dlname='\([^']*\)'/\1/p" < > | DLD-FUNCTIONS/lib__convn__.la` DLD-FUNCTIONS/__convn__.oct > | ln: creating symbolic link `DLD-FUNCTIONS/__convn__.oct' to `.libs': No > | such file or directory > | make[3]: *** [DLD-FUNCTIONS/__convn__.oct] Error 1 > | > | > | The -no-undefined flag I guess must also be specified for all > | dld-functions .la objects, otherwise no shared libs are created > | > | /bin/sh ../libtool --tag=CXX --mode=link mingw32-g++-4.4.0-dw2 > | -shared-libgcc -march=i686 -mtune=generic -O3 -Wall -DHAVE_CONFIG_H > | -mieee-fp -Wall -W -Wshadow -Wold-style-cast -Wformat -march=i686 > | -mtune=generic -O3 -Wall -march=i686 -mtune=generic -O3 -Wall > | -shared-libgcc -Wl,--allow-multiple-definition -o > | DLD-FUNCTIONS/lib__contourc__.la -rpath > | /usr/local/octmgw32_gcc-4.4.0-dw2/octave/tip-automake-4/lib/octave-3.3.50+ > | DLD-FUNCTIONS/__contourc__.lo -shared-libgcc > | -Wl,--allow-multiple-definition ./liboctinterp.la > | ../liboctave/liboctave.la ../libcruft/libcruft.la -liberty -lm -lgdi32 > | -lws2_32 -luser32 -lkernel32 > | libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 > | shared libraries > | libtool: link: rm -fr DLD-FUNCTIONS/.libs/lib__contourc__.a > | DLD-FUNCTIONS/.libs/lib__contourc__.lai > | libtool: link: ar cru DLD-FUNCTIONS/.libs/lib__contourc__.a > | DLD-FUNCTIONS/.libs/__contourc__.o > | libtool: link: ranlib DLD-FUNCTIONS/.libs/lib__contourc__.a > | libtool: link: ( cd "DLD-FUNCTIONS/.libs" && rm -f "lib__contourc__.la" > | && ln -s "../lib__contourc__.la" "lib__contourc__.la" ) > | > | and the corresponding .la files read > | > | # The name that we can dlopen(3). > | dlname='' > | > | and this makes the above ln call fail. > | > | Again I am not sure where to best add this in the autoconf sources. > | I see that in the makefile every .oct file has it's own link make rule, > | but these seem to be generated, as there are none in the .mk sources. > > The problem here is that dlname is empty in the .la file. So we need > to find out why that is happening. Hm, the following may be a wrong conclusion, but I find that if libtool does not create the shared library (whyever), then the dlname is empty (like in the above case). But if I manually add "-no-undefined" to CXXLINK in .build/src/makefile as CXXLINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ --mode=link $(CXXLD) -no-undefined $(AM_CXXFLAGS) $(CXXFLAGS) $(AM_LDFLAGS) \ $(LDFLAGS) -o $@ then I get .dlls for the dld-functions, and then in the .la files I see # The name that we can dlopen(3). dlname='lib__contourc__-0.dll' ? > I've since discovered the -module option for libtool, which is > supposed to tell it to build something that can be opened with > dlopen. Of course you don't have dlopen, but I don't know precisely > what "dlopen" means here. If it strictly means "use the dlopen > library call", then we need another approach. But if it means > "dynamically link in some way that works for the given system", then I > think this approach should work. Looking at the code generated by > LT_INIT in the configure script, I see > > case $host_os in > ... > > mingw* | pw32* | cegcc*) > lt_cv_dlopen="LoadLibrary" > lt_cv_dlopen_libs= > ;; > > but for this to be enabled, we have to specify "dlopen" as an option > to the LT_INIT macro. > > I've put a new changeset at http://jweaton.org/automake-diffs.gz that > includes these changes and is updated for the latest Octave sources, > so should apply cleanly to a fresh clone of the current hg archive. > > Could you try a build with these recent changes? > > Thanks, sure. benjamin From jwe at octave.org Fri Nov 6 14:08:45 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 6 Nov 2009 15:08:45 -0500 Subject: gnulib and automake In-Reply-To: <4AF47DE0.2090402@gmx.net> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <4AF47DE0.2090402@gmx.net> Message-ID: <19188.33357.562164.2842@segfault.lan> On 6-Nov-2009, Benjamin Lindner wrote: | I forgot: | I had to add the follwing patch to define the necessary dependency | libraries for all dld-functions which do not have any additional | external dependendcies. Otherwise I am seing undefined reference link | failures. Does the following patch also work? It should generate the repetitive LIBADD lines in the DLD-FUNCTIONS/module.mk file when autogen.sh runs, then the special libraries should be added in the Makefile.am file. jwe -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diffs Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091106/b4164840/attachment.ksh From jwe at octave.org Fri Nov 6 14:11:40 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 6 Nov 2009 15:11:40 -0500 Subject: libtool and mkoctfile In-Reply-To: <4AF47262.4030804@gmx.net> References: <19183.20260.190284.974800@segfault.lan> <1257356376.3955.11.camel@sh-t400> <19185.49562.641185.158843@segfault.lan> <4AF1F467.5030509@gmx.net> <19185.64297.527396.220894@segfault.lan> <4AF47262.4030804@gmx.net> Message-ID: <19188.33532.487384.779173@segfault.lan> On 6-Nov-2009, Benjamin Lindner wrote: | Let's see, since I'd actually like to start writing a howto for octave | on windows anyway. Would you be willing to play test subject? Yes, I can help with that. I think it would help if several people did this, so if anyone else is interested, please speak up. I see Judd already has. Thanks, jwe From jwe at octave.org Fri Nov 6 14:19:21 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 6 Nov 2009 15:19:21 -0500 Subject: gnulib and automake In-Reply-To: <4AF4808B.7010703@gmx.net> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> Message-ID: <19188.33993.430549.638193@segfault.lan> On 6-Nov-2009, Benjamin Lindner wrote: | Hm, the following may be a wrong conclusion, but I find that if libtool | does not create the shared library (whyever), then the dlname is empty | (like in the above case). | | But if I manually add "-no-undefined" to CXXLINK in .build/src/makefile | as | | CXXLINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ | --mode=link $(CXXLD) -no-undefined $(AM_CXXFLAGS) $(CXXFLAGS) | $(AM_LDFLAGS) \ | $(LDFLAGS) -o $@ | | then I get .dlls for the dld-functions, and then in the .la files I see | | # The name that we can dlopen(3). | dlname='lib__contourc__-0.dll' OK, so -no-undefined may also be needed. I guess the way to add it is to also make a change like the attached? There is currently no rule in the Makefile for running the script that this patch modifies, so you'll have to run autogen.sh again after making this change. 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/20091106/f7a6c9c0/attachment.ksh From lindnerben at gmx.net Fri Nov 6 15:19:37 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Fri, 06 Nov 2009 22:19:37 +0100 Subject: gnulib and automake In-Reply-To: <19188.33357.562164.2842@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <4AF47DE0.2090402@gmx.net> <19188.33357.562164.2842@segfault.lan> Message-ID: <4AF492E9.9030307@gmx.net> John W. Eaton wrote: > On 6-Nov-2009, Benjamin Lindner wrote: > > | I forgot: > | I had to add the follwing patch to define the necessary dependency > | libraries for all dld-functions which do not have any additional > | external dependendcies. Otherwise I am seing undefined reference link > | failures. > > Does the following patch also work? It should generate the repetitive > LIBADD lines in the DLD-FUNCTIONS/module.mk file when autogen.sh runs, > then the special libraries should be added in the Makefile.am file. much better! thanks benjamin From lindnerben at gmx.net Fri Nov 6 15:19:40 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Fri, 06 Nov 2009 22:19:40 +0100 Subject: gnulib and automake In-Reply-To: <19188.33993.430549.638193@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <19188.33993.430549.638193@segfault.lan> Message-ID: <4AF492EC.5070808@gmx.net> John W. Eaton wrote: > > OK, so -no-undefined may also be needed. I guess the way to add it is > to also make a change like the attached? There is currently no rule > in the Makefile for running the script that this patch modifies, so > you'll have to run autogen.sh again after making this change. Yes this works, thanks benjamin From lindnerben at gmx.net Fri Nov 6 15:26:48 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Fri, 06 Nov 2009 22:26:48 +0100 Subject: gnulib and automake In-Reply-To: <4AF4808B.7010703@gmx.net> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> Message-ID: <4AF49498.6020603@gmx.net> >> I've put a new changeset at http://jweaton.org/automake-diffs.gz that >> includes these changes and is updated for the latest Octave sources, >> so should apply cleanly to a fresh clone of the current hg archive. >> >> Could you try a build with these recent changes? >> >> Thanks, > > sure. > Ok, now make is stopping at the following error: ln -s .libs/`sed -n -e "s/dlname='\([^']*\)'/\1/p" < DLD-FUNCTIONS/__convn__.la` DLD-FUNCTIONS/__convn__.oct ln: creating symbolic link `DLD-FUNCTIONS/__convn__.oct' to `.libs/__convn__-0.dll': No such file or directory make[3]: *** [DLD-FUNCTIONS/__convn__.oct] Error 1 make[3]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src' In my build directrory I have .build/src/.libs/ and .build/src/DLD-FUNCTION/.libs/ and the dld-function shared libs are located in the latter (while liboctinterp.dll is found in the former diretctory) So in my case, since the makefile is executed in the src/ directory the ln command should probably read ln -s DLD-FUNCTIONS/.libs/`sed -n -e "s/dlname='\([^']*\)'/\1/p" < DLD-FUNCTIONS/__convn__.la` DLD-FUNCTIONS/__convn__.oct I don't know if this is now a mingw speciality of libtool to put the libraries there. benjamin From jwe at octave.org Fri Nov 6 23:07:32 2009 From: jwe at octave.org (John W. Eaton) Date: Sat, 7 Nov 2009 00:07:32 -0500 Subject: gnulib and automake In-Reply-To: <4AF49498.6020603@gmx.net> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> Message-ID: <19189.148.970534.7634@segfault.lan> On 6-Nov-2009, Benjamin Lindner wrote: | Ok, now make is stopping at the following error: | | ln -s .libs/`sed -n -e "s/dlname='\([^']*\)'/\1/p" < | DLD-FUNCTIONS/__convn__.la` DLD-FUNCTIONS/__convn__.oct | ln: creating symbolic link `DLD-FUNCTIONS/__convn__.oct' to | `.libs/__convn__-0.dll': No such file or directory | make[3]: *** [DLD-FUNCTIONS/__convn__.oct] Error 1 | make[3]: Leaving directory | `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src' | | In my build directrory I have | .build/src/.libs/ | and | .build/src/DLD-FUNCTION/.libs/ | | and the dld-function shared libs are located in the latter (while | liboctinterp.dll is found in the former diretctory) | So in my case, since the makefile is executed in the src/ directory | the ln command should probably read | | ln -s DLD-FUNCTIONS/.libs/`sed -n -e "s/dlname='\([^']*\)'/\1/p" < | DLD-FUNCTIONS/__convn__.la` DLD-FUNCTIONS/__convn__.oct | | I don't know if this is now a mingw speciality of libtool to put the | libraries there. On my system, running the command $(LN_S) .libs/foo.dll DLD-FUNCTIONS/foo.oct in the parent of the DLD-FUNCTIONS directory creates a symbolic link in the DLD-FUNCTIONS directory with the name __convn__.oct that points to the file .libs/foo.dll. Ah, but Windows doesn't have symbolic links and $(LN_S) is just cp, so I guess this fails. OK, I think what we need to do is cd DLD-FUNCTIONS && $(LN_S) .libs/foo.dll foo.oct so that it will work correctly with either cp or "ln -s". I've made a change that should do this correctly now. The updated versinon of my patch is now on http://jweaton.org/automake-diffs.gz. This version of the patch includes all the other changes I made on Friday. Thanks, jwe From storrsjm at email.uc.edu Sat Nov 7 14:42:19 2009 From: storrsjm at email.uc.edu (Judd Storrs) Date: Sat, 7 Nov 2009 15:42:19 -0500 Subject: libtool and mkoctfile In-Reply-To: <19188.33532.487384.779173@segfault.lan> References: <19183.20260.190284.974800@segfault.lan> <1257356376.3955.11.camel@sh-t400> <19185.49562.641185.158843@segfault.lan> <4AF1F467.5030509@gmx.net> <19185.64297.527396.220894@segfault.lan> <4AF47262.4030804@gmx.net> <19188.33532.487384.779173@segfault.lan> Message-ID: On Wed, Nov 4, 2009 at 5:07 PM, John W. Eaton wrote: > need some precise instructions about how to construct the same build > environment that you have on a Windows system. So far, no one has > posted any instructions that would help me do that, or pointed me to > an existing document that clearly describes how to build Octave on a > Windows system. You're probably way ahead of me at this point, but I feel like I'm finally making some progress toward building 3.2.3 on Windows. Here's what I've been able to figure out. I think it boils down to discovering that this exists: svn co https://octave.svn.sourceforge.net/svnroot/octave/trunk/octave-forge/admin/Windows/mingw32 mingw32 I found this via Matusuoka-san's instructions at: http://www.tatsuromatsuoka.com/octave/Eng/Win/ReadmeBriefOctBuildMingw.html A big thank you to Matsuoka-san for pointing me toward the svn. After wading through the MSYS/MinGW website I have to say the SVN repository is an amazing sea tranquility and sane build scripts. I wish I had found this so much sooner. So, now it looks like I'm making progress in compiling 3.2.3. * I cloned the svn repository using TortoiseSVN to O:\octave. Then I saw the comments at the top of install-mingw32-4.4.0.bat install-msys-1.0.11.bat There are two parts--first getting executables the bat files require and also downloading archives for the bat files to process. I put the required programs inside: O:\bootstrap NOTE: Things seem to get very cranky if mount points get crossed. My C:\ was too small so everything is on O:\. O:\bootstrap contains: wget.exe bsdtar.exe sed.exe libiconv2.dll regex2.dll bzip2.dll libarchive2.dll libintl3.dll zlib1.dll (I can ZIP this up for anyone that wants it -- getting them is described in the bat files) I then downloaded all the files listed in mingw32/mingw32-gcc-url.txt and msys/msys-url.txt using wget on linux and transferred them into the mingw32 and msys directories on windows. * Add O:\bootstrap to the end of the Windows Path environment variable * Run install-mingw32-4.4.0.bat (double click). I choose O:\MinGW for the install path. * The next thing I did was use the MSYS-1.0.11.exe setup installer. This probably isn't necessary if you know what you're doing. (I couldn't figure out how to start msys after it was installed by install-msys-1.0.11.bat). I installed to O:\msys\1.0 The installer will ask for the path to MinGW at the end and it will complain about not finding the gcc compilers not existing in the installed MinGW. I think this is because the MSYS installer wants to rename them but install-mingw32-4.4.0.bat has already done that. It doesn't matter. I was just using it for the shortcut. Shortcut info: Target: O:\msys\1.0\msys.bat -norxvt Start in: O:\msys\1.0\bin Run: Normal window * Now run install-msys-1.0.11.bat (double click). I choose O:\msys\1.0 i.e. the same place as the installer. * Copy O:\msys\1.0\etc\fstab.example to O:\msys\1.0\etc\fstab and set the path for /mingw to go to the MinGW install directory. Mine looks like: o:/mingw /mingw * Remove O:\bootstrap from the end of the Windows Path environment variable * Start MSYS $ cd \o\octave $ ./gcc44_build_dep.sh That's as far as I've made it. There are other scripts in there and I'm not sure the correct order of running them, but I think the build environment is working. It's still compiling and hasn't been angry yet. I have no idea when it will finish. I'm assuming that the next steps are: ./gcc44_install_dep.sh Maybe convert gcc43_build_tools.sh gcc43_build_octave.sh into gcc44 versions? --judd From younes at lyx.org Sun Nov 8 15:05:52 2009 From: younes at lyx.org (Abdelrazak Younes) Date: Sun, 08 Nov 2009 22:05:52 +0100 Subject: libtool and mkoctfile In-Reply-To: <19185.50863.316733.700063@segfault.lan> References: <19183.20260.190284.974800@segfault.lan> <20091104085058.227470@gmx.net> <69d8d540911040152y3c283756vd993483b5ea9accc@mail.gmail.com> <19185.40998.634807.594456@segfault.lan> <69d8d540911040944t5adcadb8mc39438e7056e36d3@mail.gmail.com> <19185.50863.316733.700063@segfault.lan> Message-ID: <4AF732B0.2050001@lyx.org> On 04/11/2009 19:23, John W. Eaton wrote: > On 4-Nov-2009, Jaroslav Hajek wrote: > > | If thanks to these changes Octave's code will become cleaner and more > | portable, then I suppose that justifies them well. I never knew of > | gnulib before, so I can't justify that. I hope it's no problem use > | libtool and gnulib with other compilers. > > As far as I know, libtool and gnulib are not aimed only at GCC. > > | One problem I see with gnulib is that it is C-centric rather than > | C++-centric. > > What I'm looking for is something that will handle replacing the core > POSIX functions on systems that don't have them, or that have broken > versions. Most often these days, that is Windows, isn't it? And > these are relatively low-level functions defined with C language > interfaces. So I don't see this as a problem. > > | Have you also considered Boost? FSF recognizes the Boost software > | license as free and GPL compatible. > | Boost likewise provides portable I/O and memory facilities, special > | functions etc... > | Boost is extensively developed and maintained, and very portable. Some > | portions of Boost made it into the C++ standard, and some are planned > | in the future. Maybe Boost would be a better option for Octave? > > I suppose Boost would be OK for higher level things. But it doesn't > aim to provide replacements for readdir or strftime on systems that > lack them, does it? It does... readdir and other file handling: boost::filesystem strftime: boost date_time In the LyX project we used to use boost a lot. Nowadays we prefer Qt which brings a lot of cross-platform functions for everything (QtCore is not about GUI). My 2 outsider cents :-) Abdel. From individ at acc.umu.se Mon Nov 9 08:25:22 2009 From: individ at acc.umu.se (David Grundberg) Date: Mon, 09 Nov 2009 15:25:22 +0100 Subject: gnulib and automake In-Reply-To: <19189.148.970534.7634@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> Message-ID: <4AF82652.2060000@acc.umu.se> John W. Eaton wrote: > On 6-Nov-2009, Benjamin Lindner wrote: > > | Ok, now make is stopping at the following error: > | > | ln -s .libs/`sed -n -e "s/dlname='\([^']*\)'/\1/p" < > | DLD-FUNCTIONS/__convn__.la` DLD-FUNCTIONS/__convn__.oct > | ln: creating symbolic link `DLD-FUNCTIONS/__convn__.oct' to > | `.libs/__convn__-0.dll': No such file or directory > | make[3]: *** [DLD-FUNCTIONS/__convn__.oct] Error 1 > | make[3]: Leaving directory > | `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src' > | > | In my build directrory I have > | .build/src/.libs/ > | and > | .build/src/DLD-FUNCTION/.libs/ > | > | and the dld-function shared libs are located in the latter (while > | liboctinterp.dll is found in the former diretctory) > | So in my case, since the makefile is executed in the src/ directory > | the ln command should probably read > | > | ln -s DLD-FUNCTIONS/.libs/`sed -n -e "s/dlname='\([^']*\)'/\1/p" < > | DLD-FUNCTIONS/__convn__.la` DLD-FUNCTIONS/__convn__.oct > | > | I don't know if this is now a mingw speciality of libtool to put the > | libraries there. > > On my system, running the command > > $(LN_S) .libs/foo.dll DLD-FUNCTIONS/foo.oct > > in the parent of the DLD-FUNCTIONS directory creates a symbolic link > in the DLD-FUNCTIONS directory with the name __convn__.oct that points > to the file .libs/foo.dll. > > Ah, but Windows doesn't have symbolic links and $(LN_S) is just cp, so > I guess this fails. OK, I think what we need to do is > > cd DLD-FUNCTIONS && $(LN_S) .libs/foo.dll foo.oct > > so that it will work correctly with either cp or "ln -s". I've made a > change that should do this correctly now. The updated versinon of my > patch is now on http://jweaton.org/automake-diffs.gz. This version of > the patch includes all the other changes I made on Friday. > > Thanks, > > jwe > Hi jwe, I made some changes on top of automake-diffs in order to build liboctave/ and src/. amd.patch is just a rewrite of an earlier changeset that fixes a configure test on my setup. lt-flags.patch are some changes I made while compiling against ARPACK, SparseSuite, qrupdate and FFTW for liboctave/. It fixes the convhulln typo in src/. Best regards, David -------------- next part -------------- A non-text attachment was scrubbed... Name: lt-flags.patch Type: text/x-diff Size: 3276 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091109/f8a445c2/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: amd.patch Type: text/x-diff Size: 1050 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091109/f8a445c2/attachment-0001.bin From jwe at octave.org Mon Nov 9 11:48:27 2009 From: jwe at octave.org (John W. Eaton) Date: Mon, 9 Nov 2009 12:48:27 -0500 Subject: gnulib and automake In-Reply-To: <4AF82652.2060000@acc.umu.se> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <4AF82652.2060000@acc.umu.se> Message-ID: <19192.21995.855841.648786@segfault.lan> On 9-Nov-2009, David Grundberg wrote: | I made some changes on top of automake-diffs in order to build | liboctave/ and src/. | | amd.patch is just a rewrite of an earlier changeset that fixes a | configure test on my setup. | | lt-flags.patch are some changes I made while compiling against ARPACK, | SparseSuite, qrupdate and FFTW for liboctave/. It fixes the convhulln | typo in src/. | | ---------------------------------------------------------------------- | diff --git a/liboctave/Makefile.am b/liboctave/Makefile.am | --- a/liboctave/Makefile.am | +++ b/liboctave/Makefile.am | @@ -494,10 +494,10 @@ | LINK_DEPS = \ | $(RLD_FLAG) \ | ../libcruft/libcruft.la \ | - $(SPARSE_LDFLAGS) $(SPARSE_XLIBS) \ | + $(SPARSE_XLIBS) \ | $(ARPACK_LIBS) \ | $(QRUPDATE_LIBS) \ | - $(FFTW_LDFLAGS) $(FFTW_XLIBS) \ | + $(FFTW_XLIBS) \ | $(LAPACK_LIBS) $(BLAS_LIBS) \ | $(READLINE_LIBS) $(TERM_LIBS) \ | $(LIBGLOB) $(REGEX_LIBS) $(DL_LIBS) \ | @@ -511,7 +511,17 @@ | | liboctave_la_LIBADD = $(LINK_DEPS) | | -liboctave_la_LDFLAGS = -release $(version) | +liboctave_la_LDFLAGS = -release $(version) \ | + $(SPARSE_XLDFLAGS) \ | + $(ARPACK_LDFLAGS) \ | + $(QRUPDATE_LDFLAGS) \ | + $(FFTW_XLDFLAGS) | + | +liboctave_la_CPPFLAGS = \ | + $(SPARSE_XCPPFLAGS) \ | + $(FFTW_XCPPFLAGS) \ | + $(ARPACK_CPPFLAGS) \ | + $(AM_CPPFLAGS) | | octinclude_HEADERS = \ | $(INCS) \ | @@ -538,46 +548,6 @@ | $(AWK) -f $(srcdir)/mk-ops.awk prefix=mx make_inclusive_header=mx-ops.h $(srcdir)/mx-ops > $@-t | $(simple_move_if_change_rule) | | -CSparse.d CSparse.df pic/CSparse.o CSparse.o: CPPFLAGS += $(SPARSE_CPPFLAGS) | - | -dSparse.d dSparse.df pic/dSparse.o dSparse.o: CPPFLAGS += $(SPARSE_CPPFLAGS) | - | -SparseCmplxLU.d SparseCmplxLU.df pic/SparseCmplxLU.o SparseCmplxLU.o: \ | - CPPFLAGS += $(SPARSE_CPPFLAGS) | - | -SparsedbleLU.d SparsedbleLU.df pic/SparsedbleLU.o SparsedbleLU.o: \ | - CPPFLAGS += $(SPARSE_CPPFLAGS) | - | -SparseCmplxQR.d SparseCmplxQR.df pic/SparseCmplxQR.o SparseCmplxQR.o: \ | - CPPFLAGS += $(SPARSE_CPPFLAGS) | - | -SparsedbleQR.d SparsedbleQR.df pic/SparsedbleQR.o SparsedbleQR.o: \ | - CPPFLAGS += $(SPARSE_CPPFLAGS) | - | -SparseCmplxCHOL.d SparseCmplxCHOL.df pic/SparseCmplxCHOL.o SparseCmplxCHOL.o: \ | - CPPFLAGS += $(SPARSE_CPPFLAGS) | - | -SparsedbleCHOL.d SparsedbleCHOL.df pic/SparsedbleCHOL.o SparsedbleCHOL.o: \ | - CPPFLAGS += $(SPARSE_CPPFLAGS) | - | -CMatrix.d CMatrix.df pic/CMatrix.o CMatrix.o: CPPFLAGS += $(FFTW_CPPFLAGS) | - | -CNDArray.d CNDArray.df pic/CNDArray.o CNDArray.o: CPPFLAGS += $(FFTW_CPPFLAGS) | - | -dMatrix.d dMatrix.df pic/dMatrix.o dMatrix.o: CPPFLAGS += $(FFTW_CPPFLAGS) | - | -dNDArray.d dNDArray.df pic/dNDArray.o dNDArray.o: CPPFLAGS += $(FFTW_CPPFLAGS) | - | -fCMatrix.d fCMatrix.df pic/fCMatrix.o fCMatrix.o: CPPFLAGS += $(FFTW_CPPFLAGS) | - | -fCNDArray.d fCNDArray.df pic/fCNDArray.o fCNDArray.o: CPPFLAGS += $(FFTW_CPPFLAGS) | - | -fMatrix.d fMatrix.df pic/fMatrix.o fMatrix.o: CPPFLAGS += $(FFTW_CPPFLAGS) | - | -fNDArray.d fNDArray.df pic/fNDArray.o fNDArray.o: CPPFLAGS += $(FFTW_CPPFLAGS) | - | -oct-fftw.d oct-fftw.df pic/oct-fftw.o oct-fftw.o: CPPFLAGS += $(FFTW_CPPFLAGS) I made these changes in my automake patch. | @@ -724,7 +724,7 @@ | DLD_FUNCTIONS_lib__magick_read___la_LIBADD = $(OCT_LINK_DEPS) $(MAGICK_LDFLAGS) $(MAGICK_LIBS) | | DLD-FUNCTIONS/convhull.df: CPPFLAGS += $(QHULL_CPPFLAGS) | -DLD_FUNCTIONS_libconvhull_la_CPPFLAGS = $(AM_CPPFLAGS) $(QHULL_CPPFLAGS) | +DLD_FUNCTIONS_libconvhulln_la_CPPFLAGS = $(AM_CPPFLAGS) $(QHULL_CPPFLAGS) | DLD_FUNCTIONS_libconvhulln_la_LIBADD = $(OCT_LINK_DEPS) $(QHULL_LDFLAGS) $(QHULL_LIBS) I changed the name of the convnull.df file dependency and folded this change into my automake patch. | | diff --git a/ChangeLog b/ChangeLog | --- a/ChangeLog | +++ b/ChangeLog | @@ -1,6 +1,10 @@ | 2009-10-29 Thomas Treichl | | * configure.in: Add support for dlopen on Mac systems. | + | +2009-10-21 David Grundberg | + | + * configure.ac: Use AMD_CPPFLAGS while checking for UMFPACK. | | 2009-10-20 Jaroslav Hajek I applied this patch to the current sources. Thanks, jwe From jwe at octave.org Mon Nov 9 13:23:30 2009 From: jwe at octave.org (John W. Eaton) Date: Mon, 9 Nov 2009 14:23:30 -0500 Subject: gnulib and automake In-Reply-To: <19189.148.970534.7634@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> Message-ID: <19192.27698.157200.992712@segfault.lan> I've placed another updated version of the automake patch here: http://jweaton.org/automake-diffs.gz This version of the patch should apply cleanly to the the current tip of the public Octave hg archive on savannah. I think it addresses all problems reported so far. If I've missed something, let me know what's broken. I'd like to check in this change within the next day or two. jwe From lindnerben at gmx.net Mon Nov 9 14:08:18 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Mon, 09 Nov 2009 21:08:18 +0100 Subject: gnulib and automake In-Reply-To: <19189.148.970534.7634@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> Message-ID: <4AF876B2.9060202@gmx.net> John W. Eaton wrote: > > Ah, but Windows doesn't have symbolic links and $(LN_S) is just cp, so > I guess this fails. Windows has a kind of "symbolic links", but only with absolute paths, not with relative paths. But I'm not sure if they are supported in msys. So you can't do what you can do with links on unix filesystems > OK, I think what we need to do is > > cd DLD-FUNCTIONS && $(LN_S) .libs/foo.dll foo.oct > > so that it will work correctly with either cp or "ln -s". I've made a > change that should do this correctly now. The updated versinon of my > patch is now on http://jweaton.org/automake-diffs.gz. This version of > the patch includes all the other changes I made on Friday. Works fine, make now completes beyond building all dld-functions. It's stuck building the doumentation, but I expected that. I need to translate my local patches and get shared libstdc++ working with libtool to get octave finally up and running thanks so far benjamin From lindnerben at gmx.net Mon Nov 9 14:36:15 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Mon, 09 Nov 2009 21:36:15 +0100 Subject: gnulib and automake In-Reply-To: <19192.27698.157200.992712@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <19192.27698.157200.992712@segfault.lan> Message-ID: <4AF87D3F.6010604@gmx.net> John W. Eaton wrote: > I've placed another updated version of the automake patch here: > > http://jweaton.org/automake-diffs.gz > > This version of the patch should apply cleanly to the the current tip > of the public Octave hg archive on savannah. I think it addresses all > problems reported so far. If I've missed something, let me know > what's broken. I'd like to check in this change within the next day > or two. Ok, not sure if I picked up the last updated patch or not, so I rechecked. Works fine until building the documentation, which I expect to fail at the current stage. benjamin From godfrey at isl.stanford.edu Mon Nov 9 15:31:13 2009 From: godfrey at isl.stanford.edu (Michael D. Godfrey) Date: Mon, 09 Nov 2009 22:31:13 +0100 Subject: Build error: __init_fltk__ missing Message-ID: <4AF88A21.3070608@isl.stanford.edu> Program received signal SIGSEGV, Segmentation fault. 0x000000396727f440 in ?? () from /usr/lib64/nvidia/libGL.so.1 I tried a build without the new automake and it fails the same way. My experience is that while OpenGL does lots of good stuff, it also has its share of quirks. This is one of them. Michael From Thomas.Treichl at gmx.net Tue Nov 10 02:38:11 2009 From: Thomas.Treichl at gmx.net (Thomas Treichl) Date: Tue, 10 Nov 2009 09:38:11 +0100 Subject: gnulib and automake In-Reply-To: <19192.27698.157200.992712@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <19192.27698.157200.992712@segfault.lan> Message-ID: <4AF92673.3010109@gmx.net> John W. Eaton schrieb: > I've placed another updated version of the automake patch here: > > http://jweaton.org/automake-diffs.gz > > This version of the patch should apply cleanly to the the current tip > of the public Octave hg archive on savannah. I think it addresses all > problems reported so far. If I've missed something, let me know > what's broken. I'd like to check in this change within the next day > or two. Everything worked fine on Mac OS X 10.4. Thomas From individ at acc.umu.se Tue Nov 10 03:02:00 2009 From: individ at acc.umu.se (David Grundberg) Date: Tue, 10 Nov 2009 10:02:00 +0100 Subject: gnulib and automake In-Reply-To: <19192.27698.157200.992712@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <19192.27698.157200.992712@segfault.lan> Message-ID: <4AF92C08.8050807@acc.umu.se> John W. Eaton wrote: > I've placed another updated version of the automake patch here: > > http://jweaton.org/automake-diffs.gz > > This version of the patch should apply cleanly to the the current tip > of the public Octave hg archive on savannah. I think it addresses all > problems reported so far. If I've missed something, let me know > what's broken. I'd like to check in this change within the next day > or two. > > jwe > I needed to add a backslash. Once I did that, it builds the executable (but no documentation or check). Attaching patch. Regards, David -------------- next part -------------- A non-text attachment was scrubbed... Name: missingbslash.patch Type: text/x-diff Size: 429 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091110/d1b2bb84/attachment.bin From godfrey at isl.stanford.edu Tue Nov 10 03:31:02 2009 From: godfrey at isl.stanford.edu (Michael Godfrey) Date: Tue, 10 Nov 2009 10:31:02 +0100 Subject: gnulib and automake In-Reply-To: <19192.27698.157200.992712@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <19192.27698.157200.992712@segfault.lan> Message-ID: <4AF932D6.5010307@isl.stanford.edu> > > This version of the patch should apply cleanly to the the current tip > of the public Octave hg archive on savannah. Worked without problem on Fedora FC11 x86_64. Michael From jwe at octave.org Tue Nov 10 12:27:35 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 10 Nov 2009 13:27:35 -0500 Subject: gnulib and automake (a fix?) In-Reply-To: <5AAD953D-523D-46FA-B7F9-509666A2E238@mac.com> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <420fb9e60910280944l1479037cj939059e5b4b95fa@mail.gmail.com> <19176.31314.572679.656960@segfault.lan> <420fb9e60910281230k5267e6e7h70f0b4352812e726@mail.gmail.com> <19176.41013.46982.260285@segfault.lan> <420fb9e60910281314s28d7f61sa7d701d7fb48736d@mail.gmail.com> <19176.45899.330498.302231@segfault.lan> <19176.58906.848113.829594@segfault.lan> <5AAD953D-523D-46FA-B7F9-509666A2E238@mac.com> Message-ID: <19193.45207.8120.111446@segfault.lan> On 30-Oct-2009, Ben Abbott wrote: | The attached resolves the problem for John's example. The following | also ran without incident. | | geometryimages ('voronoi', 'eps'); | geometryimages ('triplot', 'eps'); | geometryimages ('griddata', 'eps'); | geometryimages ('convhull', 'eps'); I applied the changeset. Thanks, jwe From jwe at octave.org Tue Nov 10 12:36:22 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 10 Nov 2009 13:36:22 -0500 Subject: gnulib and automake In-Reply-To: <4AF876B2.9060202@gmx.net> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <4AF876B2.9060202@gmx.net> Message-ID: <19193.45734.551735.424206@segfault.lan> On 9-Nov-2009, Benjamin Lindner wrote: | John W. Eaton wrote: | > | > Ah, but Windows doesn't have symbolic links and $(LN_S) is just cp, so | > I guess this fails. | | Windows has a kind of "symbolic links", but only with absolute paths, | not with relative paths. But I'm not sure if they are supported in msys. | So you can't do what you can do with links on unix filesystems | | > OK, I think what we need to do is | > | > cd DLD-FUNCTIONS && $(LN_S) .libs/foo.dll foo.oct | > | > so that it will work correctly with either cp or "ln -s". I've made a | > change that should do this correctly now. The updated versinon of my | > patch is now on http://jweaton.org/automake-diffs.gz. This version of | > the patch includes all the other changes I made on Friday. | | Works fine, | make now completes beyond building all dld-functions. | It's stuck building the doumentation, but I expected that. | I need to translate my local patches and get shared libstdc++ working | with libtool to get octave finally up and running Does it link and run now, even without a shared libstdc++? What are the problems with building the documentation? Is it anything that we should fix before checking the the changes to the main development branch? If not, then I'd like to go ahead and check it in today. Thanks, jwe From lindnerben at gmx.net Tue Nov 10 13:05:05 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Tue, 10 Nov 2009 20:05:05 +0100 Subject: gnulib and automake In-Reply-To: <19193.45734.551735.424206@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <4AF876B2.9060202@gmx.net> <19193.45734.551735.424206@segfault.lan> Message-ID: <4AF9B961.1070502@gmx.net> > | make now completes beyond building all dld-functions. > | It's stuck building the doumentation, but I expected that. > | I need to translate my local patches and get shared libstdc++ working > | with libtool to get octave finally up and running > > Does it link and run now, even without a shared libstdc++? Yes it linkes all executables and libraries. It also in principle runs, but there are issues with throwing (and catching) exceptions across dll's if you don't link against shared libstdc++, so I prefer to use it. > What are the problems with building the documentation? Is it anything > that we should fix before checking the the changes to the main > development branch? No, this is a pure msys issue. I use MiKTeX for building documentation. MiKTeX, as native win application, uses windows style paths. However, ocatve's configure procedure is run within msys, and uses thus msys style paths, which - consequently - miktex does not understand. > If not, then I'd like to go ahead and check it in > today. go ahead. benjamin From jwe at octave.org Tue Nov 10 15:34:40 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 10 Nov 2009 16:34:40 -0500 Subject: gnulib and automake In-Reply-To: <4AF9B961.1070502@gmx.net> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <4AF876B2.9060202@gmx.net> <19193.45734.551735.424206@segfault.lan> <4AF9B961.1070502@gmx.net> Message-ID: <19193.56432.620743.620783@segfault.lan> On 10-Nov-2009, Benjamin Lindner wrote: | No, this is a pure msys issue. I use MiKTeX for building documentation. | MiKTeX, as native win application, uses windows style paths. | However, ocatve's configure procedure is run within msys, and uses thus | msys style paths, which - consequently - miktex does not understand. Can you send details? I'd like to fix this so that it just works without requiring you to patch Octave's Makefiles. | > If not, then I'd like to go ahead and check it in | > today. | | go ahead. I've checked it in. jwe From linuxchristian at gmail.com Tue Nov 10 16:08:47 2009 From: linuxchristian at gmail.com (=?ISO-8859-1?Q?Christian_Br=E6dstrup?=) Date: Tue, 10 Nov 2009 23:08:47 +0100 Subject: [Octave] Improving Octave for large files Message-ID: Hi, I have been looking for some time after a cool GNU project to help on and the Octave project just what I was looking for. I have been following the Octave project for sometime (looking at the code and sitting om the mailinglist) and have now decided to do some real work if possible. I have been looking in the PROJECTS file in the source and wanted to hear if anyone is working on the problem with large files that Juhana K. Kouhia talks about (I couldn't find any code in the src/load-save.cc file to indicate that)? I have a friend working on the TPIE library ( http://www.madalgo.au.dk/Trac-tpie/) and thought it would fit nicely into the octave source. Does anyone have any concerns about including the TPIE library or any comments about how best to add the functionality. Cheers, Christian Br?dstrup -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091110/b8ea15e9/attachment.html From dbateman at dbateman.org Tue Nov 10 17:51:20 2009 From: dbateman at dbateman.org (David Bateman) Date: Wed, 11 Nov 2009 00:51:20 +0100 Subject: [Octave] Improving Octave for large files In-Reply-To: References: Message-ID: <4AF9FC78.6050608@dbateman.org> Christian Br?dstrup wrote: > I have > been looking in the PROJECTS file in the source and wanted to hear if anyone > is working on the problem with large files that Juhana K. Kouhia talks about > (I couldn't find any code in the src/load-save.cc file to indicate that)? I > have a friend working on the TPIE library ( > http://www.madalgo.au.dk/Trac-tpie/) and thought it would fit nicely into > the octave source. Does anyone have any concerns about including the TPIE > library or any comments about how best to add the functionality. > > That idea was proposed in 1994 http://old.nabble.com/Octave-question-to9226868.html#a9226868 and things have perhaps moved a bit since. I'd say the large file issues now are two fold 1) Data sets with more elements that 2^31 due to 64-bit indexing. The ability to handle such datasets is in Octave but poorly tested. The loading and saving of files for such datasets is not however tested though the HDF5 formats should be able to handle this 2) Large data sets tend to go hand in hand with large computational problems, and the parallelisation and distribution of a database across many nodes could be improved I'm sorry I don't know really what TPIE was to offer, but if as I suspect it defers reading data from a file till its needed. In this case to integrate TPIE probably means implementing user types from the ground up (right down to a reimplementation of the Array class. Is the benefit worth the cost? D. -- David Bateman dbateman at dbateman.org 35 rue Gambetta +33 1 46 04 02 18 (Home) 92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob) From jwe at octave.org Tue Nov 10 18:50:36 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 10 Nov 2009 19:50:36 -0500 Subject: hardcopy support for gl-render and the fltk_backend In-Reply-To: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com> References: <420fb9e60910131043h12b23de1ld05e437c36a39c70@mail.gmail.com> Message-ID: <19194.2652.911142.327290@segfault.lan> On 13-Oct-2009, Shai Ayal wrote: | I attach a changeset which adds postscript output to the fltk backend, | based on the gl-renderer and the gl2ps library | (http://www.geuz.org/gl2ps). | This changeset is relatively big because the gl2ps library is | distributed as 2 files - gl2ps.c and gl2ps.h which need to be included | in the distribution of the project using it. There is no binary | library. | to use : | backend("fltk"); plot(randn(1e3,1)); print("test.eps") | | Limitations (which I will try to fix in the future): | 1. no support for images | 2. only supports the postscript core fonts Helvetica, Times-Roman, | Courier, Symbol, ZapfDingbats (defaults to Helvetica) | 3. no support for bold/italic fonts | 4. outputs only eps I made some additional changes (mostly style fixes plus adapting to the new build system) and checked in this patch. Thanks, jwe From jwe at octave.org Tue Nov 10 22:17:01 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 10 Nov 2009 23:17:01 -0500 Subject: Octave loops infinitely in dlamc3_ from /usr/lib/liblapack.so In-Reply-To: <1257184471.3934.1.camel@sh-t400> References: <26114361.post@talk.nabble.com> <69d8d540911020158i228239fbpd88e01baea7aea7a@mail.gmail.com> <128f38bd0911020222t793c917doea9745f696c91605@mail.gmail.com> <69d8d540911020224o5043ac70y588f33c055a1a2b1@mail.gmail.com> <128f38bd0911020227y871b39ep5a69e4344fb3454e@mail.gmail.com> <69d8d540911020240h43d33a25rfd9bdaff8e035827@mail.gmail.com> <19183.549.952812.823846@segfault.lan> <69d8d540911020911r6287f8b0r977776f582b5f41f@mail.gmail.com> <1257184471.3934.1.camel@sh-t400> Message-ID: <19194.15037.131248.885303@segfault.lan> On 2-Nov-2009, S?ren Hauberg wrote: | man, 02 11 2009 kl. 18:11 +0100, skrev Jaroslav Hajek: | > I think the BLAS and LAPACK are a little special in the sense that | > they're (AFAIK) the only strong requirement for Octave. If any other | > dependency is missing, Octave will build and work, though with some | > crippled functionality. | > OTOH, BLAS and LAPACK are now almost universally available, so maybe | > nobody actually needs this feature. In that case, I think it's fine to | > drop these sources. It will also plausibly reduce Octave's code size. | | One advantage of dropping BLAS and LAPACK from the sources is that the | user don't end up using these by accident instead of using the system | libraries. I committed the following changeset which removes the subset of the reference BLAS and LAPACK sources from the Octave source tree: http://hg.savannah.gnu.org/hgweb/octave/rev/cfd0aa788ae1 If somehow people think that any further discussion about this is needed, then please use the maintainers list. Thanks, jwe From paulo_cesar at udistrital.edu.co Tue Nov 10 23:48:02 2009 From: paulo_cesar at udistrital.edu.co (Paulo Cesar Coronado) Date: Wed, 11 Nov 2009 00:48:02 -0500 (COT) Subject: Spanish Translation Message-ID: <13508.190.24.181.227.1257918482.squirrel@mail.udistrital.edu.co> At the Universidad Distrital in Bogota, Colombia. we are migrating from Matlab to octave in some of our subjects like Linear Algebra, Calculus and Physics and we are using it in some new research projects. The Official Manual is so useful but it is in english and is to difficult for our students to understand some parts of its content (All of our students are native spanish speakers just beginning with basic/intermediate english courses). I translated some parts of the content (about 100 pages and growing) but i am not sure if someone in your organization is working in the spanish traslation or if exists some official spanish translation. To do not "reinvent the wheel", we would be very happy and pleased to collaborate with the translation work, and share what we have done so far. Thanks in advance for your attention. PAULO CESAR ---------------------------------------------------------------------- 1948-2008:SESENTA A?OS DE VIDA UNIVERSITARIA *********************************** Este correo y cualquier archivo anexo son confidenciales y para uso exclusivo de la persona o entidad de destino. Esta comunicacion puede contener informacion protegida por el privilegio de cliente-abogado. Si usted ha recibido este correo por error, equivocacion u omision queda estrictamente prohibido la utilizacion, copia, reimpresion o reenvio del mismo. En tal caso, favor notificar en forma inmediata al remitente From marco_atzeri at yahoo.it Wed Nov 11 01:51:28 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Wed, 11 Nov 2009 07:51:28 +0000 (GMT) Subject: WIN32 problem on liboctave/kpse.cc Message-ID: <205925.28583.qm@web25507.mail.ukl.yahoo.com> Hi, building on latest $ hg tip changeset: 9799:cfd0aa788ae1 tag: tip user: John W. Eaton date: Tue Nov 10 23:07:25 2009 -0500 summary: remove reference blas and lapack sources this block on liboctave/kpse.cc is causing win32lib.h (that does not esist) to be included in cygwin. #if defined(__MINGW32__) #include #include #include #elif defined(WIN32) #define __STDC__ 1 #ifndef _MSC_VER #include "win32lib.h" #endif #endif /* not WIN32 */ This fault is really new, so some of the latest changesets caused it, but kpse.cc seems untouched from longtime so I am bit puzzled. Marco From highegg at gmail.com Wed Nov 11 02:21:04 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 11 Nov 2009 09:21:04 +0100 Subject: gnulib and automake In-Reply-To: <19193.56432.620743.620783@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <4AF876B2.9060202@gmx.net> <19193.45734.551735.424206@segfault.lan> <4AF9B961.1070502@gmx.net> <19193.56432.620743.620783@segfault.lan> Message-ID: <69d8d540911110021h5ebf80beg7ce495b3ebe3c7b7@mail.gmail.com> On Tue, Nov 10, 2009 at 10:34 PM, John W. Eaton wrote: > On 10-Nov-2009, Benjamin Lindner wrote: > > | No, this is a pure msys issue. I use MiKTeX for building documentation. > | MiKTeX, as native win application, uses windows style paths. > | However, ocatve's configure procedure is run within msys, and uses thus > | msys style paths, which - consequently - miktex does not understand. > > Can you send details? I'd like to fix this so that it just works > without requiring you to patch Octave's Makefiles. > > | > If not, then I'd like to go ahead and check it in > | > today. > | > | go ahead. > > I've checked it in. > > jwe > First thoughts (from a first-time libtool&automake user): It would be nice to specify the versions needed. I tried with my system autoconf 2.61, automake 1.10 and libtool 1.5.26 and build failed complaining that automake 1.11 is required. I compiled autoconf 2.64 & automake 1.11 and tried again, but this time I got weird messages about AC_PROG_LIBTOOL missing in configure.ac. Adding it there didn't help though. I finally installed built also libtool 2.2.6a and everything went OK. I think it would be nice to discover the minimum required levels. So my working config is autoconf 2.64 + automake 1.11 + libtool 2.2.6a but that does not help anything since these are all newest versions. What's yours? Otherwise, the build went smoothly, even with multiprocessing (make -j2). It doesn't seem to be significantly slower. make install was visibly slower, but that doesn't matter to me much. All in all, no big deal for self-builders. -- 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/20091111/c8279773/attachment.html From shaiay at gmail.com Wed Nov 11 02:31:29 2009 From: shaiay at gmail.com (Shai Ayal) Date: Wed, 11 Nov 2009 10:31:29 +0200 Subject: Spanish Translation In-Reply-To: <13508.190.24.181.227.1257918482.squirrel@mail.udistrital.edu.co> References: <13508.190.24.181.227.1257918482.squirrel@mail.udistrital.edu.co> Message-ID: <420fb9e60911110031i4bc7b405w6f486b93fa2515f6@mail.gmail.com> On Wed, Nov 11, 2009 at 7:48 AM, Paulo Cesar Coronado wrote: > To do not "reinvent the wheel", we would be very happy and pleased to > collaborate with the translation work, and share what we have done so far. > It's good that you asked: There was quite a lot of work done on translation infrastructure already: http://octave.sourceforge.net/translation.html There is also one actual translation: http://octave.sourceforge.net/pt_BR/index.html Shai > > Thanks in advance for your attention. > > PAULO CESAR > > > ---------------------------------------------------------------------- > ? ? ? ?1948-2008:SESENTA A?OS DE VIDA UNIVERSITARIA > ? ? ? ? ? *********************************** > Este correo y cualquier archivo anexo son confidenciales y para uso > exclusivo de la persona o entidad de destino. Esta comunicacion puede > contener informacion protegida por el privilegio de cliente-abogado. Si > usted ha recibido este correo por error, equivocacion u omision queda > estrictamente prohibido la utilizacion, copia, reimpresion o reenvio del > mismo. En tal caso, favor notificar en forma inmediata al remitente > From dbateman at dbateman.org Wed Nov 11 02:42:41 2009 From: dbateman at dbateman.org (David Bateman) Date: Wed, 11 Nov 2009 09:42:41 +0100 Subject: Spanish Translation In-Reply-To: <420fb9e60911110031i4bc7b405w6f486b93fa2515f6@mail.gmail.com> References: <13508.190.24.181.227.1257918482.squirrel@mail.udistrital.edu.co> <420fb9e60911110031i4bc7b405w6f486b93fa2515f6@mail.gmail.com> Message-ID: <4AFA7901.3020203@dbateman.org> Shai Ayal wrote: > On Wed, Nov 11, 2009 at 7:48 AM, Paulo Cesar Coronado > wrote: > >> To do not "reinvent the wheel", we would be very happy and pleased to >> collaborate with the translation work, and share what we have done so far. >> >> > It's good that you asked: There was quite a lot of work done on > translation infrastructure already: > http://octave.sourceforge.net/translation.html > There is also one actual translation: > http://octave.sourceforge.net/pt_BR/index.html > > In fact there was also quite a lot of work on a Spanish translation. Though its not packaged yet.. See the SVN at http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/language/es/ there appears that 1120 functions already have Spanish translations, which is already pretty complete. I'm sure it'll be in the next release. D. -- David Bateman dbateman at dbateman.org 35 rue Gambetta +33 1 46 04 02 18 (Home) 92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob) From michael.goffioul at gmail.com Wed Nov 11 03:42:49 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Wed, 11 Nov 2009 09:42:49 +0000 Subject: WIN32 problem on liboctave/kpse.cc In-Reply-To: <205925.28583.qm@web25507.mail.ukl.yahoo.com> References: <205925.28583.qm@web25507.mail.ukl.yahoo.com> Message-ID: <128f38bd0911110142ld3f8802x4b22ba6ba9946669@mail.gmail.com> On Wed, Nov 11, 2009 at 7:51 AM, Marco Atzeri wrote: > Hi, > building on latest > $ hg tip > changeset: ? 9799:cfd0aa788ae1 > tag: ? ? ? ? tip > user: ? ? ? ?John W. Eaton > date: ? ? ? ?Tue Nov 10 23:07:25 2009 -0500 > summary: ? ? remove reference blas and lapack sources > > this block on liboctave/kpse.cc > is causing win32lib.h (that does not esist) to be > included in cygwin. > > #if defined(__MINGW32__) > #include > #include > #include > #elif defined(WIN32) > #define __STDC__ 1 > #ifndef _MSC_VER > #include "win32lib.h" > #endif > #endif /* not WIN32 */ > > This fault is really new, so some of the latest changesets > caused it, but kpse.cc seems untouched from longtime > so I am bit puzzled. Maybe because WIN32 is now defined under cygwin, while it used to not be defined before. Might be a configure issue. Michael. From j4r.e4o at gmail.com Wed Nov 11 05:08:14 2009 From: j4r.e4o at gmail.com (Javier Enciso) Date: Wed, 11 Nov 2009 12:08:14 +0100 Subject: Spanish Translation In-Reply-To: <4AFA7901.3020203@dbateman.org> References: <13508.190.24.181.227.1257918482.squirrel@mail.udistrital.edu.co> <420fb9e60911110031i4bc7b405w6f486b93fa2515f6@mail.gmail.com> <4AFA7901.3020203@dbateman.org> Message-ID: <4AFA9B1E.7070601@googlemail.com> Hi Paulo, I'm very glad Universidad Distrital is migrating to Octave, I hope other Colombian public universities follow the path you are about to trace. I have spent a couple of months in the translation of the help strings for Octave functions. So far it counts for 1120 translated functions (only 290 help strings are left - according to my last record). Of course, my work can be improved (it hasn't been tested yet) and additional help is very welcome..., please feel free to contact me to discuss about it. Regards, Javier P.S: I'm former student of the Universidad Nacional de Colombia. >> On Wed, Nov 11, 2009 at 7:48 AM, Paulo Cesar Coronado >> wrote: >> >>> To do not "reinvent the wheel", we would be very happy and pleased to >>> collaborate with the translation work, and share what we have done so >>> far. From linuxchristian at gmail.com Wed Nov 11 06:38:39 2009 From: linuxchristian at gmail.com (=?ISO-8859-1?Q?Christian_Br=E6dstrup?=) Date: Wed, 11 Nov 2009 13:38:39 +0100 Subject: [Octave] Improving Octave for large files In-Reply-To: <4AF9FC78.6050608@dbateman.org> References: <4AF9FC78.6050608@dbateman.org> Message-ID: Okay, I didn't know the feature request was that old. When the code is so untested then perhaps the best thing to do is to create some large files and see how Octave handes them to begin with. As far as I have been told TPIE sorts all the data from the input file and then only access the data it needs after the sort (to save memory space). The reason I suggested the library is because I know it is actively developed at a university level and that the group uses it to handle very very large sets of satelite data to do 3D terrain mapping. But if using the library involves rewriting a lot of good code it would be foolish to use it. On Wed, Nov 11, 2009 at 12:51 AM, David Bateman wrote: > Christian Br?dstrup wrote: > >> I have >> been looking in the PROJECTS file in the source and wanted to hear if >> anyone >> is working on the problem with large files that Juhana K. Kouhia talks >> about >> (I couldn't find any code in the src/load-save.cc file to indicate that)? >> I >> have a friend working on the TPIE library ( >> http://www.madalgo.au.dk/Trac-tpie/) and thought it would fit nicely into >> the octave source. Does anyone have any concerns about including the TPIE >> library or any comments about how best to add the functionality. >> >> >> > > That idea was proposed in 1994 > > http://old.nabble.com/Octave-question-to9226868.html#a9226868 > > and things have perhaps moved a bit since. I'd say the large file issues > now are two fold > > 1) Data sets with more elements that 2^31 due to 64-bit indexing. The > ability to handle such datasets is in Octave but poorly tested. The loading > and saving of files for such datasets is not however tested though the HDF5 > formats should be able to handle this > 2) Large data sets tend to go hand in hand with large computational > problems, and the parallelisation and distribution of a database across many > nodes could be improved > > I'm sorry I don't know really what TPIE was to offer, but if as I suspect > it defers reading data from a file till its needed. In this case to > integrate TPIE probably means implementing user types from the ground up > (right down to a reimplementation of the Array class. Is the benefit worth > the cost? > > D. > > -- > > David Bateman dbateman at dbateman.org > 35 rue Gambetta +33 1 46 04 02 18 (Home) > 92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091111/e5a59795/attachment-0001.html From individ at acc.umu.se Wed Nov 11 07:00:45 2009 From: individ at acc.umu.se (David Grundberg) Date: Wed, 11 Nov 2009 14:00:45 +0100 Subject: gnulib and automake In-Reply-To: <69d8d540911110021h5ebf80beg7ce495b3ebe3c7b7@mail.gmail.com> References: <19121.21838.419944.184758@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <4AF876B2.9060202@gmx.net> <19193.45734.551735.424206@segfault.lan> <4AF9B961.1070502@gmx.net> <19193.56432.620743.620783@segfault.lan> <69d8d540911110021h5ebf80beg7ce495b3ebe3c7b7@mail.gmail.com> Message-ID: <4AFAB57D.4080301@acc.umu.se> Jaroslav Hajek wrote: > > > On Tue, Nov 10, 2009 at 10:34 PM, John W. Eaton > wrote: > > On 10-Nov-2009, Benjamin Lindner wrote: > > | No, this is a pure msys issue. I use MiKTeX for building > documentation. > | MiKTeX, as native win application, uses windows style paths. > | However, ocatve's configure procedure is run within msys, and > uses thus > | msys style paths, which - consequently - miktex does not understand. > > Can you send details? I'd like to fix this so that it just works > without requiring you to patch Octave's Makefiles. > > | > If not, then I'd like to go ahead and check it in > | > today. > | > | go ahead. > > I've checked it in. > > jwe > > > First thoughts (from a first-time libtool&automake user): > It would be nice to specify the versions needed. I tried with my > system autoconf 2.61, automake 1.10 and libtool 1.5.26 and build > failed complaining that automake 1.11 is required. I compiled autoconf > 2.64 & automake 1.11 and tried again, but this time I got weird > messages about AC_PROG_LIBTOOL missing in configure.ac > . Adding it there didn't help though. I finally > installed built also libtool 2.2.6a and everything went OK. > > I think it would be nice to discover the minimum required levels. > > So my working config is > autoconf 2.64 + automake 1.11 + libtool 2.2.6a > but that does not help anything since these are all newest versions. > What's yours? > > Otherwise, the build went smoothly, even with multiprocessing (make > -j2). It doesn't seem to be significantly slower. make install was > visibly slower, but that doesn't matter to me much. > > All in all, no big deal for self-builders. > > -- > RNDr. Jaroslav Hajek > computing expert & GNU Octave developer > Aeronautical Research and Test Institute (VZLU) > Prague, Czech Republic > url: www.highegg.matfyz.cz Had the same problems myself, ended up building and installing the latest releases much as you did. I think this line LT_PREREQ([2.2.2]) does state a lower version than 2.2.6, but maybe it can be even lower? Notice that LT_INIT and friends aren't in libtool 1.5, and AC_PROG_LIBTOOL is deprecated in later versions. Maybe some m4 magic could check whether LT_INIT is defined and put out a message to update to a newer libtool. David From jwe at octave.org Wed Nov 11 09:01:36 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 11 Nov 2009 10:01:36 -0500 Subject: gnulib and automake In-Reply-To: <69d8d540911110021h5ebf80beg7ce495b3ebe3c7b7@mail.gmail.com> References: <19121.21838.419944.184758@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <4AF876B2.9060202@gmx.net> <19193.45734.551735.424206@segfault.lan> <4AF9B961.1070502@gmx.net> <19193.56432.620743.620783@segfault.lan> <69d8d540911110021h5ebf80beg7ce495b3ebe3c7b7@mail.gmail.com> Message-ID: <19194.53712.157068.832208@segfault.lan> On 11-Nov-2009, Jaroslav Hajek wrote: | First thoughts (from a first-time libtool&automake user): | It would be nice to specify the versions needed. We do, with the lines AM_INIT_AUTOMAKE([1.11 tar-ustar]) AC_PREREQ(2.60) LT_PREREQ([2.2.2]) in the configure.ac script. | I tried with my system | autoconf 2.61, automake 1.10 and libtool 1.5.26 and build failed complaining | that automake 1.11 is required. I compiled autoconf 2.64 & automake 1.11 and | tried again, but this time I got weird messages about AC_PROG_LIBTOOL | missing in configure.ac. Adding it there didn't help though. I finally | installed built also libtool 2.2.6a and everything went OK. In the libtool NEWS file, I see New in 1.9b: 2004-08-29; CVS version 1.5a, Libtool team: [...] * New LT_PREREQ macro for specifying minimum libtool requirement. * New LT_INIT interface replaces AC_PROG_LIBTOOL, AC_ENABLE_SHARED, AC_DISABLE_SHARED, AC_ENABLE_STATIC, AC_DISABLE_STATIC, AC_ENABLE_FAST_INSTALL, AC_DISABLE_FAST_INSTALL, AC_LIBTOOL_DLOPEN, AC_LIBTOOL_WIN32_DLL and AC_LIBTOOL_PIC_MODE. Use autoupdate to modernise your configure.ac files after installing this release. So LT_PREREQ won't help if you don't have it... Since this might be a common problem for a while yet, I tried adding ifdef([SOMETHING_UNDEFINED], [], [ errprint([error: you must have Libtool 2.2.2 or a more recent version ]) m4exit([1])]) before the LT_PREREQ and LT_INIT lines in configure.ac. With this, autogen.sh produced the following messages: calling libtoolize... calling aclocal... error: you must have Libtool 2.2.2 or a more recent version generating source lists for liboctave/Makefile... vx-op-inc.mk is unchanged mx-op-inc.mk is unchanged smx-op-inc.mk is unchanged vx-op-src.mk is unchanged mx-op-src.mk is unchanged smx-op-src.mk is unchanged generating doc/interpreter/images.mk... images.mk is unchanged generating src/DLD-FUNCTIONS/module.mk... module.mk is unchanged calling autoheader... error: you must have Libtool 2.2.2 or a more recent version calling automake... calling autoconf... error: you must have Libtool 2.2.2 or a more recent version I was expecting m4exit([1]) and the "set -e" line in autogen.sh to cause the script to terminate after the first error. I checked in my change anyway (substituting LT_INIT for SOMETHING_UNDEFINED), but it would be great if someone could find out how to make the error exit actually work, so that it doesn't appear that the autogen script succeeds when it is not really working properly. | I think it would be nice to discover the minimum required levels. | | So my working config is | autoconf 2.64 + automake 1.11 + libtool 2.2.6a | but that does not help anything since these are all newest versions. What's | yours? I run Debian testing and frequently update, so I'm not a good test case for finding out the oldest possible versions. I have 2.64, 1.11, and 2.2.6. I'm pretty sure automake 1.11 and libtool 2.2.2 are required (someone already did a test for the libtool version number). I don't know about the autoconf version. The last time we checked, I think 2.60 was sufficient. If something newer is required now to work with automake 1.11 and libtool 2.2.2, then we should update the AC_PREREQ version. If 2.64 is required, then we can remove the definitions of m4_ifblank and m4_ifnblank from acinclude.m4. jwe From jwe at octave.org Wed Nov 11 09:04:31 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 11 Nov 2009 10:04:31 -0500 Subject: WIN32 problem on liboctave/kpse.cc In-Reply-To: <128f38bd0911110142ld3f8802x4b22ba6ba9946669@mail.gmail.com> References: <205925.28583.qm@web25507.mail.ukl.yahoo.com> <128f38bd0911110142ld3f8802x4b22ba6ba9946669@mail.gmail.com> Message-ID: <19194.53887.945507.836190@segfault.lan> On 11-Nov-2009, Michael Goffioul wrote: | On Wed, Nov 11, 2009 at 7:51 AM, Marco Atzeri wrote: | > Hi, | > building on latest | > $ hg tip | > changeset: ? 9799:cfd0aa788ae1 | > tag: ? ? ? ? tip | > user: ? ? ? ?John W. Eaton | > date: ? ? ? ?Tue Nov 10 23:07:25 2009 -0500 | > summary: ? ? remove reference blas and lapack sources | > | > this block on liboctave/kpse.cc | > is causing win32lib.h (that does not esist) to be | > included in cygwin. | > | > #if defined(__MINGW32__) | > #include | > #include | > #include | > #elif defined(WIN32) | > #define __STDC__ 1 | > #ifndef _MSC_VER | > #include "win32lib.h" | > #endif | > #endif /* not WIN32 */ | > | > This fault is really new, so some of the latest changesets | > caused it, but kpse.cc seems untouched from longtime | > so I am bit puzzled. | | Maybe because WIN32 is now defined under cygwin, while it used | to not be defined before. Might be a configure issue. What is defining WIN32 on Cygwin systems? Is GCC defining that by default now? Or is it some (unintentional) change in the configure script that is doing it? jwe From jwe at octave.org Wed Nov 11 09:47:45 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 11 Nov 2009 10:47:45 -0500 Subject: Fix for fltk zoom box problems In-Reply-To: <420fb9e60910101338n313dc4ecu5e97be2dd769e742@mail.gmail.com> References: <420fb9e60910090640l2e1f2315n4648463e131de80b@mail.gmail.com> <1255198991.4615.12.camel@sh-t400> <420fb9e60910101232j49d957d9gc6077d72bba5e09e@mail.gmail.com> <420fb9e60910101338n313dc4ecu5e97be2dd769e742@mail.gmail.com> Message-ID: <19194.56481.553944.308994@segfault.lan> On 10-Oct-2009, Shai Ayal wrote: | On Sat, Oct 10, 2009 at 9:32 PM, Shai Ayal wrote: | > On Sat, Oct 10, 2009 at 8:23 PM, S?ren Hauberg wrote: | >> fre, 09 10 2009 kl. 15:40 +0200, skrev Shai Ayal: | >>> I attach a (trivial) fix which should work -- it simply bypasses the | >>> OpenGL overlay and draws the zoom box (now in cool transparent grey!) | >>> normally. | >>> Please try | >> | >> Hey, this is quite neat. Due to driver issues I have not been able to | >> test with my Intel card, but this works great on my AMD card. | >> | >> Attached is a trivial change that | >> | >> ?* draws a border around the overlay, | >> ?* changes the colour to a Tango [1] colour. | >> | >> This is a pure visual change, so feel free to ignore it, though. | > | > I'll use it and send a complete changeset soon | I attach a changeset incorporating the Tange color & border. This | patch includes the previous patch I sent I applied this changeset. Thanks, jwe From paulo_cesar at udistrital.edu.co Wed Nov 11 10:59:43 2009 From: paulo_cesar at udistrital.edu.co (Paulo Cesar Coronado) Date: Wed, 11 Nov 2009 11:59:43 -0500 (COT) Subject: Spanish Translation Message-ID: <15074.190.24.181.227.1257958783.squirrel@mail.udistrital.edu.co> "Fiat Lux", thanks ---------------------------------------------------------------------- 1948-2008:SESENTA A?OS DE VIDA UNIVERSITARIA *********************************** Este correo y cualquier archivo anexo son confidenciales y para uso exclusivo de la persona o entidad de destino. Esta comunicacion puede contener informacion protegida por el privilegio de cliente-abogado. Si usted ha recibido este correo por error, equivocacion u omision queda estrictamente prohibido la utilizacion, copia, reimpresion o reenvio del mismo. En tal caso, favor notificar en forma inmediata al remitente From marco_atzeri at yahoo.it Wed Nov 11 11:27:05 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Wed, 11 Nov 2009 17:27:05 +0000 (GMT) Subject: WIN32 problem on liboctave/kpse.cc In-Reply-To: <19194.53887.945507.836190@segfault.lan> Message-ID: <581560.61031.qm@web25505.mail.ukl.yahoo.com> --- Mer 11/11/09, John W. Eaton ha scritto: > Da: John W. Eaton > Oggetto: Re: WIN32 problem on liboctave/kpse.cc > A: "Michael Goffioul" > Cc: "Marco Atzeri" , maintainers at octave.org > Data: Mercoled? 11 novembre 2009, 16:04 > On 11-Nov-2009, Michael Goffioul > wrote: > > | On Wed, Nov 11, 2009 at 7:51 AM, Marco Atzeri > wrote: > | > Hi, > | > building on latest > | > $ hg tip > | > changeset: ? 9799:cfd0aa788ae1 > | > tag: ? ? ? ? tip > | > user: ? ? ? ?John W. Eaton > | > date: ? ? ? ?Tue Nov 10 23:07:25 2009 -0500 > | > summary: ? ? remove reference blas and lapack > sources > | > > | > this block on liboctave/kpse.cc > | > is causing win32lib.h (that does not esist) to be > | > included in cygwin. > | > > | > #if defined(__MINGW32__) > | > #include > | > #include > | > #include > | > #elif defined(WIN32) > | > #define __STDC__ 1 > | > #ifndef _MSC_VER > | > #include "win32lib.h" > | > #endif > | > #endif /* not WIN32 */ > | > > | > This fault is really new, so some of the latest > changesets > | > caused it, but kpse.cc seems untouched from > longtime > | > so I am bit puzzled. > | > | Maybe because WIN32 is now defined under cygwin, while it > used > | to not be defined before. Might be a configure issue. > > What is defining WIN32 on Cygwin systems?? Is GCC > defining that by > default now?? Or is it some (unintentional) change in > the configure > script that is doing it? > > jwe Theorically WIN32 should be not defined. There is a strange section in config.h #if defined (_MSC_VER) #define __WIN32__ #define WIN32 /* missing parameters in macros */ #pragma warning (disable: 4003) /* missing implementations in template instantiation */ #pragma warning (disable: 4996) /* deprecated function names (FIXME?) */ #pragma warning (disable: 4661) #endif but it should NOT define WIN32 in any case. I will try to investigate with "g++ -E" what is pulling in the win32lib.h Marco From octave at nomad.inbox5.com Wed Nov 11 11:40:44 2009 From: octave at nomad.inbox5.com (Rik) Date: Wed, 11 Nov 2009 09:40:44 -0800 Subject: Minimum requirements for new builds In-Reply-To: References: Message-ID: > > ------------------------------------------------------------------------ > > Subject: > Re: gnulib and automake > From: > Jaroslav Hajek > Date: > Wed, 11 Nov 2009 09:21:04 +0100 > To: > "John W. Eaton" > > To: > "John W. Eaton" > CC: > octave maintainers mailing list > > > > First thoughts (from a first-time libtool&automake user): > It would be nice to specify the versions needed. I tried with my > system autoconf 2.61, automake 1.10 and libtool 1.5.26 and build > failed complaining that automake 1.11 is required. I compiled autoconf > 2.64 & automake 1.11 and tried again, but this time I got weird > messages about AC_PROG_LIBTOOL missing in configure.ac > . Adding it there didn't help though. I finally > installed built also libtool 2.2.6a and everything went OK. > > I think it would be nice to discover the minimum required levels. > > So my working config is > autoconf 2.64 + automake 1.11 + libtool 2.2.6a > but that does not help anything since these are all newest versions. > What's yours? These versions were worked out during the initial testing period. Automake >= 1.11 Libtool >= 2.2.2 Autoconf >= 2.6.0 The file configure.ac contains checks for all three program versions. The real question is why they didn't assert a warning when you tried to compile with older versions. --Rik From shaiay at gmail.com Wed Nov 11 11:42:50 2009 From: shaiay at gmail.com (Shai Ayal) Date: Wed, 11 Nov 2009 19:42:50 +0200 Subject: remove ftgl from dependencies Message-ID: <420fb9e60911110942r28658b16ied7575830d9d5cc8@mail.gmail.com> Hi I attach a patch to remove the check for FTGL from the configure script. I planned to use FTGL for text rendering in the fltk_backend, but Michael Goffioul implemented a text renderer on his own, obsoleting FTGL before it's first use. Shai -------------- next part -------------- A non-text attachment was scrubbed... Name: remove_ftgl.patch Type: text/x-diff Size: 2828 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091111/1644d593/attachment.bin From jwe at octave.org Wed Nov 11 11:52:21 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 11 Nov 2009 12:52:21 -0500 Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50 built by mingw-gcc-4.4.0 cannot be executed.) In-Reply-To: <128f38bd0910111302i1cb9404aib9be492140d4f145@mail.gmail.com> References: <20090930111533.90584.qmail@web3806.mail.bbt.yahoo.co.jp> <4ACA4046.8050005@gmx.net> <19153.62958.446247.732431@hugo.lan> <128f38bd0910111302i1cb9404aib9be492140d4f145@mail.gmail.com> Message-ID: <19194.63957.741562.585823@segfault.lan> On 11-Oct-2009, Michael Goffioul wrote: | On Sun, Oct 11, 2009 at 4:12 PM, John W. Eaton wrote: | > | diff -r a65c135a1deb configure.in | > | --- a/configure.in ? ? ?Mon Oct 05 19:22:13 2009 +0200 | > | +++ b/configure.in ? ? ?Mon Oct 05 20:30:33 2009 +0200 | > | @@ -847,6 +847,11 @@ | > | ? ? FLTK_CFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --cflags`" | > | ? ? FLTK_LDFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --ldflags`" | > | | > | + ?case "$canonical_host_type" in | > | + ?*-*-mingw*) | > | + ? ?FLTK_LDFLAGS="`echo $FLTK_LDFLAGS | sed -e 's+-mwindows++g'`" | > | + ?esac | > | + | > | ? ? AC_MSG_CHECKING(for OpenGL support in FLTK) | > | ? ? cat > conftest.cc < | ? ? #include | > | > Only *-*-mingw*? ?Would this also be a problem for *-*-msdosmsvc? | | No. The -mwindows flag is only GCC specific. I checked in the following change. http://hg.savannah.gnu.org/hgweb/octave/rev/f5126ea721e2 Is this OK? Or should we be more careful and try to only match -mwindows if it appears as a word by itself? Or is this change even needed now? jwe From godfrey at isl.stanford.edu Wed Nov 11 12:03:10 2009 From: godfrey at isl.stanford.edu (Michael D. Godfrey) Date: Wed, 11 Nov 2009 19:03:10 +0100 Subject: PS output from OpenGL Message-ID: <4AFAFC5E.60102@isl.stanford.edu> I tried it. First test worked just fine. I am on a trip now so have limited testing time, but it looks good. Thanks very much!! :-) Thinking about TeX interpretation? :-) :-) Michael From jwe at octave.org Wed Nov 11 12:06:07 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 11 Nov 2009 13:06:07 -0500 Subject: Brittleness with texinfo and version numbering In-Reply-To: References: <19156.22908.790892.25147@hugo.lan> <19161.64942.357946.819476@hugo.lan> Message-ID: <19194.64783.458210.748788@segfault.lan> On 17-Oct-2009, Rik wrote: | John W. Eaton wrote: | > On 13-Oct-2009, Rik wrote: | > | > | I agree it's a problem with texinfo, but I think it will take a longer | > | to fix it this way than simply avoiding the problem. | > | > The problem only shows up if you do a "make dist" on an Octave version | > from the hg archive, which isn't something that I expect to happen | > often. If I make a snapshot, then I use a "normal" version number. | > | > | This is fine. If it is a low frequency event then it is easier to avoid | it then to fix it. That was the point I was trying to convey regarding | texinfo as well. I sent a bug report about this problem to bug-texinfo at gnu.org. jwe From jwe at octave.org Wed Nov 11 12:09:52 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 11 Nov 2009 13:09:52 -0500 Subject: Minimum requirements for new builds In-Reply-To: References: Message-ID: <19194.65008.808825.70702@segfault.lan> On 11-Nov-2009, Rik wrote: | The file configure.ac contains checks for all three program versions. | The real question is why they didn't assert a warning when you tried to | compile with older versions. Jaroslav did say that I tried with my system autoconf 2.61, automake 1.10 and libtool 1.5.26 and build failed complaining that automake 1.11 is required. So the test for autoconf succeeded and the one for automake generated an error. The problem with libtool happened because the older version of libtool that he was using did not have LT_PREREQ or LT_INIT. I think my check for LT_INIT being undefined will help, but it would be better if it could make the autogen process stop at the point of the error instead of continuing on. jwe From octave at nomad.inbox5.com Wed Nov 11 12:16:45 2009 From: octave at nomad.inbox5.com (Rik) Date: Wed, 11 Nov 2009 10:16:45 -0800 Subject: Required versions of autotools In-Reply-To: References: Message-ID: > > I'm pretty sure automake 1.11 and libtool 2.2.2 are required (someone > already did a test for the libtool version number). > I did the testing for automake and libtool. Those version numbers are correct. > I don't know about the autoconf version. The last time we checked, > I think 2.60 was sufficient. If something newer is required now to > work with automake 1.11 and libtool 2.2.2, then we should update the > AC_PREREQ version. If 2.64 is required, then we can remove the > definitions of m4_ifblank and m4_ifnblank from acinclude.m4. > I didn't check the autoconf version. My platform is using 2.62 and seems to work fine. I seem to recall that moving to automake-1.11 or libtool-2.2.2 did push me up from autoconf-2.61. If no one else can verify a lower autoconf number then we should change the macro in configure.ac to at least require 2.62. --Rik From jwe at octave.org Wed Nov 11 12:17:23 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 11 Nov 2009 13:17:23 -0500 Subject: remove ftgl from dependencies In-Reply-To: <420fb9e60911110942r28658b16ied7575830d9d5cc8@mail.gmail.com> References: <420fb9e60911110942r28658b16ied7575830d9d5cc8@mail.gmail.com> Message-ID: <19194.65459.335003.184224@segfault.lan> On 11-Nov-2009, Shai Ayal wrote: | I attach a patch to remove the check for FTGL from the configure script. | I planned to use FTGL for text rendering in the fltk_backend, but | Michael Goffioul implemented a text renderer on his own, obsoleting | FTGL before it's first use. I checked it in. Thanks, jwe From jwe at octave.org Wed Nov 11 12:48:29 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 11 Nov 2009 13:48:29 -0500 Subject: new file, oct-mem.h In-Reply-To: References: Message-ID: <19195.1789.391727.856238@segfault.lan> On 4-Nov-2009, Rik wrote: | Isn't the configure check preferable in that it catches the assumption | at compile time rather than run time? It would be annoying to spend 45 | minutes compiling the sources only to have octave complain and demand to | be re-compiled with the correct IEEE flags. But, perhaps I'm not | understanding the situation. I checked in the following change. http://hg.savannah.gnu.org/hgweb/octave/rev/bb70d16cca3b jwe From dbateman at dbateman.org Wed Nov 11 13:54:54 2009 From: dbateman at dbateman.org (David Bateman) Date: Wed, 11 Nov 2009 20:54:54 +0100 Subject: [Octave] Improving Octave for large files In-Reply-To: References: <4AF9FC78.6050608@dbateman.org> Message-ID: <4AFB168E.9020401@dbateman.org> Christian Br?dstrup wrote: > Okay, I didn't know the feature request was that old. > When the code is so untested then perhaps the best thing to do is to create > some large files and see how Octave handes them to begin with. > > The more people using 64-bit versions of Octave the faster the bugs will be worked out.. It takes a bit of effort to get a 64-bit build of Octave right though as the integer type for blas, lapack and other libraries needs to be 64-bit, though it can be done... > As far as I have been told TPIE sorts all the data from the input file and > then only access the data it needs after the sort (to save memory space). > The reason I suggested the library is because I know it is actively > developed at a university level and that the group uses it to handle very > very large sets of satelite data to do 3D terrain mapping. But if using the > library involves rewriting a lot of good code it would be foolish to use it. > > As I said I don't know TPIE but it sounds like one solution to its integration might be find a way to allow Array::data to be replaced with an external representation given by TPIE, though doing that might be quite dangerous D. -- David Bateman dbateman at dbateman.org 35 rue Gambetta +33 1 46 04 02 18 (Home) 92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob) From jwe at octave.org Wed Nov 11 14:12:39 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 11 Nov 2009 15:12:39 -0500 Subject: help directory_name In-Reply-To: References: Message-ID: <19195.6839.56755.407016@segfault.lan> On 29-Oct-2009, Marco Caliari wrote: | Dear maintainers, | | if your current working directory is, e.g., /home/caliari/analysis and you | type | | help analysis | | you should get the help text for Contents.m (if present). This does not | work in Octave 3.2.3 | | octave:1> help analysis | error: help: `analysis' not found | octave:1> pwd | ans = /home/caliari/analysis | octave:2> ls | Contents.m | | despite the function do_contents in help.m. It is not difficult to fix | this problem. But, there is another problem: if you type | | help name | | in Matlab, and name is more than once in your path, then you get the | help text for all the Contents.m therein. In Octave there is | find_dir_in_path. First of all, it does not find name in the current | working directory: | | octave:1> pwd | ans = /home/caliari/analysis | octave:2> path | | Octave's search path contains the following directories: | | . | /usr/local/share/octave/3.2.3/m/statistics/base | [CUT...] | octave:3> find_dir_in_path ('analysis') | ans = | | and, if name is twice in your path, it finds only one | | octave:1> find_dir_in_path('geometry') | ans = /usr/local/share/octave/3.2.3/m/geometry | octave:2> addpath('/home/caliari/geometry') | octave:3> find_dir_in_path('geometry') | ans = /home/caliari/geometry | | I think that the right fix for help directory_name should be based on a | fix for find_dir_in_path (which I'm not able to do). I checked in the following changeset. http://hg.savannah.gnu.org/hgweb/octave/rev/8e345f2fe4d6 jwe From lindnerben at gmx.net Wed Nov 11 14:47:47 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Wed, 11 Nov 2009 21:47:47 +0100 Subject: gnulib and automake In-Reply-To: <19193.56432.620743.620783@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AE5824C.5040106@gmx.net> <19176.28026.31789.710006@segfault.lan> <4AEB36F9.9070404@gmx.net> <19179.15601.907503.686285@segfault.lan> <4AEB46EE.8030400@gmx.net> <19179.21624.130899.537300@segfault.lan> <4AEB58DA.9070805@gmx.net> <19179.26026.448430.104714@segfault.lan> <4AEC1A96.4020108@gmx.net> <19180.23890.807202.518048@segfault.lan> <4AEC6889.3010906@gmx.net> <19180.28680.836723.376270@segfault.lan> <4AEC90A2.5000909@gmx.net> <4AEF3B5C.201@gmx.net> <19183.19051.712300.979144@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <4AF876B2.9060202@gmx.net> <19193.45734.551735.424206@segfault.lan> <4AF9B961.1070502@gmx.net> <19193.56432.620743.620783@segfault.lan> Message-ID: <4AFB22F3.7040100@gmx.net> John W. Eaton wrote: > On 10-Nov-2009, Benjamin Lindner wrote: > > | No, this is a pure msys issue. I use MiKTeX for building documentation. > | MiKTeX, as native win application, uses windows style paths. > | However, ocatve's configure procedure is run within msys, and uses thus > | msys style paths, which - consequently - miktex does not understand. > > Can you send details? I'd like to fix this so that it just works > without requiring you to patch Octave's Makefiles. Hm, switching to automake got me stuck in building the documentation. I don't have a nice solution at hand. What worked previously cannot be done in the new build system (at least not uncomplicated). Following issues: 1) /doc/conf.texi contains the lines @set top_srcdir /foo/bar @set abs_top_srcdir /foo/bar @set OCTAVEHOME /foo/bar Now miktex as native win application cannot handle such msys-style paths, so I apply the following change: diff -r 6fcc4179c178 common.mk --- a/common.mk Wed Nov 11 13:17:34 2009 -0500 +++ b/common.mk Wed Nov 11 21:27:54 2009 +0100 @@ -622,9 +622,9 @@ define do_subst_texinfo_vals echo "making $@ from $<" $(SED) < $< \ - -e "s|%abs_top_srcdir%|${abs_top_srcdir}|" \ - -e "s|%top_srcdir%|${top_srcdir}|" \ - -e "s|%OCTAVE_HOME%|${prefix}|" \ + -e "s|%abs_top_srcdir%|`cd ${abs_top_srcdir} && pwd -W`|" \ + -e "s|%top_srcdir%|`cd ${top_srcdir} && pwd -W`|" \ + -e "s|%OCTAVE_HOME%|`cd ${prefix} && pwd -W`|" \ -e "s|%OCTAVE_VERSION%|${version}|" \ -e "s|%TEXINFO_COLAMD%|${TEXINFO_COLAMD}|" \ -e "s|%TEXINFO_CHOLMOD%|${TEXINFO_CHOLMOD}|" \ diff -r 6fcc4179c178 doc/Makefile.am --- a/doc/Makefile.am Wed Nov 11 13:17:34 2009 -0500 +++ b/doc/Makefile.am Wed Nov 11 21:27:54 2009 +0100 @@ -37,9 +37,9 @@ conf.texi: conf.texi.in $(TOPDIR)/common.mk @echo "making $@ from $<" @$(SED) < $< \ - -e "s|%abs_top_srcdir%|${abs_top_srcdir}|" \ - -e "s|%top_srcdir%|${top_srcdir}|" \ - -e "s|%OCTAVE_HOME%|${prefix}|" \ + -e "s|%abs_top_srcdir%|`cd ${abs_top_srcdir} && pwd -W`|" \ + -e "s|%top_srcdir%|`cd ${top_srcdir} && pwd -W`|" \ + -e "s|%OCTAVE_HOME%|`cd ${prefix} && pwd -W`|" \ -e "s|%OCTAVE_VERSION%|${version}|" \ -e "s|%TEXINFO_COLAMD%|${TEXINFO_COLAMD}|" \ -e "s|%TEXINFO_CHOLMOD%|${TEXINFO_CHOLMOD}|" \ I noted that this code is duplicated, once in common.mk, once in doc/makefile.am. I guess that's an unnecessary duplication. Anyway, I don't substitute ${abs_top_srcdir}, rather the windows-style of this path (pwd -W prints the current working directory in win-style) Ok, this one can be solved. 2) When calling a native win application from within msys, then msys takes care of translating all msys-style paths on both the command line as well as in the environment into win-style paths. However, it does not do this for TEXINPUTS and TEXMFCNF, because these paths are literally encolsed in double quotes. (I am not sure if double quotes are legal in PATH on windows) So I apply the change diff -r 6fcc4179c178 doc/interpreter/Makefile.am --- a/doc/interpreter/Makefile.am Wed Nov 11 13:17:34 2009 -0500 +++ b/doc/interpreter/Makefile.am Wed Nov 11 21:27:54 2009 +0100 @@ -28,10 +28,10 @@ TEXINFO_TEX = ../texinfo.tex -TEXINPUTS := "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)$(TEXINPUTS)$(PATH_SEPARATOR)" +TEXINPUTS := ..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)$(TEXINPUTS)$(PATH_SEPARATOR) export TEXINPUTS -TEXMFCNF := "..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)$(PATH_SEPARATOR)$(TEXMFCNF)$(PATH_SEPARATOR)" +TEXMFCNF := ..$(PATH_SEPARATOR)$(srcdir)$(PATH_SEPARATOR)$(srcdir)/..$(PATH_SEPARATOR)$(PATH_SEPARATOR)$(TEXMFCNF)$(PATH_SEPARATOR) export TEXMFCNF dist_man1_MANS = \ Again, this can be solved. 3) Now I am stuck at the problem that miktex supports TEXINPUTS, however apparently does not put its contents *in front* of the search path. This results in miktex picking up its own texinfo.tex, which is dated 2007-06-20.13. And this version is too old (it chokes on the '@' character in the example's path) Now octave ships a newer version of texinfo.tex (because of these '@' characters in paths), however, miktex does not pick up this one. This problem was present since octave 3.0.x, and I did the following in the pre-automake time: diff -r 29e0b2f57398 doc/interpreter/Makefile.in --- a/doc/interpreter/Makefile.in Tue Sep 15 19:39:42 2009 +0200 +++ b/doc/interpreter/Makefile.in Tue Sep 15 19:39:48 2009 +0200 @@ -135,13 +135,13 @@ # targeted file name (e.g. to generate octave-a4.pdf, copy to # octave-a4.texi) and call texi2[dvi|pdf] on it. -TEXI2DVICOMMAND = TEXINPUTS="..$(sepchar)$(srcdir)$(sepchar)$(srcdir)/..$(sepchar)$(TEXINPUTS)$(sepchar)" \ - TEXMFCNF="..$(sepchar)$(srcdir)$(sepchar)$(srcdir)/..$(sepchar)$(TEXINPUTS)$(sepchar)" \ - $(TEXI2DVI) +TEXI2DVICOMMAND = TEXINPUTS="..:$(srcdir):$(srcdir)/..:$(TEXINPUTS):" \ + TEXMFCNF="..:$(srcdir):$(srcdir)/..:$(TEXINPUTS):" \ + $(TEXI2DVI) -I$(srcdir)/.. -TEXI2PDFCOMMAND = TEXINPUTS="..$(sepchar)$(srcdir)$(sepchar)$(srcdir)/..$(sepchar)$(TEXINPUTS)$(sepchar)" \ - TEXMFCNF="..$(sepchar)$(srcdir)$(sepchar)$(srcdir)/..$(sepchar)$(TEXMFCNF)$(sepchar)" \ - $(TEXI2PDF) +TEXI2PDFCOMMAND = TEXINPUTS="..:$(srcdir):$(srcdir)/..:$(TEXINPUTS):" \ + TEXMFCNF="..:$(srcdir):$(srcdir)/..:$(TEXMFCNF):" \ + $(TEXI2PDF) -I$(srcdir)/.. FORMATTED = octave.info octave.pdf octave-a4.pdf octave.info-[0-9]* (i.e. add "-I$(srcdir)/.." explicitly to texi2pdf and texi2dvi command line) I cannot do this now, since the rule to create .dvi and .pdf from .texi is not coded in the makefiles, but created automatically. I would need to have .texi.dvi: TEXINPUTS="$(am__TEXINFO_TEX_DIR)$(PATH_SEPARATOR)$$TEXINPUTS" \ MAKEINFO='$(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -I $(srcdir)' \ $(TEXI2DVI) -I$(srcdir)/.. $< in the generated makefile.in (again added "-I$(srcdir)/.." here). This then works. I could do this after calling autoconf.sh, but this is not really a satisfying solution. benjamin From tmacchant at yahoo.co.jp Wed Nov 11 18:33:13 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Thu, 12 Nov 2009 09:33:13 +0900 (JST) Subject: fltk-config for windows gives -mwindows flag (was octave-3.3.50 built by mingw-gcc-4.4.0 cannot be executed.) In-Reply-To: <19194.63957.741562.585823@segfault.lan> Message-ID: <20091112003313.56694.qmail@web3809.mail.bbt.yahoo.co.jp> Hello --- "John W. Eaton" wrote: > On 11-Oct-2009, Michael Goffioul wrote: > > | On Sun, Oct 11, 2009 at 4:12 PM, John W. Eaton wrote: > | > | diff -r a65c135a1deb configure.in > | > | --- a/configure.in   Mon Oct 05 19:22:13 2009 +0200 > | > | +++ b/configure.in   Mon Oct 05 20:30:33 2009 +0200 > | > | @@ -847,6 +847,11 @@ > | > |   FLTK_CFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --cflags`" > | > |   FLTK_LDFLAGS="`$FLTK_CONFIG $fltkconf_args --use-gl --ldflags`" > | > | > | > | + case "$canonical_host_type" in > | > | + *-*-mingw*) > | > | +  FLTK_LDFLAGS="`echo $FLTK_LDFLAGS | sed -e 's+-mwindows++g'`" > | > | + esac > | > | + > | > |   AC_MSG_CHECKING(for OpenGL support in FLTK) > | > |   cat > conftest.cc < | > |   #include > | > > | > Only *-*-mingw*? Would this also be a problem for *-*-msdosmsvc? > | > | No. The -mwindows flag is only GCC specific. > > I checked in the following change. > > http://hg.savannah.gnu.org/hgweb/octave/rev/f5126ea721e2 > > Is this OK? Or should we be more careful and try to only match > -mwindows if it appears as a word by itself? Or is this change even > needed now? > I think it is OK. By the change, people who would like to build octave by themselves on mingw need not tweak fltk-config. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From highegg at gmail.com Thu Nov 12 09:19:03 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Thu, 12 Nov 2009 16:19:03 +0100 Subject: unary mapper system redesigned + a few questions Message-ID: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> hi all, the following (rather large) changeset redesigns the system for unary mapper functions. http://hg.savannah.gnu.org/hgweb/octave/rev/f80c566bc751 Rationale: Until now, there existed a single virtual octave_base_value method for each mapper. Now, there is a single map (unary_mapper_t) method that takes an enum parameter identifying the mapper. The new style has some advantages: 1. It becomes far easier to implement a "handle some, convert & forward others" approach. 2. When adding a new mapper, less classes need to be touched. Adding support for scalars and dense arrays mostly suffices; the fallback conversions will handle the rest. 3. Adding a new mapper won't alter the VMT, hence the ABI is not broken. 4. 40 virtual methods are replaced by one, saving 39 VMT entries :) (probably not a real issue though) 5. Less code and less macros. I think the only disadvantage is that one now needs to write value.map (umap_abs) rather than value.abs (). If anyone thinks that would be a good idea, the old mappers can be put back to octave_value for compatibility. Right now they're gone. I also altered somewhat the way mapping functions on arrays is handled, but that's even more technical and probably not yet final... If you compile, you'll notice 37 failures. Of those, 30 are caused by the fact that isalpha, tolower et al. now don't work for numeric inputs. Matlab apparently only has lower/upper and only mentions characters. Giving an error on, say, toupper (1+1i) makes sense to me, so unless someone disagrees I'll alter the tests instead. The remaining 7 failures are more subtle, caused by things like: octave:1> a = -1i*sqrt(-1/(6.4187*6.4187)); octave:2> assert (erf(a), erf(real(a))); error: erf: not defined for complex scalar error: evaluating argument list element number 1 For some reason, Octave's complex->real autoconversion doesn't take place on a: octave:2> isreal (a) ans = 0 I checked the sources and it seems this behaviour is intended - positive imaginary zeros are narrowed, negative zeros aren't. that gives rise to some surprising results: octave:3> isreal (i*i) ans = 1 octave:4> isreal (-i*i) ans = 0 why by all heavens does Octave do this? Can anyone explain? Apparently it was done on purpose, but I don't understand it. And I'd like to, so that I can argue about it :) best regards -- 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/20091112/580c4843/attachment.html From godfrey at isl.stanford.edu Thu Nov 12 09:56:59 2009 From: godfrey at isl.stanford.edu (Michael D. Godfrey) Date: Thu, 12 Nov 2009 16:56:59 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> Message-ID: <4AFC304B.6090402@isl.stanford.edu> > octave:3> isreal (i*i) > ans = 1 > octave:4> isreal (-i*i) > ans = 0 > > why by all heavens does Octave do this? Right now I cannot think of a reason. And, Matlab says: >> isreal(i*i) ans = 1 >> isreal(-i*i) ans = 1 >> That's an extra 0.5 point in favor of a change. Michael From jwe at octave.org Thu Nov 12 10:37:24 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 12 Nov 2009 11:37:24 -0500 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> Message-ID: <19196.14788.828621.761029@segfault.lan> On 12-Nov-2009, Jaroslav Hajek wrote: | the following (rather large) changeset redesigns the system for unary mapper | functions. | http://hg.savannah.gnu.org/hgweb/octave/rev/f80c566bc751 I think it would be preferable if you posted a diff for discussion before comitting large changes that completely alter the structure of the way things are done. In most cases, we will probably agree that the change is good and can be applied, but I think it would be better to have some discussion before comitting. | Rationale: | Until now, there existed a single virtual octave_base_value method for each | mapper. The current method of doing things has only been in place since mid February of 2008. There was a discussion about it at the time, before the change was made, here: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2008-February/006013.html The initial changeset is here: http://hg.savannah.gnu.org/hgweb/octave/rev/8c32f95c2639 | Now, there is a single map (unary_mapper_t) method that takes an | enum parameter identifying the mapper. The new style has some advantages: | 1. It becomes far easier to implement a "handle some, convert & forward | others" approach. Can you give a specific example of this? | 2. When adding a new mapper, less classes need to be touched. Adding support | for scalars and dense arrays mostly suffices; the fallback conversions will | handle the rest. Where is the conversion happening before, and now with your change? With the previous code, could conversion have been handled by the octave_base_value mapper functions? | 3. Adding a new mapper won't alter the VMT, hence the ABI is not | broken. How often are new mapper functions added? Do you have plans to add some? | 4. 40 virtual methods are replaced by one, saving 39 VMT entries :) | (probably not a real issue though) It seems to me that you have traded a set of virtual functions for a collection of large switch statements. Usually, I would want to go in the other direction and replace large switch statements with virtual functions, but I might agree with the change if there are some good reasons. | I think the only disadvantage is that one now needs to write value.map | (umap_abs) rather than value.abs (). If anyone thinks that would be a good | idea, the old mappers can be put back to octave_value for compatibility. It might be more natural to write value.abs() if you are converting some script to C++. Maybe it would also be good to hide the enum details and leave the interface at the octave_value level alone? | I also altered somewhat the way mapping functions on arrays is handled, but | that's even more technical and probably not yet final... What changes are you referring to here? | Of those, 30 are caused by the fact that isalpha, tolower et al. now don't | work for numeric inputs. Matlab apparently only has lower/upper and only | mentions characters. Giving an error on, say, toupper (1+1i) makes sense to | me, so unless someone disagrees I'll alter the tests instead. I wouldn't be surprised if there is some old Matlab code out there that relies on numeric (probably not complex) values in the range of ascii characters behaving like characters. | I checked the sources and it seems this behaviour is intended - positive | imaginary zeros are narrowed, negative zeros aren't. Yes, I think that is intentional, so that you get different results for things like complex (-0, 1)/inf complex (0, 1)/inf jwe From highegg at gmail.com Thu Nov 12 15:03:12 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Thu, 12 Nov 2009 22:03:12 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: <19196.14788.828621.761029@segfault.lan> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19196.14788.828621.761029@segfault.lan> Message-ID: <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> On Thu, Nov 12, 2009 at 5:37 PM, John W. Eaton wrote: > On 12-Nov-2009, Jaroslav Hajek wrote: > > | the following (rather large) changeset redesigns the system for unary > mapper > | functions. > | http://hg.savannah.gnu.org/hgweb/octave/rev/f80c566bc751 > > I think it would be preferable if you posted a diff for discussion > before comitting large changes that completely alter the structure of > the way things are done. In most cases, we will probably agree that > the change is good and can be applied, but I think it would be better > to have some discussion before comitting. > > That's the old discussion about how much "working" the development repo is. I prefer using the repo rather than sharing patches via mail. I remind that we still have the secondary "stable" repo set up on Savannah. > | Rationale: > | Until now, there existed a single virtual octave_base_value method for > each > | mapper. > > The current method of doing things has only been in place since mid > February of 2008. There was a discussion about it at the time, before > the change was made, here: > > > https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2008-February/006013.html > > Thanks, I'll look at that. > The initial changeset is here: > > http://hg.savannah.gnu.org/hgweb/octave/rev/8c32f95c2639 > > | Now, there is a single map (unary_mapper_t) method that takes an > | enum parameter identifying the mapper. The new style has some advantages: > > | 1. It becomes far easier to implement a "handle some, convert & forward > | others" approach. > > Can you give a specific example of this? > For instance, octave_range now only needs octave_value map (unary_mapper_t umap) const { octave_matrix m (matrix_value ()); return m.map (umap); } previously, there were 40 separate forwards for each method. Similarly for octave_perm_matrix, diag matrices etc. > > | 2. When adding a new mapper, less classes need to be touched. Adding > support > | for scalars and dense arrays mostly suffices; the fallback conversions > will > | handle the rest. > > Where is the conversion happening before, and now with your change? > Previously, each mapper method needed to be separately overriden for each class it was supposed to work on, so the default conversions were injected into each method, typically via a macro. Now it's only needed once as a the default: case. With the previous code, could conversion have been handled by the > octave_base_value mapper functions? > I didn't see a good way. I thought about using somehow the default numeric conversions for operators, but that didn't seem to quite work. > > | 3. Adding a new mapper won't alter the VMT, hence the ABI is not > | broken. > > How often are new mapper functions added? Do you have plans to add some? > > Yes. I also added some in the past (log2, roundb) and I remember that it was error-prone. | 4. 40 virtual methods are replaced by one, saving 39 VMT entries :) > | (probably not a real issue though) > > It seems to me that you have traded a set of virtual functions for a > collection of large switch statements. Usually, I would want to go in > the other direction and replace large switch statements with virtual > functions, but I might agree with the change if there are some good > reasons. > > I traded 40 similar virtual methods for one virtual method with a parameter. That idea is too general; here each switch statements replaced 40 methods, not one call. > | I think the only disadvantage is that one now needs to write value.map > | (umap_abs) rather than value.abs (). If anyone thinks that would be a > good > | idea, the old mappers can be put back to octave_value for compatibility. > > It might be more natural to write value.abs() if you are converting > some script to C++. Maybe it would also be good to hide the enum > details and leave the interface at the octave_value level alone? > > OK, good suggestion. Maybe the enum can be in octave_base_value and protected; anyway, only its descendants will probably need it. > > | I also altered somewhat the way mapping functions on arrays is handled, > but > | that's even more technical and probably not yet final... > > What changes are you referring to here? > Array::map was repeatedly overriden in subclasses, hiding the original method (template method hiding) and disabling inlining possibilities. I removed most of these overrides and instead I'm accessing the methods directly, resulting in less boilerplate code. > > | Of those, 30 are caused by the fact that isalpha, tolower et al. now > don't > | work for numeric inputs. Matlab apparently only has lower/upper and only > | mentions characters. Giving an error on, say, toupper (1+1i) makes sense > to > | me, so unless someone disagrees I'll alter the tests instead. > > I wouldn't be surprised if there is some old Matlab code out there > that relies on numeric (probably not complex) values in the range of > ascii characters behaving like characters. > OK. So let's allow only real numeric args? > > | I checked the sources and it seems this behaviour is intended - positive > | imaginary zeros are narrowed, negative zeros aren't. > > Yes, I think that is intentional, so that you get different results > for things like > > complex (-0, 1)/inf > complex (0, 1)/inf > Sorry, but what is that good for? I still don't get the point. I don't think Matlab supports this, does it? So what is the motivation? Why does Octave distinguish signed and unsigned zeros? -- 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/20091112/31e17b16/attachment.html From jwe at octave.org Thu Nov 12 15:20:42 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 12 Nov 2009 16:20:42 -0500 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19196.14788.828621.761029@segfault.lan> <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> Message-ID: <19196.31786.833114.405812@segfault.lan> On 12-Nov-2009, Jaroslav Hajek wrote: | Sorry, but what is that good for? I still don't get the point. I don't think | Matlab supports this, does it? So what is the motivation? Why does Octave | distinguish signed and unsigned zeros? IEEE 754? We've discussed this before: http://old.nabble.com/Negative-zeros--to844605.html#a845854 jwe From jwe at octave.org Thu Nov 12 15:25:45 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 12 Nov 2009 16:25:45 -0500 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19196.14788.828621.761029@segfault.lan> <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> Message-ID: <19196.32089.528082.477053@segfault.lan> On 12-Nov-2009, Jaroslav Hajek wrote: | That's the old discussion about how much "working" the development repo is. | I prefer using the repo rather than sharing patches via mail. It's also about discussing potential changes with others before putting them in the public archive. If the changes are large or disruptive in some way, I think it would be good to give others a chance to review and discuss them first. I don't think it is necessary to discuss everything first. But structural changes, or major additions, or changes that result in lots of tests suddenly failing should probably get a public viewing first, before committing. jwe From michael.goffioul at gmail.com Thu Nov 12 15:46:39 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Thu, 12 Nov 2009 21:46:39 +0000 Subject: gnulib and automake In-Reply-To: <19193.56432.620743.620783@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <4AF876B2.9060202@gmx.net> <19193.45734.551735.424206@segfault.lan> <4AF9B961.1070502@gmx.net> <19193.56432.620743.620783@segfault.lan> Message-ID: <128f38bd0911121346m3aad0b85q5ebc11420945b0a2@mail.gmail.com> Hi, I just tried to recompile octave with MSVC using the new automake/libtool framework and the first thing I came across is the drop of mkf77def script in libcruft. Any chance to get this functionality back into the build system? Michael. From jwe at octave.org Thu Nov 12 15:55:38 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 12 Nov 2009 16:55:38 -0500 Subject: gnulib and automake In-Reply-To: <128f38bd0911121346m3aad0b85q5ebc11420945b0a2@mail.gmail.com> References: <19121.21838.419944.184758@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <4AF876B2.9060202@gmx.net> <19193.45734.551735.424206@segfault.lan> <4AF9B961.1070502@gmx.net> <19193.56432.620743.620783@segfault.lan> <128f38bd0911121346m3aad0b85q5ebc11420945b0a2@mail.gmail.com> Message-ID: <19196.33882.797708.699014@segfault.lan> On 12-Nov-2009, Michael Goffioul wrote: | I just tried to recompile octave with MSVC using the new automake/libtool | framework and the first thing I came across is the drop of mkf77def script | in libcruft. Any chance to get this functionality back into the build system? Yes. The file libcruft/mkf22def.in still exists, so I guess we just need a few rules to be added into the libcruft/Makefile.am file. jwe From jwe at octave.org Thu Nov 12 17:28:00 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 12 Nov 2009 18:28:00 -0500 Subject: gnulib and automake In-Reply-To: <19196.33882.797708.699014@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AF478BD.1060507@gmx.net> <19188.32449.963957.318005@segfault.lan> <4AF4808B.7010703@gmx.net> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <4AF876B2.9060202@gmx.net> <19193.45734.551735.424206@segfault.lan> <4AF9B961.1070502@gmx.net> <19193.56432.620743.620783@segfault.lan> <128f38bd0911121346m3aad0b85q5ebc11420945b0a2@mail.gmail.com> <19196.33882.797708.699014@segfault.lan> Message-ID: <19196.39424.88855.594114@segfault.lan> On 12-Nov-2009, John W. Eaton wrote: | On 12-Nov-2009, Michael Goffioul wrote: | | | I just tried to recompile octave with MSVC using the new automake/libtool | | framework and the first thing I came across is the drop of mkf77def script | | in libcruft. Any chance to get this functionality back into the build system? | | Yes. | | The file libcruft/mkf22def.in still exists, so I guess we just need a | few rules to be added into the libcruft/Makefile.am file. Do the following changes work for you? If so, I'll commit them. 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/20091112/66680aa6/attachment-0001.ksh From highegg at gmail.com Fri Nov 13 00:27:51 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 13 Nov 2009 07:27:51 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: <19196.31786.833114.405812@segfault.lan> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19196.14788.828621.761029@segfault.lan> <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> <19196.31786.833114.405812@segfault.lan> Message-ID: <69d8d540911122227s5d80ecbbkb3b57eae7b9e9aa9@mail.gmail.com> On Thu, Nov 12, 2009 at 10:20 PM, John W. Eaton wrote: > On 12-Nov-2009, Jaroslav Hajek wrote: > > | Sorry, but what is that good for? I still don't get the point. I don't > think > | Matlab supports this, does it? So what is the motivation? Why does Octave > | distinguish signed and unsigned zeros? > > IEEE 754? We've discussed this before: > > http://old.nabble.com/Negative-zeros--to844605.html#a845854 > > jwe > Thanks for the pointer. This thread mainly discusses the existence of signed zero which I'm OK with. It's also fine that Octave prints negative zeros. But why are complex numbers with negative zero parts excluded from automatic narrowing? I found this message: http://old.nabble.com/Negative-zeros--to844605.html#a845854 "I don't see a quick fix for these problems, but the following patch does allow you to write 0*(-i) to produce (0, -0). jwe " So it seems you made this change so that 0*(-i) produces a 0 - 0i. I think it's a good time to rethink this decision. First, you probably overlooked the fact that 0 - 0i is constructible with complex (0, -0) - because complex() is the (only) function that bypasses the narrowing. So the primary motivation is not strong - these numbers *would be* constructible, albeit less conveniently. On the other hand, there are disadvantages: 1. It's not Matlab-compatible. Matlab seems to discard all zero imaginary parts. 2. isreal produces confusing results (isreal (i*i) vs. isreal (-i*i)). 3. When numbers like x-0i are excluded from simplifying, you want real-only mappers (erf, gamma etc) to still work on them. Currently that requires each real-only mapper to have a complex wrapper counterpart. That's cumbersome and easy to forget when new mappers are added. 4. a' * a is not always real if a is a complex scalar. On the contrary, if a is a complex vector, the result *is* always real, as computed by BLAS. Should we try to fix BLAS? The advantages, for recap: 1. Numbers with negative zero imaginary parts, should they be needed for consistency, can be constructed like x + 0*(-i). However, even without the discussed behaviour, these numbers could be constructed using complex (), so this is pretty weak. 2. more? Unless there are more advantages that I just don't see, it seems to me that the losses far outweigh the benefits. So I vote for a change. The overall impact is probably minor and won't affect most existing computations, because the issues being dealt with are quite subtle anyway. comments? -- 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/20091113/ee53d3dd/attachment.html From highegg at gmail.com Fri Nov 13 00:41:32 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 13 Nov 2009 07:41:32 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: <19196.32089.528082.477053@segfault.lan> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19196.14788.828621.761029@segfault.lan> <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> <19196.32089.528082.477053@segfault.lan> Message-ID: <69d8d540911122241k3ddf5919w8289738e0564d5b8@mail.gmail.com> On Thu, Nov 12, 2009 at 10:25 PM, John W. Eaton wrote: > On 12-Nov-2009, Jaroslav Hajek wrote: > > | That's the old discussion about how much "working" the development repo > is. > | I prefer using the repo rather than sharing patches via mail. > > It's also about discussing potential changes with others before > putting them in the public archive. If the changes are large or > disruptive in some way, I think it would be good to give others a > chance to review and discuss them first. > > I don't think it is necessary to discuss everything first. But > structural changes, or major additions, or changes that result in lots > of tests suddenly failing should probably get a public viewing first, > before committing. > > jwe > OK, I'm sorry. I was almost sure I proposed and discussed this previously, but I can't find anything, so apparently I was wrong. Once again I forgot I have my own repo for such stuff - I'm so used to commit patches after finishing. Maybe I'm contributing too often :) sorry again & best regards -- 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/20091113/af29f021/attachment.html From godfrey at isl.stanford.edu Fri Nov 13 01:37:55 2009 From: godfrey at isl.stanford.edu (Michael D. Godfrey) Date: Fri, 13 Nov 2009 08:37:55 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911122241k3ddf5919w8289738e0564d5b8@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19196.14788.828621.761029@segfault.lan> <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> <19196.32089.528082.477053@segfault.lan> <69d8d540911122241k3ddf5919w8289738e0564d5b8@mail.gmail.com> Message-ID: <4AFD0CD3.5040604@isl.stanford.edu> On 11/13/09 7:41 AM, Jaroslav Hajek wrote: > Maybe I'm contributing too often :) You must be kidding. Think for a minute where Octive would be without your contributions. Even when doing lots of excellent work it is useful to remember the various customers. :-) In any case, keep up the good work. Michael From michael.goffioul at gmail.com Fri Nov 13 04:50:16 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Fri, 13 Nov 2009 10:50:16 +0000 Subject: gnulib and automake In-Reply-To: <19196.39424.88855.594114@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <4AF876B2.9060202@gmx.net> <19193.45734.551735.424206@segfault.lan> <4AF9B961.1070502@gmx.net> <19193.56432.620743.620783@segfault.lan> <128f38bd0911121346m3aad0b85q5ebc11420945b0a2@mail.gmail.com> <19196.33882.797708.699014@segfault.lan> <19196.39424.88855.594114@segfault.lan> Message-ID: <128f38bd0911130250s64b3d16blbe75df293ca1ef7@mail.gmail.com> I'll test that asap. It should rebuild cruft.def properly. But I think I'll still miss the addition of XTRA_CRUFT_SH_LDFLAGS to the link flags. Michael. On Thu, Nov 12, 2009 at 11:28 PM, John W. Eaton wrote: > On 12-Nov-2009, John W. Eaton wrote: > > | On 12-Nov-2009, Michael Goffioul wrote: > | > | | I just tried to recompile octave with MSVC using the new automake/libtool > | | framework and the first thing I came across is the drop of mkf77def script > | | in libcruft. Any chance to get this functionality back into the build system? > | > | Yes. > | > | The file libcruft/mkf22def.in still exists, so I guess we just need a > | few rules to be added into the libcruft/Makefile.am file. > > Do the following changes work for you? ?If so, I'll commit them. > > Thanks, > > jwe > > > # HG changeset patch > # User John W. Eaton > # Date 1258068399 18000 > # Node ID dd9e9bf3a9aa293dfe8477ebe55bbb20c66c25d2 > # Parent ?4ea4eef3d8689422957d0959fab245898c0845de > restore rules to create libcruft/cruft.def > > diff --git a/ChangeLog b/ChangeLog > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,7 @@ > +2009-11-12 ?John W. Eaton ? > + > + ? ? ? * configure.ac (AC_CONFIG_FILES): Also generate libcruft/mkf77def. > + > ?2009-11-11 ?John W. Eaton ? > > ? ? ? ?* acinclude.m4 (OCTAVE_IEEE754_DATA_FORMAT): Fail if IEEE 754 > diff --git a/configure.ac b/configure.ac > --- a/configure.ac > +++ b/configure.ac > @@ -2165,6 +2165,7 @@ > ? gnulib/po/Makefile.in > ? gnulib/tests/Makefile > ? libcruft/Makefile > + ?libcruft/mkf77def > ? liboctave/Makefile > ? scripts/Makefile > ? src/Makefile > diff --git a/libcruft/ChangeLog b/libcruft/ChangeLog > --- a/libcruft/ChangeLog > +++ b/libcruft/ChangeLog > @@ -1,3 +1,9 @@ > +2009-11-12 ?John W. Eaton ? > + > + ? ? ? * Makefile.am: Restore rules for building cruft.def. > + ? ? ? * mkf77def.in: Use @VAR@ instead of %VAR% substitutions. > + ? ? ? Process list of files instead of working as a filter. > + > ?2009-11-10 ?John W. Eaton ? > > ? ? ? ?* blas, lapack: Remove directories and all files. > diff --git a/libcruft/Makefile.am b/libcruft/Makefile.am > --- a/libcruft/Makefile.am > +++ b/libcruft/Makefile.am > @@ -52,3 +52,10 @@ > ?include slatec-err/module.mk > ?include slatec-fn/module.mk > ?include villad/module.mk > + > +cruft.def: $(libcruft_la_SOURCES) $(TOPDIR)/libcruft/mkf77def > + ? ? ? @chmod a+rx mkf77def > + ? ? ? @./mkf77def < $(addprefix $(srcdir)/, $(libcruft_la_SOURCES)) > $@-t > + ? ? ? @mv $@-t $@ > + > +libcruft.la: cruft.def > diff --git a/libcruft/mkf77def.in b/libcruft/mkf77def.in > old mode 100644 > new mode 100755 > --- a/libcruft/mkf77def.in > +++ b/libcruft/mkf77def.in > @@ -21,9 +21,9 @@ > ?SED=${SED:-'sed'} > ?AWK=${AWK:-'awk'} > > -F77_TOLOWER=%F77_APPEND_UNDERSCORE% > -F77_APPEND_UNDERSCORE=%F77_APPEND_UNDERSCORE% > -F77_APPEND_EXTRA_UNDERSCORE=%F77_APPEND_EXTRA_UNDERSCORE% > +F77_TOLOWER="@F77_APPEND_UNDERSCORE@" > +F77_APPEND_UNDERSCORE="@F77_APPEND_UNDERSCORE@" > +F77_APPEND_EXTRA_UNDERSCORE="@F77_APPEND_EXTRA_UNDERSCORE@" > > ?if $F77_TOLOWER; then > ? case_cmd="tolower"; > @@ -43,4 +43,8 @@ > ? awkcmd="$AWK '{ printf (\"%s%s\n\", tolower (\$0), \"$uscore\"); }'" > ?fi > > -$SED -n -e 'y/ABCDEFGHIJLKMNOPQRSTUVWXYZ/abcdefghijlkmnopqrstuvwxyz/; s/^\( ? ? ?\| ? ?\)[ ? ? ]*\(.*function\|subroutine\|entry\)[ ? ?]*\([^ ?(]*\).*$/\3/p' | eval $awkcmd > +echo EXPORTS > +for arg > +do > + ?$SED -n -e 'y/ABCDEFGHIJLKMNOPQRSTUVWXYZ/abcdefghijlkmnopqrstuvwxyz/; s/^\( ? ? ?\| ?\)[ ? ? ]*\(.*function\|subroutine\|entry\)[ ? ?]*\([^ ?(]*\).*$/\3/p' "$arg" | eval $awkcmd > +done > > From godfrey at isl.stanford.edu Fri Nov 13 05:07:29 2009 From: godfrey at isl.stanford.edu (Michael Godfrey) Date: Fri, 13 Nov 2009 12:07:29 +0100 Subject: openGL printing Message-ID: <4AFD3DF1.9030603@isl.stanford.edu> A very minor adjustment of xlabel and ylabel is needed. The following example should show the problem: octave:1> plot([1:200]) octave:2> xlabel('this is xlabel'); octave:3> ylabel('this is ylabel'); octave:4> title('this is the title'); octave:5> print "test01.ps" ========================= The plot looks just fine with the x and y labels positioned correctly. However, the PS file has the x and y labels written too close to the actual x and y axes so that the text overlaps the numeric scale values. I have tried a few other plots and this is the only problem that has come up. Michael From highegg at gmail.com Fri Nov 13 05:08:59 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 13 Nov 2009 12:08:59 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: <19196.14788.828621.761029@segfault.lan> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19196.14788.828621.761029@segfault.lan> Message-ID: <69d8d540911130308i56abbca4j29d58db71841bc47@mail.gmail.com> On Thu, Nov 12, 2009 at 5:37 PM, John W. Eaton wrote: > On 12-Nov-2009, Jaroslav Hajek wrote: > > | the following (rather large) changeset redesigns the system for unary > mapper > | functions. > | http://hg.savannah.gnu.org/hgweb/octave/rev/f80c566bc751 > > I think it would be preferable if you posted a diff for discussion > before comitting large changes that completely alter the structure of > the way things are done. In most cases, we will probably agree that > the change is good and can be applied, but I think it would be better > to have some discussion before comitting. > > | Rationale: > | Until now, there existed a single virtual octave_base_value method for > each > | mapper. > > The current method of doing things has only been in place since mid > February of 2008. There was a discussion about it at the time, before > the change was made, here: > > > https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2008-February/006013.html > > The initial changeset is here: > > http://hg.savannah.gnu.org/hgweb/octave/rev/8c32f95c2639 > > | Now, there is a single map (unary_mapper_t) method that takes an > | enum parameter identifying the mapper. The new style has some advantages: > > | 1. It becomes far easier to implement a "handle some, convert & forward > | others" approach. > > Can you give a specific example of this? > > | 2. When adding a new mapper, less classes need to be touched. Adding > support > | for scalars and dense arrays mostly suffices; the fallback conversions > will > | handle the rest. > > Where is the conversion happening before, and now with your change? > With the previous code, could conversion have been handled by the > octave_base_value mapper functions? > > | 3. Adding a new mapper won't alter the VMT, hence the ABI is not > | broken. > > How often are new mapper functions added? Do you have plans to add some? > > | 4. 40 virtual methods are replaced by one, saving 39 VMT entries :) > | (probably not a real issue though) > > It seems to me that you have traded a set of virtual functions for a > collection of large switch statements. Usually, I would want to go in > the other direction and replace large switch statements with virtual > functions, but I might agree with the change if there are some good > reasons. > > | I think the only disadvantage is that one now needs to write value.map > | (umap_abs) rather than value.abs (). If anyone thinks that would be a > good > | idea, the old mappers can be put back to octave_value for compatibility. > > It might be more natural to write value.abs() if you are converting > some script to C++. Maybe it would also be good to hide the enum > details and leave the interface at the octave_value level alone? > > | I also altered somewhat the way mapping functions on arrays is handled, > but > | that's even more technical and probably not yet final... > > What changes are you referring to here? > > | Of those, 30 are caused by the fact that isalpha, tolower et al. now > don't > | work for numeric inputs. Matlab apparently only has lower/upper and only > | mentions characters. Giving an error on, say, toupper (1+1i) makes sense > to > | me, so unless someone disagrees I'll alter the tests instead. > > I wouldn't be surprised if there is some old Matlab code out there > that relies on numeric (probably not complex) values in the range of > ascii characters behaving like characters. > > Update: http://hg.savannah.gnu.org/hgweb/octave/rev/8fa32b527d9a Summary: unary_mapper_t is moved to octave_base_value. The octave_value::NAME functions are back for convenient use, and the induced changes are reverted. isalnum, toupper et al now work on numeric matrices, forcing an implicit conversion. I'm not sure whether isalnum (68*speye (5)) should produce a dense result, but that is what the tests contained. I think a sparse result is more sound and actually it requires an extra check to prevent it (because the sparse mapper fallback is: convert to dense -> apply mapper -> sparsify if possible). Unless anyone disagrees, I'll remove this extra quirk and update the tests. What remains are the 7 failures related to narrowing of complex data; I'll address those after the dispute is resolved. regards -- 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/20091113/d289bbc0/attachment-0001.html From highegg at gmail.com Fri Nov 13 05:46:28 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 13 Nov 2009 12:46:28 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911122227s5d80ecbbkb3b57eae7b9e9aa9@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19196.14788.828621.761029@segfault.lan> <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> <19196.31786.833114.405812@segfault.lan> <69d8d540911122227s5d80ecbbkb3b57eae7b9e9aa9@mail.gmail.com> Message-ID: <69d8d540911130346y68d8c15eqff0e870b12c9cdfc@mail.gmail.com> On Fri, Nov 13, 2009 at 7:27 AM, Jaroslav Hajek wrote: > > > On Thu, Nov 12, 2009 at 10:20 PM, John W. Eaton wrote: > >> On 12-Nov-2009, Jaroslav Hajek wrote: >> >> | Sorry, but what is that good for? I still don't get the point. I don't >> think >> | Matlab supports this, does it? So what is the motivation? Why does >> Octave >> | distinguish signed and unsigned zeros? >> >> IEEE 754? We've discussed this before: >> >> http://old.nabble.com/Negative-zeros--to844605.html#a845854 >> >> jwe >> > > Thanks for the pointer. This thread mainly discusses the existence of > signed zero which I'm OK with. It's also fine that Octave prints negative > zeros. But why are complex numbers with negative zero parts excluded from > automatic narrowing? > > I found this message: > > http://old.nabble.com/Negative-zeros--to844605.html#a845854 > > "I don't see a quick fix for these problems, but the following patch > does allow you to write > > 0*(-i) > > to produce (0, -0). > > jwe > " > > So it seems you made this change so that 0*(-i) produces a 0 - 0i. I think > it's a good time to rethink this decision. > First, you probably overlooked the fact that 0 - 0i is constructible with > complex (0, -0) - because complex() is the (only) function that bypasses the > narrowing. So the primary motivation is not strong - these numbers *would > be* constructible, albeit less conveniently. > > On the other hand, there are disadvantages: > > 1. It's not Matlab-compatible. Matlab seems to discard all zero imaginary > parts. > 2. isreal produces confusing results (isreal (i*i) vs. isreal (-i*i)). > 3. When numbers like x-0i are excluded from simplifying, you want real-only > mappers (erf, gamma etc) to still work on them. Currently that requires each > real-only mapper to have a complex wrapper counterpart. That's cumbersome > and easy to forget when new mappers are added. > 4. a' * a is not always real if a is a complex scalar. On the contrary, if > a is a complex vector, the result *is* always real, as computed by BLAS. > Should we try to fix BLAS? > > The advantages, for recap: > > 1. Numbers with negative zero imaginary parts, should they be needed for > consistency, can be constructed like x + 0*(-i). However, even without the > discussed behaviour, these numbers could be constructed using complex (), so > this is pretty weak. > 2. more? > > Unless there are more advantages that I just don't see, it seems to me that > the losses far outweigh the benefits. So I vote for a change. The overall > impact is probably minor and won't affect most existing computations, > because the issues being dealt with are quite subtle anyway. > > comments? > > Attached is a proposed changeset. This eliminates the remaining test failures and gives: octave:1> i*i ans = -1 octave:2> -i*i ans = 1 octave:3> 0*(-i) ans = -0 octave:4> complex (0, -0) ans = 0 - 0i octave:5> a = complex (1, -0); a'*a ans = 1 regards -- 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/20091113/2e194e71/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: complex.diff Type: text/x-diff Size: 8502 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091113/2e194e71/attachment.bin From jwe at octave.org Fri Nov 13 11:45:49 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 13 Nov 2009 12:45:49 -0500 Subject: gnulib and automake In-Reply-To: <128f38bd0911130250s64b3d16blbe75df293ca1ef7@mail.gmail.com> References: <19121.21838.419944.184758@segfault.lan> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <4AF876B2.9060202@gmx.net> <19193.45734.551735.424206@segfault.lan> <4AF9B961.1070502@gmx.net> <19193.56432.620743.620783@segfault.lan> <128f38bd0911121346m3aad0b85q5ebc11420945b0a2@mail.gmail.com> <19196.33882.797708.699014@segfault.lan> <19196.39424.88855.594114@segfault.lan> <128f38bd0911130250s64b3d16blbe75df293ca1ef7@mail.gmail.com> Message-ID: <19197.39757.734427.585503@segfault.lan> On 13-Nov-2009, Michael Goffioul wrote: | I'll test that asap. It should rebuild cruft.def properly. But I think | I'll still miss the addition of XTRA_CRUFT_SH_LDFLAGS to the link flags. Does this additional change fix that problem for you? diff --git a/libcruft/Makefile.am b/libcruft/Makefile.am --- a/libcruft/Makefile.am +++ b/libcruft/Makefile.am @@ -29,7 +29,8 @@ libcruft_la_SOURCES = -libcruft_la_LDFLAGS = -release $(version) $(NO_UNDEFINED_LDFLAG) +libcruft_la_LDFLAGS = \ + -release $(version) $(NO_UNDEFINED_LDFLAG) @XTRA_CRUFT_SH_LDFLAGS@ libcruft_la_LIBADD = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) jwe From jordigh at gmail.com Fri Nov 13 12:32:44 2009 From: jordigh at gmail.com (=?UTF-8?Q?Jordi_Guti=C3=A9rrez_Hermoso?=) Date: Fri, 13 Nov 2009 12:32:44 -0600 Subject: Spanish Translation In-Reply-To: <4AFA9B1E.7070601@googlemail.com> References: <13508.190.24.181.227.1257918482.squirrel@mail.udistrital.edu.co> <420fb9e60911110031i4bc7b405w6f486b93fa2515f6@mail.gmail.com> <4AFA7901.3020203@dbateman.org> <4AFA9B1E.7070601@googlemail.com> Message-ID: <9543b3a40911131032s10f117ffyae76c5b2e2f6ffcd@mail.gmail.com> 2009/11/11 Javier Enciso : > I have spent a couple of months in the translation of the help strings for > Octave functions. So far it counts for 1120 translated functions (only 290 > help strings are left - according to my last record). We should coordinate translation of technical terms. Perhaps in the Octave wiki? There are plenty of technical terms which I'm sure are still not uniform in Spanish, and I personally hope we can avoid calques. For example, sparse matrices should be "matrices ralas", not "matrices esparcidas". From jwe at octave.org Fri Nov 13 12:33:36 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 13 Nov 2009 13:33:36 -0500 Subject: gnulib and automake In-Reply-To: <19197.39757.734427.585503@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <4AF49498.6020603@gmx.net> <19189.148.970534.7634@segfault.lan> <4AF876B2.9060202@gmx.net> <19193.45734.551735.424206@segfault.lan> <4AF9B961.1070502@gmx.net> <19193.56432.620743.620783@segfault.lan> <128f38bd0911121346m3aad0b85q5ebc11420945b0a2@mail.gmail.com> <19196.33882.797708.699014@segfault.lan> <19196.39424.88855.594114@segfault.lan> <128f38bd0911130250s64b3d16blbe75df293ca1ef7@mail.gmail.com> <19197.39757.734427.585503@segfault.lan> Message-ID: <19197.42624.793244.338602@segfault.lan> On 13-Nov-2009, John W. Eaton wrote: | On 13-Nov-2009, Michael Goffioul wrote: | | | I'll test that asap. It should rebuild cruft.def properly. But I think | | I'll still miss the addition of XTRA_CRUFT_SH_LDFLAGS to the link flags. | | Does this additional change fix that problem for you? | | diff --git a/libcruft/Makefile.am b/libcruft/Makefile.am | --- a/libcruft/Makefile.am | +++ b/libcruft/Makefile.am | @@ -29,7 +29,8 @@ | | libcruft_la_SOURCES = | | -libcruft_la_LDFLAGS = -release $(version) $(NO_UNDEFINED_LDFLAG) | +libcruft_la_LDFLAGS = \ | + -release $(version) $(NO_UNDEFINED_LDFLAG) @XTRA_CRUFT_SH_LDFLAGS@ | | libcruft_la_LIBADD = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) One more try. Here is the current complete patch. Please let me know if this works for you. 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/20091113/7e19f98d/attachment.ksh From michael.goffioul at gmail.com Fri Nov 13 14:21:50 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Fri, 13 Nov 2009 20:21:50 +0000 Subject: gnulib and automake In-Reply-To: <19197.42624.793244.338602@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <19193.45734.551735.424206@segfault.lan> <4AF9B961.1070502@gmx.net> <19193.56432.620743.620783@segfault.lan> <128f38bd0911121346m3aad0b85q5ebc11420945b0a2@mail.gmail.com> <19196.33882.797708.699014@segfault.lan> <19196.39424.88855.594114@segfault.lan> <128f38bd0911130250s64b3d16blbe75df293ca1ef7@mail.gmail.com> <19197.39757.734427.585503@segfault.lan> <19197.42624.793244.338602@segfault.lan> Message-ID: <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> This will definitely help, but that won't be enough. I'm also missing OCTAVE_DLL_DEFS and the likes in CPPFLAGS for the various octave libraries. But more problematic is the use of i686-pc-msdosmsvc as build target with libtool. This is not recognized by libtool and it simply refuses to build shared libraries (whether you use --enable-shared or not). I see 2 ways to work around that: 1) Drop the build target and let configure script detect it; as I run it within MSYS, it'll detect mingw platform and accept to build shared libs; after configure script, I then have to hack the libtool script to make it work with my cc-msvc compiler (gcc-like wrapper on top of MSVC), which I already did in order to compile other dep libs, so that's not a problem. This means that the configure script should be change, whenever it does something special for msdosmsvc platform 2) Hack libtool to accept that non standard build target. Given the complexity of libtool and the fact that it would only be valid for my gcc-like wrapper (no chance to get changes upstream into libtool), this option doesn't have really my preference. Michael. On Fri, Nov 13, 2009 at 6:33 PM, John W. Eaton wrote: > On 13-Nov-2009, John W. Eaton wrote: > > | On 13-Nov-2009, Michael Goffioul wrote: > | > | | I'll test that asap. It should rebuild cruft.def properly. But I think > | | I'll still miss the addition of XTRA_CRUFT_SH_LDFLAGS to the link flags. > | > | Does this additional change fix that problem for you? > | > | diff --git a/libcruft/Makefile.am b/libcruft/Makefile.am > | --- a/libcruft/Makefile.am > | +++ b/libcruft/Makefile.am > | @@ -29,7 +29,8 @@ > | > | ?libcruft_la_SOURCES = > | > | -libcruft_la_LDFLAGS = -release $(version) $(NO_UNDEFINED_LDFLAG) > | +libcruft_la_LDFLAGS = \ > | + ?-release $(version) $(NO_UNDEFINED_LDFLAG) @XTRA_CRUFT_SH_LDFLAGS@ > | > | ?libcruft_la_LIBADD = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) > > One more try. ?Here is the current complete patch. ?Please let me know > if this works for you. > > Thanks, > > jwe > > > # HG changeset patch > # User John W. Eaton > # Date 1258137155 18000 > # Node ID 2fc0d63f4c5d963d868b734f2c2fe9b8d5af35ce > # Parent ?7c211d0091d923e74f684ac82bf09d0ec02bd55c > restore rules to create libcruft/cruft.def > > diff --git a/ChangeLog b/ChangeLog > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,7 @@ > +2009-11-12 ?John W. Eaton ? > + > + ? ? ? * configure.ac (AC_CONFIG_FILES): Also generate libcruft/mkf77def. > + > ?2009-11-11 ?John W. Eaton ? > > ? ? ? ?* acinclude.m4 (OCTAVE_IEEE754_DATA_FORMAT): Fail if IEEE 754 > diff --git a/configure.ac b/configure.ac > --- a/configure.ac > +++ b/configure.ac > @@ -2149,6 +2149,7 @@ > ? doc/refcard/Makefile > ? examples/Makefile > ? libcruft/Makefile > + ?libcruft/mkf77def > ? liboctave/Makefile > ? scripts/Makefile > ? src/Makefile > diff --git a/libcruft/ChangeLog b/libcruft/ChangeLog > --- a/libcruft/ChangeLog > +++ b/libcruft/ChangeLog > @@ -1,3 +1,11 @@ > +2009-11-13 ?John W. Eaton ? > + > + ? ? ? * Makefile.am: Restore rules for building cruft.def. > + ? ? ? (libcruft_la_LDFLAGS): Also append @XTRA_CRUFT_SH_LDFLAGS at . > + ? ? ? (libcruft_la_DEPENDENCIES): New variable. > + ? ? ? * mkf77def.in: Use @VAR@ instead of %VAR% substitutions. > + ? ? ? Process srcdir plus list of files instead of working as a filter. > + > ?2009-11-10 ?John W. Eaton ? > > ? ? ? ?* blas, lapack: Remove directories and all files. > diff --git a/libcruft/Makefile.am b/libcruft/Makefile.am > --- a/libcruft/Makefile.am > +++ b/libcruft/Makefile.am > @@ -29,10 +29,13 @@ > > ?libcruft_la_SOURCES = > > -libcruft_la_LDFLAGS = -release $(version) $(NO_UNDEFINED_LDFLAG) > +libcruft_la_LDFLAGS = \ > + ?-release $(version) $(NO_UNDEFINED_LDFLAG) @XTRA_CRUFT_SH_LDFLAGS@ > > ?libcruft_la_LIBADD = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) > > +libcruft_la_DEPENDENCIES = cruft.def > + > ?octinclude_HEADERS = > > ?EXTRA_DIST = ChangeLog STOP.patch mkf77def.in > @@ -52,3 +55,8 @@ > ?include slatec-err/module.mk > ?include slatec-fn/module.mk > ?include villad/module.mk > + > +cruft.def: $(libcruft_la_SOURCES) $(TOPDIR)/libcruft/mkf77def > + ? ? ? chmod a+rx mkf77def > + ? ? ? ./mkf77def $(srcdir) $(libcruft_la_SOURCES) > $@-t > + ? ? ? mv $@-t $@ > diff --git a/libcruft/mkf77def.in b/libcruft/mkf77def.in > old mode 100644 > new mode 100755 > --- a/libcruft/mkf77def.in > +++ b/libcruft/mkf77def.in > @@ -21,9 +21,9 @@ > ?SED=${SED:-'sed'} > ?AWK=${AWK:-'awk'} > > -F77_TOLOWER=%F77_APPEND_UNDERSCORE% > -F77_APPEND_UNDERSCORE=%F77_APPEND_UNDERSCORE% > -F77_APPEND_EXTRA_UNDERSCORE=%F77_APPEND_EXTRA_UNDERSCORE% > +F77_TOLOWER="@F77_APPEND_UNDERSCORE@" > +F77_APPEND_UNDERSCORE="@F77_APPEND_UNDERSCORE@" > +F77_APPEND_EXTRA_UNDERSCORE="@F77_APPEND_EXTRA_UNDERSCORE@" > > ?if $F77_TOLOWER; then > ? case_cmd="tolower"; > @@ -43,4 +43,13 @@ > ? awkcmd="$AWK '{ printf (\"%s%s\n\", tolower (\$0), \"$uscore\"); }'" > ?fi > > -$SED -n -e 'y/ABCDEFGHIJLKMNOPQRSTUVWXYZ/abcdefghijlkmnopqrstuvwxyz/; s/^\( ? ? ?\| ? ?\)[ ? ? ]*\(.*function\|subroutine\|entry\)[ ? ?]*\([^ ?(]*\).*$/\3/p' | eval $awkcmd > +if [ $# -gt 1 ]; then > + ?srcdir="$1" > + ?shift > +fi > + > +echo EXPORTS > +for arg > +do > + ?$SED -n -e 'y/ABCDEFGHIJLKMNOPQRSTUVWXYZ/abcdefghijlkmnopqrstuvwxyz/; s/^\( ? ? ?\| ?\)[ ? ? ]*\(.*function\|subroutine\|entry\)[ ? ?]*\([^ ?(]*\).*$/\3/p' "$srcdir/$arg" | eval $awkcmd > +done > > From jwe at octave.org Fri Nov 13 21:48:48 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 13 Nov 2009 22:48:48 -0500 Subject: gnulib and automake In-Reply-To: <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> References: <19121.21838.419944.184758@segfault.lan> <19193.45734.551735.424206@segfault.lan> <4AF9B961.1070502@gmx.net> <19193.56432.620743.620783@segfault.lan> <128f38bd0911121346m3aad0b85q5ebc11420945b0a2@mail.gmail.com> <19196.33882.797708.699014@segfault.lan> <19196.39424.88855.594114@segfault.lan> <128f38bd0911130250s64b3d16blbe75df293ca1ef7@mail.gmail.com> <19197.39757.734427.585503@segfault.lan> <19197.42624.793244.338602@segfault.lan> <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> Message-ID: <19198.10400.313123.479215@segfault.lan> On 13-Nov-2009, Michael Goffioul wrote: | This will definitely help, but that won't be enough. I'm also | missing OCTAVE_DLL_DEFS and the likes in CPPFLAGS | for the various octave libraries. OK, I checked in the earlier change and the following: http://hg.savannah.gnu.org/hgweb/octave/rev/b1462c588dd5 Thanks, jwe From jwe at octave.org Fri Nov 13 21:53:02 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 13 Nov 2009 22:53:02 -0500 Subject: gnulib and automake In-Reply-To: <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> References: <19121.21838.419944.184758@segfault.lan> <19193.45734.551735.424206@segfault.lan> <4AF9B961.1070502@gmx.net> <19193.56432.620743.620783@segfault.lan> <128f38bd0911121346m3aad0b85q5ebc11420945b0a2@mail.gmail.com> <19196.33882.797708.699014@segfault.lan> <19196.39424.88855.594114@segfault.lan> <128f38bd0911130250s64b3d16blbe75df293ca1ef7@mail.gmail.com> <19197.39757.734427.585503@segfault.lan> <19197.42624.793244.338602@segfault.lan> <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> Message-ID: <19198.10654.902488.247862@segfault.lan> On 13-Nov-2009, Michael Goffioul wrote: | But more problematic is the | use of i686-pc-msdosmsvc as build target with libtool. This is | not recognized by libtool and it simply refuses to build shared | libraries (whether you use --enable-shared or not). I see 2 ways | to work around that: I'm not sure what's best here. I'd really like to see it just work automatically if possible, and would be willing to do some work/lobbying to try to get whatever changes are needed into libtool and config.{sub,guess} to make that happen. I'm not sure we'd be successful, but I'm willing to try. jwe From j4r.e4o at gmail.com Sat Nov 14 00:59:31 2009 From: j4r.e4o at gmail.com (Javier Enciso) Date: Sat, 14 Nov 2009 07:59:31 +0100 Subject: Spanish Translation In-Reply-To: <9543b3a40911131032s10f117ffyae76c5b2e2f6ffcd@mail.gmail.com> References: <13508.190.24.181.227.1257918482.squirrel@mail.udistrital.edu.co> <420fb9e60911110031i4bc7b405w6f486b93fa2515f6@mail.gmail.com> <4AFA7901.3020203@dbateman.org> <4AFA9B1E.7070601@googlemail.com> <9543b3a40911131032s10f117ffyae76c5b2e2f6ffcd@mail.gmail.com> Message-ID: <4AFE5553.6080004@googlemail.com> Jordi Guti?rrez Hermoso wrote: > There are plenty of technical terms which I'm sure are still not > uniform in Spanish, and I personally hope we can avoid calques. For > example, sparse matrices should be "matrices ralas", not "matrices > esparcidas". > I definitely agree. Also, there are lot of differences between the Spanish from Spain and the International one. I think the Wiki is a good starting point to discuss such disparities and standardize the usage of the language. It would be great if any of you guys can start the Spanish translation of the Wiki (right now I'm in a trip and don't have the time to do so :( ). Javier From paulocoronado at gmail.com Sat Nov 14 02:05:03 2009 From: paulocoronado at gmail.com (Paulo Cesar coronado) Date: Sat, 14 Nov 2009 03:05:03 -0500 Subject: Spanish Translation In-Reply-To: <4AFE5553.6080004@googlemail.com> References: <13508.190.24.181.227.1257918482.squirrel@mail.udistrital.edu.co> <420fb9e60911110031i4bc7b405w6f486b93fa2515f6@mail.gmail.com> <4AFA7901.3020203@dbateman.org> <4AFA9B1E.7070601@googlemail.com> <9543b3a40911131032s10f117ffyae76c5b2e2f6ffcd@mail.gmail.com> <4AFE5553.6080004@googlemail.com> Message-ID: <4AFE64AF.5020506@udistrital.edu.co> Very good idea, at this time i am interested in having an spanish version of the manual. I have translated a few pages of it and I asked in the list for a password to be registered in the wiki. If you agree. I can start the translation work or I could help in the translation task. Paulo Cesar From michael.goffioul at gmail.com Sat Nov 14 09:26:38 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Sat, 14 Nov 2009 15:26:38 +0000 Subject: gnulib and automake In-Reply-To: <19198.10654.902488.247862@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <19193.56432.620743.620783@segfault.lan> <128f38bd0911121346m3aad0b85q5ebc11420945b0a2@mail.gmail.com> <19196.33882.797708.699014@segfault.lan> <19196.39424.88855.594114@segfault.lan> <128f38bd0911130250s64b3d16blbe75df293ca1ef7@mail.gmail.com> <19197.39757.734427.585503@segfault.lan> <19197.42624.793244.338602@segfault.lan> <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> <19198.10654.902488.247862@segfault.lan> Message-ID: <128f38bd0911140726v491e8e09y93786ec6a2f6f8cf@mail.gmail.com> On Sat, Nov 14, 2009 at 3:53 AM, John W. Eaton wrote: > On 13-Nov-2009, Michael Goffioul wrote: > > | But more problematic is the > | use of i686-pc-msdosmsvc as build target with libtool. This is > | not recognized by libtool and it simply refuses to build shared > | libraries (whether you use --enable-shared or not). I see 2 ways > | to work around that: > > I'm not sure what's best here. ?I'd really like to see it just work > automatically if possible, and would be willing to do some > work/lobbying to try to get whatever changes are needed into libtool > and config.{sub,guess} to make that happen. ?I'm not sure we'd be > successful, but I'm willing to try. Indeed, that would be nice it'd just work out of the box, however this might be a complex task, given the complexity of libtool. Also, it would have to work with standard MSVC compiler, not the gcc-like wrapper I'm using. I think what I'll do first is trying to get octave compilable with MSVC, which is not the case anymore (i'll start another thread about that), with my own toolchain. Then I'll see if I can get it working using standard tools. Up to now, I could get libcruft compiled. Michael. From michael.goffioul at gmail.com Sat Nov 14 09:31:07 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Sat, 14 Nov 2009 15:31:07 +0000 Subject: Compilation failure, template problems Message-ID: <128f38bd0911140731q4ab898c2qc52c10534a2ec587@mail.gmail.com> Hi, Using recent octave archive, MSVC fails to compile liboctave due to a template problems. The error is the following: ../../liboctave/CNDArray.cc(763) : error C2563: mismatch in formal parameter list ../../liboctave/CNDArray.cc(763) : error C2563: mismatch in formal parameter list ../../liboctave/CNDArray.cc(763) : error C2440: 'specialization' : cannot convert from 'overloaded-function' to 'double (__cdecl *const )(Complex)' None of the functions with this name in scope match the target type ../../liboctave/CNDArray.cc(763) : error C2973: 'do_mx_unary_map' : invalid template argument 'overloaded-function' c:\sources\playground\c\octave-graphics-hg\liboctave\mx-inlines.cc(264) : see declaration of 'do_mx_unary_map' ../../liboctave/CNDArray.cc(763) : error C2668: 'do_mx_unary_map' : ambiguous call to overloaded function c:\sources\playground\c\octave-graphics-hg\liboctave\mx-inlines.cc(271): could be 'RNDA do_mx_unary_map(const std::complex &)>(const XNDA &)' with [ RNDA=NDArray, XNDA=ComplexNDArray ] c:\sources\playground\c\octave-graphics-hg\liboctave\mx-inlines.cc(264): or 'RNDA do_mx_unary_map(const XNDA &)' with [ RNDA=NDArray, XNDA=ComplexNDArray ] while trying to match the argument list '(const ComplexNDArray)' Any idea how to work around the problem? This part of the code seems pretty recent. Michael. From michael.goffioul at gmail.com Sat Nov 14 11:13:56 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Sat, 14 Nov 2009 17:13:56 +0000 Subject: Compilation failure, template problems In-Reply-To: <128f38bd0911140731q4ab898c2qc52c10534a2ec587@mail.gmail.com> References: <128f38bd0911140731q4ab898c2qc52c10534a2ec587@mail.gmail.com> Message-ID: <128f38bd0911140913n71c2800dl6b02bb602e8114b2@mail.gmail.com> I think I narrowed down the problem to the following piece of code, which does not compile under MSVC. If I remove the 'g' overloads to only keep the 'double' one, then it compiles fine. Any chance to get a workaround? Michael. #include template class A { public: typedef T element_type; }; template void f() { std::cout << "f" << std::endl; } double g(double x) { std::cout << "g(double)" << std::endl; return x; } int g(int x) { std::cout << "g(int)" << std::endl; } float g(float x) { std::cout << "g(float)" << std::endl; } int main(int argc, char **argv) { f,g>(); return 0; } On Sat, Nov 14, 2009 at 3:31 PM, Michael Goffioul wrote: > Hi, > > Using recent octave archive, MSVC fails to compile liboctave due > to a template problems. The error is the following: > > ../../liboctave/CNDArray.cc(763) : error C2563: mismatch in formal > parameter list > ../../liboctave/CNDArray.cc(763) : error C2563: mismatch in formal > parameter list > ../../liboctave/CNDArray.cc(763) : error C2440: 'specialization' : > cannot convert from 'overloaded-function' to 'double (__cdecl *const > )(Complex)' > ? ? ? ?None of the functions with this name in scope match the target type > ../../liboctave/CNDArray.cc(763) : error C2973: 'do_mx_unary_map' : > invalid template argument 'overloaded-function' > ? ? ? ?c:\sources\playground\c\octave-graphics-hg\liboctave\mx-inlines.cc(264) > : see declaration of 'do_mx_unary_map' > ../../liboctave/CNDArray.cc(763) : error C2668: 'do_mx_unary_map' : > ambiguous call to overloaded function > ? ? ? ?c:\sources\playground\c\octave-graphics-hg\liboctave\mx-inlines.cc(271): > could be 'RNDA do_mx_unary_map std::abs(const std::complex &)>(const XNDA &)' > ? ? ? ?with > ? ? ? ?[ > ? ? ? ? ? ?RNDA=NDArray, > ? ? ? ? ? ?XNDA=ComplexNDArray > ? ? ? ?] > ? ? ? ?c:\sources\playground\c\octave-graphics-hg\liboctave\mx-inlines.cc(264): > or ? ? ? 'RNDA do_mx_unary_map(const > XNDA &)' > ? ? ? ?with > ? ? ? ?[ > ? ? ? ? ? ?RNDA=NDArray, > ? ? ? ? ? ?XNDA=ComplexNDArray > ? ? ? ?] > ? ? ? ?while trying to match the argument list '(const ComplexNDArray)' > > Any idea how to work around the problem? This part of the code seems > pretty recent. > > Michael. > From jwe at octave.org Sat Nov 14 11:45:12 2009 From: jwe at octave.org (John W. Eaton) Date: Sat, 14 Nov 2009 12:45:12 -0500 Subject: finally actually using gnulib Message-ID: <19198.60584.771475.300423@segfault.lan> I've made some additional changes to start using gnulib in Octave. A preliminary changeset is here: jweaton.org/gnulib-diffs.gz The biggest change is that you have to have git to check out the gnulib sources. This requirement only applies to building from Octave's Mercuial archive, not from a distribution or snapshot tarball. There is also a new file called HACKING in the archive that is intended to explain the tools required to build Octave from a Mercuial checkout. This file should probably be expanded to also include information about the library dependencies (blas, lapack, fftw, ...), the release procedure, etc. I'll leave that for another day. For the initial test of using gnulib, I chose to replace liboctave/strftime.c with the gnulib version of strftime. Unless there are seious objections, I will start to replace other portability and replacement functions gnulib versions soon. This change is working fine for me, so unless problems are reported, I intend to check it in within the next few days. Comments? jwe From lindnerben at gmx.net Sat Nov 14 13:03:45 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sat, 14 Nov 2009 20:03:45 +0100 Subject: finally actually using gnulib In-Reply-To: <19198.60584.771475.300423@segfault.lan> References: <19198.60584.771475.300423@segfault.lan> Message-ID: <4AFEFF11.1070906@gmx.net> John W. Eaton wrote: > > The biggest change is that you have to have git to check out the > gnulib sources. Hmm, apparently git is not available for windows, only for cygwin. At least git's homepage does not have any info on native windows ports, nor does a quick google-search. Yes there is http://code.google.com/p/msysgit/ but what you get there is something very closely mingled with a own separate msys installation, so you cannot use it from within an msys session for building octave. It's also not clear if this port is even usable with a standard msys installation from mingw.org. According to the changelogs, they patched or extended msys so no, obviously it will not work with a standard msys installation. Not what I was looking for. Glancing at your diff I seems one now also requires rsync. Am I right? Guess what - also not available for windows, except cygwin. Aren't there releases or snapshots of gnulib available? I must check out from the development sources? How is getting gnulib for an octave build done? Can I do it once separately, store it locally somewhere on my machine? benjamin From jwe at octave.org Sat Nov 14 13:28:45 2009 From: jwe at octave.org (John W. Eaton) Date: Sat, 14 Nov 2009 14:28:45 -0500 Subject: finally actually using gnulib In-Reply-To: <4AFEFF11.1070906@gmx.net> References: <19198.60584.771475.300423@segfault.lan> <4AFEFF11.1070906@gmx.net> Message-ID: <19199.1261.357129.774344@segfault.lan> On 14-Nov-2009, Benjamin Lindner wrote: | Hmm, apparently git is not available for windows, only for cygwin. | At least git's homepage does not have any info on native windows | ports, nor does a quick google-search. | | Yes there is http://code.google.com/p/msysgit/ | but what you get there is something very closely mingled with a | own separate msys installation, so you cannot use it from within an | msys session for building octave. It's also not clear if this port | is even usable with a standard msys installation from mingw.org. | According to the changelogs, they patched or extended msys so no, | obviously it will not work with a standard msys installation. | | Not what I was looking for. | | Glancing at your diff I seems one now also requires rsync. Am I right? | Guess what - also not available for windows, except cygwin. | | Aren't there releases or snapshots of gnulib available? | I must check out from the development sources? | | How is getting gnulib for an octave build done? | Can I do it once separately, store it locally somewhere on my machine? Yes, you can do this. The bootstrap script accepts the argument --gnulib-srcdir=DIRNAME Specify the local directory where gnulib sources reside. Use this if you already have gnulib sources on your machine, and do not want to waste your bandwidth downloading them again. You can also use this argument to speed up subsequent autogen.sh runs even if you use git for the initial checkout. The --copy argument may also help if you can't create symbolic links. The autogen.sh script doesn't process any arguments itself and instead passes all arguments to the bootstrap script. So you should be able to * Get a copy of gnulib on your system. If you download them with git (say with Cygwin), but don't want to or can't use git when you run autogen.sh, then remove or rename the .git directory in the gnulib source tree. Otherwise, it looks like the bootstrip script will try to use git to update the gnulib sources. * Run ./autogen.sh --copy --gnulib-srcdir=/location/of/gnulib The advantage of using git is that you immediately and automatically get updates from the gnulib source tree as soon as they are available. If you absolutely cannot find a way to use git to download the gnulib sources, then I suppose we could make a tar file available somewhere and keep it up to date. As far as I can tell, rsync is only used for downloading gettext translation (.po) files, and since we are not (yet) using gettext, I guess the rsync problem can be deferred for a while longer. jwe From shaiay at gmail.com Sat Nov 14 14:11:40 2009 From: shaiay at gmail.com (Shai Ayal) Date: Sat, 14 Nov 2009 22:11:40 +0200 Subject: openGL printing In-Reply-To: <4AFD3DF1.9030603@isl.stanford.edu> References: <4AFD3DF1.9030603@isl.stanford.edu> Message-ID: <420fb9e60911141211i652c5e4n6ffaa11027b7bb55@mail.gmail.com> On Fri, Nov 13, 2009 at 1:07 PM, Michael Godfrey wrote: > A very minor adjustment of xlabel and ylabel is needed. > The following example should show the problem: > octave:1> plot([1:200]) > octave:2> xlabel('this is xlabel'); > octave:3> ylabel('this is ylabel'); > octave:4> title('this is the title'); > octave:5> print "test01.ps" > ========================= > The plot looks just fine with the x and y labels positioned > correctly. ?However, the PS file has the x and y labels written > too close to the actual x and y axes so that the text overlaps > the numeric scale values. The attached changeset fixes this issue by computing the bounding box of the text with the freetype renderer also when printing postscript. This bounding box is used by the gl-render code to auto compute the position of the axes labels. Note - the on-screen fonts and the postscript fonts are not necessarily identical, so the result might not look so good depending on the available fonts on your system .... Shai -------------- next part -------------- A non-text attachment was scrubbed... Name: gl2ps_bbox.changeset Type: application/octet-stream Size: 4133 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091114/933738a4/attachment.obj From lindnerben at gmx.net Sat Nov 14 14:16:28 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sat, 14 Nov 2009 21:16:28 +0100 Subject: finally actually using gnulib In-Reply-To: <19199.1261.357129.774344@segfault.lan> References: <19198.60584.771475.300423@segfault.lan> <4AFEFF11.1070906@gmx.net> <19199.1261.357129.774344@segfault.lan> Message-ID: <4AFF101C.5020305@gmx.net> John W. Eaton wrote: > On 14-Nov-2009, Benjamin Lindner wrote: > > | Hmm, apparently git is not available for windows, only for cygwin. > | At least git's homepage does not have any info on native windows > | ports, nor does a quick google-search. > | > | Yes there is http://code.google.com/p/msysgit/ > | but what you get there is something very closely mingled with a > | own separate msys installation, so you cannot use it from within an > | msys session for building octave. It's also not clear if this port > | is even usable with a standard msys installation from mingw.org. > | According to the changelogs, they patched or extended msys so no, > | obviously it will not work with a standard msys installation. > | > | Not what I was looking for. > | > | Glancing at your diff I seems one now also requires rsync. Am I right? > | Guess what - also not available for windows, except cygwin. > | > | Aren't there releases or snapshots of gnulib available? > | I must check out from the development sources? > | > | How is getting gnulib for an octave build done? > | Can I do it once separately, store it locally somewhere on my machine? > > Yes, you can do this. The bootstrap script accepts the argument > > --gnulib-srcdir=DIRNAME Specify the local directory where gnulib > sources reside. Use this if you already > have gnulib sources on your machine, and > do not want to waste your bandwidth downloading > them again. Aha, this looks promising. > You can also use this argument to speed up subsequent autogen.sh runs > even if you use git for the initial checkout. > > The --copy argument may also help if you can't create symbolic links. > > The autogen.sh script doesn't process any arguments itself and instead > passes all arguments to the bootstrap script. So you should be able > to > > * Get a copy of gnulib on your system. If you download them with > git (say with Cygwin), but don't want to or can't use git when you > run autogen.sh, then remove or rename the .git directory in the > gnulib source tree. Otherwise, it looks like the bootstrip script > will try to use git to update the gnulib sources. Would it be possible to prevent this, by an additional option like --no-update? Or implicitly disable it, if the script is called with the --gnulib-srcdir option? I guess by removing/renaming/deleting the .git directory in the checkout tree I cannot run a git update (even separately, e.g. from within cygwin), which kind of defeates the intended use of git benjamin From shaiay at gmail.com Sat Nov 14 14:24:31 2009 From: shaiay at gmail.com (Shai Ayal) Date: Sat, 14 Nov 2009 22:24:31 +0200 Subject: finally actually using gnulib In-Reply-To: <4AFEFF11.1070906@gmx.net> References: <19198.60584.771475.300423@segfault.lan> <4AFEFF11.1070906@gmx.net> Message-ID: <420fb9e60911141224p3adbee11od4d35824be82779f@mail.gmail.com> On Sat, Nov 14, 2009 at 9:03 PM, Benjamin Lindner wrote: > John W. Eaton wrote: >> >> The biggest change is that you have to have git to check out the >> gnulib sources. > > Hmm, apparently git is not available for windows, only for cygwin. > At least git's homepage does not have any info on native windows > ports, nor does a quick google-search. > > Yes there is http://code.google.com/p/msysgit/ > but what you get there is something very closely mingled with a > own separate msys installation, so you cannot use it from within an > msys session for building octave. It's also not clear if this port > is even usable with a standard msys installation from mingw.org. > According to the changelogs, they patched or extended msys so no, > obviously it will not work with a standard msys installation. > > Not what I was looking for. > > Glancing at your diff I seems one now also requires rsync. Am I right? > Guess what - also not available for windows, except cygwin. > > Aren't there releases or snapshots of gnulib available? > I must check out from the development sources? you can get a tgz "snapshot" of the development sources via web by browsing to: http://git.savannah.gnu.org/gitweb/?p=gnulib.git and clicking on the "snapshot" link of the latest commit. there is probably a link to download the latest HEAD Shai From lindnerben at gmx.net Sat Nov 14 14:50:05 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sat, 14 Nov 2009 21:50:05 +0100 Subject: finally actually using gnulib In-Reply-To: <420fb9e60911141224p3adbee11od4d35824be82779f@mail.gmail.com> References: <19198.60584.771475.300423@segfault.lan> <4AFEFF11.1070906@gmx.net> <420fb9e60911141224p3adbee11od4d35824be82779f@mail.gmail.com> Message-ID: <4AFF17FD.8000008@gmx.net> Shai Ayal wrote: >> Aren't there releases or snapshots of gnulib available? >> I must check out from the development sources? > > you can get a tgz "snapshot" of the development sources via web by browsing to: > http://git.savannah.gnu.org/gitweb/?p=gnulib.git > and clicking on the "snapshot" link of the latest commit. > there is probably a link to download the latest HEAD Thanks for this hint. This is probably the fastest way to get it testing. benjamin From highegg at gmail.com Sat Nov 14 14:52:55 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Sat, 14 Nov 2009 21:52:55 +0100 Subject: Compilation failure, template problems In-Reply-To: <128f38bd0911140731q4ab898c2qc52c10534a2ec587@mail.gmail.com> References: <128f38bd0911140731q4ab898c2qc52c10534a2ec587@mail.gmail.com> Message-ID: <69d8d540911141252t43aaaecelf4cd6957ef1eabf5@mail.gmail.com> On Sat, Nov 14, 2009 at 4:31 PM, Michael Goffioul < michael.goffioul at gmail.com> wrote: > Hi, > > Using recent octave archive, MSVC fails to compile liboctave due > to a template problems. The error is the following: > > ../../liboctave/CNDArray.cc(763) : error C2563: mismatch in formal > parameter list > ../../liboctave/CNDArray.cc(763) : error C2563: mismatch in formal > parameter list > ../../liboctave/CNDArray.cc(763) : error C2440: 'specialization' : > cannot convert from 'overloaded-function' to 'double (__cdecl *const > )(Complex)' > None of the functions with this name in scope match the target type > ../../liboctave/CNDArray.cc(763) : error C2973: 'do_mx_unary_map' : > invalid template argument 'overloaded-function' > > c:\sources\playground\c\octave-graphics-hg\liboctave\mx-inlines.cc(264) > : see declaration of 'do_mx_unary_map' > ../../liboctave/CNDArray.cc(763) : error C2668: 'do_mx_unary_map' : > ambiguous call to overloaded function > > c:\sources\playground\c\octave-graphics-hg\liboctave\mx-inlines.cc(271): > could be 'RNDA do_mx_unary_map std::abs(const std::complex &)>(const XNDA &)' > with > [ > RNDA=NDArray, > XNDA=ComplexNDArray > ] > > c:\sources\playground\c\octave-graphics-hg\liboctave\mx-inlines.cc(264): > or 'RNDA do_mx_unary_map(const > XNDA &)' > with > [ > RNDA=NDArray, > XNDA=ComplexNDArray > ] > while trying to match the argument list '(const ComplexNDArray)' > > Any idea how to work around the problem? This part of the code seems > pretty recent. > > Michael. > I think this should compile - name resolution for template function parameters works like for regular parameters. Here the signature is fully determined by the previous parameters, so a unique match should be found. So I think this is a bug in MSVC. Unfortunately, the typical way to pick a specific overload (cast the name reference to specific function pointer type) doesn't work in this case, because only integral and enum casts are allowed in template params. Maybe just specifying std::abs instead of std::abs would work? Otherwise, I think you'll need to wrap std::abs in a function with unique name and substitute that for the template parameter. -- 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/20091114/d9b55777/attachment-0001.html From michael.goffioul at gmail.com Sat Nov 14 15:08:45 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Sat, 14 Nov 2009 21:08:45 +0000 Subject: Compilation failure, template problems In-Reply-To: <69d8d540911141252t43aaaecelf4cd6957ef1eabf5@mail.gmail.com> References: <128f38bd0911140731q4ab898c2qc52c10534a2ec587@mail.gmail.com> <69d8d540911141252t43aaaecelf4cd6957ef1eabf5@mail.gmail.com> Message-ID: <128f38bd0911141308o1d544a74wffc229d7ac188843@mail.gmail.com> On Sat, Nov 14, 2009 at 8:52 PM, Jaroslav Hajek wrote: > > > On Sat, Nov 14, 2009 at 4:31 PM, Michael Goffioul > wrote: >> >> Hi, >> >> Using recent octave archive, MSVC fails to compile liboctave due >> to a template problems. The error is the following: >> >> ../../liboctave/CNDArray.cc(763) : error C2563: mismatch in formal >> parameter list >> ../../liboctave/CNDArray.cc(763) : error C2563: mismatch in formal >> parameter list >> ../../liboctave/CNDArray.cc(763) : error C2440: 'specialization' : >> cannot convert from 'overloaded-function' to 'double (__cdecl *const >> )(Complex)' >> ? ? ? ?None of the functions with this name in scope match the target type >> ../../liboctave/CNDArray.cc(763) : error C2973: 'do_mx_unary_map' : >> invalid template argument 'overloaded-function' >> >> ?c:\sources\playground\c\octave-graphics-hg\liboctave\mx-inlines.cc(264) >> : see declaration of 'do_mx_unary_map' >> ../../liboctave/CNDArray.cc(763) : error C2668: 'do_mx_unary_map' : >> ambiguous call to overloaded function >> >> ?c:\sources\playground\c\octave-graphics-hg\liboctave\mx-inlines.cc(271): >> could be 'RNDA do_mx_unary_map> std::abs(const std::complex &)>(const XNDA &)' >> ? ? ? ?with >> ? ? ? ?[ >> ? ? ? ? ? ?RNDA=NDArray, >> ? ? ? ? ? ?XNDA=ComplexNDArray >> ? ? ? ?] >> >> ?c:\sources\playground\c\octave-graphics-hg\liboctave\mx-inlines.cc(264): >> or ? ? ? 'RNDA do_mx_unary_map(const >> XNDA &)' >> ? ? ? ?with >> ? ? ? ?[ >> ? ? ? ? ? ?RNDA=NDArray, >> ? ? ? ? ? ?XNDA=ComplexNDArray >> ? ? ? ?] >> ? ? ? ?while trying to match the argument list '(const ComplexNDArray)' >> >> Any idea how to work around the problem? This part of the code seems >> pretty recent. >> >> Michael. > > I think this should compile - name resolution for template function > parameters works like for regular parameters. Here the signature is fully > determined by the previous parameters, so a unique match should be found. > So I think this is a bug in MSVC. > Unfortunately, the typical way to pick a specific overload (cast the name > reference to specific function pointer type) doesn't work in this case, > because only integral and enum casts are allowed in template params. Maybe > just specifying std::abs instead of std::abs would work? Otherwise, > I think you'll need to wrap std::abs in a function with unique name and > substitute that for the template parameter. I tried various things, but none of them work. For instance, the following: double d_abs(double x) { return std::abs(x); } NDArray NDArray::abs (void) const { return do_mx_unary_map (*this); } gives me the following error: ../../liboctave/dNDArray.cc(880) : error C2440: 'specialization' : cannot convert from 'double (__cdecl *)(double)' to 'double (__cdecl *const )(const double &)' This conversion requires a reinterpret_cast, a C-style cast or function-style cast However, I think the problem is more than simply being unable to resolve the ambiguity. It seems MSVC fails to handle the situation correctly when dealing with inner types and/or overloaded functions. For instance, the following works fine: double g(double x) { std::cout << "g(double)" << std::endl; return x; } int g(int x) { std::cout << "g(int)" << std::endl; return x; } float g(float x) { std::cout << "g(float)" << std::endl; return x; } template T h(T t) { return fun(t); } int main(int argc, char **argv) { std::cout << h(-10) << std::endl; return 0; } I also think this is a bug in MSVC. I'm more interested in a workaround. Otherwise, this will mean the game is over. Michael. From jwe at octave.org Sat Nov 14 15:51:42 2009 From: jwe at octave.org (John W. Eaton) Date: Sat, 14 Nov 2009 16:51:42 -0500 Subject: finally actually using gnulib In-Reply-To: <4AFF101C.5020305@gmx.net> References: <19198.60584.771475.300423@segfault.lan> <4AFEFF11.1070906@gmx.net> <19199.1261.357129.774344@segfault.lan> <4AFF101C.5020305@gmx.net> Message-ID: <19199.9838.139399.534812@segfault.lan> On 14-Nov-2009, Benjamin Lindner wrote: | Would it be possible to prevent this, by an additional option like | --no-update? Or implicitly disable it, if the script is called with | the --gnulib-srcdir option? | I guess by removing/renaming/deleting the .git directory in the | checkout tree I cannot run a git update (even separately, e.g. from | within cygwin), which kind of defeates the intended use of git That's why I suggested renaming it instead of removing it. Then you can temporarily put it back in place for the update, then move it aside for building. But yes, an option might also be useful. Since this is an option for the bootstrap script which we are using unmodified from the gnulib/build-aux directory, the place to suggest that is the bug-gnulib at gnu.org list. I don't think that implicitly disabling if the --gnulib-srcdir option is specified is the right thing to do. I'd guess that the original idea behind that option was to allow a single gnulib source tree to be shared among several projects. jwe From paulocoronado at gmail.com Sat Nov 14 23:47:47 2009 From: paulocoronado at gmail.com (Paulo Cesar coronado) Date: Sun, 15 Nov 2009 00:47:47 -0500 Subject: Spanish Translation In-Reply-To: <4AFE5553.6080004@googlemail.com> References: <13508.190.24.181.227.1257918482.squirrel@mail.udistrital.edu.co> <420fb9e60911110031i4bc7b405w6f486b93fa2515f6@mail.gmail.com> <4AFA7901.3020203@dbateman.org> <4AFA9B1E.7070601@googlemail.com> <9543b3a40911131032s10f117ffyae76c5b2e2f6ffcd@mail.gmail.com> <4AFE5553.6080004@googlemail.com> Message-ID: <4AFF9603.80708@udistrital.edu.co> Spanish traslation of the wiki started at 14/11/2009. Main Page, preface and section 1 of the manual. Thanks. From godfrey at isl.stanford.edu Sun Nov 15 04:56:52 2009 From: godfrey at isl.stanford.edu (Michael D. Godfrey) Date: Sun, 15 Nov 2009 11:56:52 +0100 Subject: openGL printing In-Reply-To: <420fb9e60911141211i652c5e4n6ffaa11027b7bb55@mail.gmail.com> References: <4AFD3DF1.9030603@isl.stanford.edu> <420fb9e60911141211i652c5e4n6ffaa11027b7bb55@mail.gmail.com> Message-ID: <4AFFDE74.4040105@isl.stanford.edu> On 11/14/09 9:11 PM, Shai Ayal wrote: > Note - the on-screen fonts and the postscript fonts are not > necessarily identical, so the result might not look so good depending > on the available fonts on your system .... > I am aware of this. There is always work to be done on font handling... In any case, the label positioning fix seems just right to me. Thanks again! Michael p.s: to John, I vote for committing this changeset. From michael.goffioul at gmail.com Sun Nov 15 07:10:25 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Sun, 15 Nov 2009 13:10:25 +0000 Subject: gnulib and automake In-Reply-To: <128f38bd0911140726v491e8e09y93786ec6a2f6f8cf@mail.gmail.com> References: <19121.21838.419944.184758@segfault.lan> <128f38bd0911121346m3aad0b85q5ebc11420945b0a2@mail.gmail.com> <19196.33882.797708.699014@segfault.lan> <19196.39424.88855.594114@segfault.lan> <128f38bd0911130250s64b3d16blbe75df293ca1ef7@mail.gmail.com> <19197.39757.734427.585503@segfault.lan> <19197.42624.793244.338602@segfault.lan> <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> <19198.10654.902488.247862@segfault.lan> <128f38bd0911140726v491e8e09y93786ec6a2f6f8cf@mail.gmail.com> Message-ID: <128f38bd0911150510k32c4bee2rcf80d32653f3d152@mail.gmail.com> On Sat, Nov 14, 2009 at 3:26 PM, Michael Goffioul wrote: > Indeed, that would be nice it'd just work out of the box, however this > might be a complex task, given the complexity of libtool. Also, it > would have to work with standard MSVC compiler, not the gcc-like > wrapper I'm using. I think what I'll do first is trying to get octave > compilable with MSVC, which is not the case anymore (i'll start > another thread about that), with my own toolchain. Then I'll see if > I can get it working using standard tools. > > Up to now, I could get libcruft compiled. John, Right now, I could get stuff compiled (with some changes, I'll report all of them when I complete compilation) up to liboctinterp. Compilation of oct-files fails at link time. The problem is that OCTINTERP_DLL gets defined when compiling oct-sources, while it should not be the case. I'm not sure what is causing that. Any idea? Michael. From jwe at octave.org Sun Nov 15 09:04:43 2009 From: jwe at octave.org (John W. Eaton) Date: Sun, 15 Nov 2009 10:04:43 -0500 Subject: gnulib and automake In-Reply-To: <128f38bd0911150510k32c4bee2rcf80d32653f3d152@mail.gmail.com> References: <19121.21838.419944.184758@segfault.lan> <128f38bd0911121346m3aad0b85q5ebc11420945b0a2@mail.gmail.com> <19196.33882.797708.699014@segfault.lan> <19196.39424.88855.594114@segfault.lan> <128f38bd0911130250s64b3d16blbe75df293ca1ef7@mail.gmail.com> <19197.39757.734427.585503@segfault.lan> <19197.42624.793244.338602@segfault.lan> <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> <19198.10654.902488.247862@segfault.lan> <128f38bd0911140726v491e8e09y93786ec6a2f6f8cf@mail.gmail.com> <128f38bd0911150510k32c4bee2rcf80d32653f3d152@mail.gmail.com> Message-ID: <19200.6283.851214.564321@segfault.lan> On 15-Nov-2009, Michael Goffioul wrote: | Right now, I could get stuff compiled (with some changes, I'll report | all of them when I complete compilation) up to liboctinterp. Compilation | of oct-files fails at link time. The problem is that OCTINTERP_DLL gets | defined when compiling oct-sources, while it should not be the case. | I'm not sure what is causing that. Any idea? Do you have liboctinterp_la_CPPFLAGS = @OCTINTERP_DLL_DEFS@ $(AM_CPPFLAGS) or do you have @OCTINTERP_DLL_DEFS@ directly in $(AM_CPPFLAGS) in src/Makefile.am? If it is defined in liboctinterp_la_CPPFLAGS, then I think it should apply only to the sources that make up liboctinterp.la. jwe From michael.goffioul at gmail.com Sun Nov 15 09:55:58 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Sun, 15 Nov 2009 15:55:58 +0000 Subject: gnulib and automake In-Reply-To: <19200.6283.851214.564321@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <19196.39424.88855.594114@segfault.lan> <128f38bd0911130250s64b3d16blbe75df293ca1ef7@mail.gmail.com> <19197.39757.734427.585503@segfault.lan> <19197.42624.793244.338602@segfault.lan> <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> <19198.10654.902488.247862@segfault.lan> <128f38bd0911140726v491e8e09y93786ec6a2f6f8cf@mail.gmail.com> <128f38bd0911150510k32c4bee2rcf80d32653f3d152@mail.gmail.com> <19200.6283.851214.564321@segfault.lan> Message-ID: <128f38bd0911150755i1b2388a1nb02cdea23d938539@mail.gmail.com> On Sun, Nov 15, 2009 at 3:04 PM, John W. Eaton wrote: > On 15-Nov-2009, Michael Goffioul wrote: > > | Right now, I could get stuff compiled (with some changes, I'll report > | all of them when I complete compilation) up to liboctinterp. Compilation > | of oct-files fails at link time. The problem is that OCTINTERP_DLL gets > | defined when compiling oct-sources, while it should not be the case. > | I'm not sure what is causing that. Any idea? > > Do you have > > ?liboctinterp_la_CPPFLAGS = @OCTINTERP_DLL_DEFS@ $(AM_CPPFLAGS) > > or do you have @OCTINTERP_DLL_DEFS@ directly in $(AM_CPPFLAGS) in > src/Makefile.am? ?If it is defined in liboctinterp_la_CPPFLAGS, then I > think it should apply only to the sources that make up > liboctinterp.la. I didn't change src/Makefile.am, so it's the same as yours. OCTINTERP_DLL_DEFS is only applied to liboctinterp_la_CPPFLAGS, but the latter gets appended to the compilation of oct files. Here's for instance a piece of my src/Makefile: DLD-FUNCTIONS/liboctinterp_la-__contourc__.lo: DLD-FUNCTIONS/__contourc__.cc # $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(liboctinterp_la_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) -MT DLD-FUNCTIONS/liboctinterp_la-__contourc__.lo -MD -MP -MF DLD-FUNCTIONS/$(DEPDIR)/liboctinterp_la-__contourc__.Tpo -c -o DLD-FUNCTIONS/liboctinterp_la-__contourc__.lo `test -f 'DLD-FUNCTIONS/__contourc__.cc' || echo '$(srcdir)/'`DLD-FUNCTIONS/__contourc__.cc # $(am__mv) DLD-FUNCTIONS/$(DEPDIR)/liboctinterp_la-__contourc__.Tpo DLD-FUNCTIONS/$(DEPDIR)/liboctinterp_la-__contourc__.Plo source='DLD-FUNCTIONS/__contourc__.cc' object='DLD-FUNCTIONS/liboctinterp_la-__contourc__.lo' libtool=yes \ DEPDIR=$(DEPDIR) $(CXXDEPMODE) $(depcomp) \ $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(liboctinterp_la_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) -c -o DLD-FUNCTIONS/liboctinterp_la-__contourc__.lo `test -f 'DLD-FUNCTIONS/__contourc__.cc' || echo '$(srcdir)/'`DLD-FUNCTIONS/__contourc__.cc Michael. From jwe at octave.org Sun Nov 15 11:38:58 2009 From: jwe at octave.org (John W. Eaton) Date: Sun, 15 Nov 2009 12:38:58 -0500 Subject: gnulib and automake In-Reply-To: <128f38bd0911150755i1b2388a1nb02cdea23d938539@mail.gmail.com> References: <19121.21838.419944.184758@segfault.lan> <19196.39424.88855.594114@segfault.lan> <128f38bd0911130250s64b3d16blbe75df293ca1ef7@mail.gmail.com> <19197.39757.734427.585503@segfault.lan> <19197.42624.793244.338602@segfault.lan> <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> <19198.10654.902488.247862@segfault.lan> <128f38bd0911140726v491e8e09y93786ec6a2f6f8cf@mail.gmail.com> <128f38bd0911150510k32c4bee2rcf80d32653f3d152@mail.gmail.com> <19200.6283.851214.564321@segfault.lan> <128f38bd0911150755i1b2388a1nb02cdea23d938539@mail.gmail.com> Message-ID: <19200.15538.278080.289867@segfault.lan> On 15-Nov-2009, Michael Goffioul wrote: | I didn't change src/Makefile.am, so it's the same as yours. OCTINTERP_DLL_DEFS | is only applied to liboctinterp_la_CPPFLAGS, but the latter gets appended to | the compilation of oct files. Here's for instance a piece of my src/Makefile: | | DLD-FUNCTIONS/liboctinterp_la-__contourc__.lo: DLD-FUNCTIONS/__contourc__.cc | # $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) | --mode=compile $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) | $(liboctinterp_la_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) -MT | DLD-FUNCTIONS/liboctinterp_la-__contourc__.lo -MD -MP -MF | DLD-FUNCTIONS/$(DEPDIR)/liboctinterp_la-__contourc__.Tpo -c -o | DLD-FUNCTIONS/liboctinterp_la-__contourc__.lo `test -f | 'DLD-FUNCTIONS/__contourc__.cc' || echo | '$(srcdir)/'`DLD-FUNCTIONS/__contourc__.cc | # $(am__mv) | DLD-FUNCTIONS/$(DEPDIR)/liboctinterp_la-__contourc__.Tpo | DLD-FUNCTIONS/$(DEPDIR)/liboctinterp_la-__contourc__.Plo | source='DLD-FUNCTIONS/__contourc__.cc' | object='DLD-FUNCTIONS/liboctinterp_la-__contourc__.lo' libtool=yes \ | DEPDIR=$(DEPDIR) $(CXXDEPMODE) $(depcomp) \ | $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) | --mode=compile $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) | $(liboctinterp_la_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) -c | -o DLD-FUNCTIONS/liboctinterp_la-__contourc__.lo `test -f | 'DLD-FUNCTIONS/__contourc__.cc' || echo | '$(srcdir)/'`DLD-FUNCTIONS/__contourc__.cc OK, automake is not being too smart here. It is generating these rules as if __contourc__ (and other DLD-FUNCTIONS files) are part of liboctinterp when they are not. The relevant part of src/Makefile.am is if AMCOND_ENABLE_DYNAMIC_LINKING DLD_DYNAMIC_SRC = $(DLD_FUNCTIONS_SRC) DLD_STATIC_SRC = OCT_FILES = $(DLD_FUNCTIONS_SRC:.cc=.oct) else DLD_DYNAMIC_SRC = DLD_STATIC_SRC = $(DLD_FUNCTIONS_SRC) OCT_FILES = endif liboctinterp_la_SOURCES = \ $(DIST_SRC) \ $(DLD_STATIC_SRC) \ $(OPERATORS_SRC) \ $(TEMPLATE_INST_SRC) DLD_DYNAMIC_DEF_FILES = $(DLD_DYNAMIC_SRC:.cc=.df) DLD_STATIC_DEF_FILES = $(DLD_STATIC_SRC:.cc=.df) SRC_DEF_FILES := $(shell $(srcdir)/find-defun-files.sh "$(srcdir)" $(DIST_SRC)) DEF_FILES = $(SRC_DEF_FILES) $(DLD_DYNAMIC_DEF_FILES) $(DLD_STATIC_DEF_FILES) The problem persists even if I write this as if AMCOND_ENABLE_DYNAMIC_LINKING OCT_FILES = $(DLD_FUNCTIONS_SRC:.cc=.oct) liboctinterp_la_SOURCES = \ $(DIST_SRC) \ $(OPERATORS_SRC) \ $(TEMPLATE_INST_SRC) else OCT_FILES = liboctinterp_la_SOURCES = \ $(DIST_SRC) \ $(OPERATORS_SRC) \ $(TEMPLATE_INST_SRC) \ $(DLD_FUNCTIONS_SRC) endif DEF_FILES = \ $(shell $(srcdir)/find-defun-files.sh "$(srcdir)" $(DIST_SRC)) \ $(DLD_FUNCTIONS_SRC:.cc=.df) Since you want to do dynamic linking, try the following change and see if it solves the problem. Then I will try to figure out if this is a bug in automake or just pilot error. jwe -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diffs Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091115/49a88cb7/attachment-0001.ksh From bpabbott at mac.com Sun Nov 15 12:09:04 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sun, 15 Nov 2009 13:09:04 -0500 Subject: build failure - no static version of libiconv.la Message-ID: /bin/sh ../libtool --tag=CXX --mode=link g++-4 -O3 -I/sw/include/freetype2 -I/sw/include -DHAVE_CONFIG_H -mieee-fp -I/usr/X11/include -Wall -W -Wshadow -Wold-style-cast -Wformat -O3 -I/sw/include/freetype2 -I/sw/include -D_THREAD_SAFE -O3 -I/sw/include/freetype2 -I/sw/include -release 3.3.50+ -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 -o liboctinterp.la -rpath /sw/lib/octave-3.3.50+ liboctinterp_la-Cell.lo [?] ../libcruft/libcruft.la -lfftw3 -lfftw3f -lhdf5 -lz -L/usr/X11/lib -lfontconfig -Wl,-framework -Wl,OpenGL -L/usr/X11/lib -lX11 -lreadline -lncurses -framework Accelerate -lm -L/sw/lib -lfreetype -lz -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices -Wl,-framework -Wl,OpenGL /sw/lib/gcc4.4/lib/libgfortran.dylib -lm -L/sw/lib -lfreetype -lz -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices -Wl,-framework -Wl,OpenGL libtool: link: warning: `/sw/lib/gcc4.4/lib//libgfortran.la' seems to be moved libtool: link: warning: `/sw/lib/gcc4.4/lib//libgfortran.la' seems to be moved libtool: link: warning: `/sw/lib/gcc4.4/lib//libgfortran.la' seems to be moved grep: /usr/lib/libiconv.la: No such file or directory /sw/bin/sed: can't read /usr/lib/libiconv.la: No such file or directory libtool: link: `/usr/lib/libiconv.la' is not a valid libtool archive make[3]: *** [liboctinterp.la] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Using Fink a dynamic (shared) version of libiconv is installed on Mac OSX, but no static version. $ ls -l /usr/lib/libiconv* lrwxr-xr-x 1 root wheel 16 2009-08-28 12:08 /usr/lib/libiconv.2.4.0.dylib -> libiconv.2.dylib -rw-r--r-- 1 root wheel 3098592 2009-05-18 19:09 /usr/lib/libiconv.2.dylib lrwxr-xr-x 1 root wheel 20 2009-08-28 12:08 /usr/lib/libiconv.dylib -> libiconv.2.4.0.dylib Can this be fixed during the configure process, or is there a configure option I can specify to resolve this? If not, I can try to have the package maintainer at Fink modify the libiconv package. Ben From bpabbott at mac.com Sun Nov 15 12:28:12 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sun, 15 Nov 2009 13:28:12 -0500 Subject: build failure - no static version of libiconv.la In-Reply-To: References: Message-ID: On Nov 15, 2009, at 1:09 PM, Ben Abbott wrote: > /bin/sh ../libtool --tag=CXX --mode=link g++-4 -O3 -I/sw/include/freetype2 -I/sw/include -DHAVE_CONFIG_H -mieee-fp -I/usr/X11/include -Wall -W -Wshadow -Wold-style-cast -Wformat -O3 -I/sw/include/freetype2 -I/sw/include -D_THREAD_SAFE -O3 -I/sw/include/freetype2 -I/sw/include -release 3.3.50+ -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 -o liboctinterp.la -rpath /sw/lib/octave-3.3.50+ liboctinterp_la-Cell.lo [?] ../libcruft/libcruft.la -lfftw3 -lfftw3f -lhdf5 -lz -L/usr/X11/lib -lfontconfig -Wl,-framework -Wl,OpenGL -L/usr/X11/lib -lX11 -lreadline -lncurses -framework Accelerate -lm -L/sw/lib -lfreetype -lz -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices -Wl,-framework -Wl,OpenGL /sw/lib/gcc4.4/lib/libgfortran.dylib -lm -L/sw/lib -lfreetype -lz -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices -Wl,-framework -Wl,OpenGL > libtool: link: warning: `/sw/lib/gcc4.4/lib//libgfortran.la' seems to be moved > libtool: link: warning: `/sw/lib/gcc4.4/lib//libgfortran.la' seems to be moved > libtool: link: warning: `/sw/lib/gcc4.4/lib//libgfortran.la' seems to be moved > grep: /usr/lib/libiconv.la: No such file or directory > /sw/bin/sed: can't read /usr/lib/libiconv.la: No such file or directory > libtool: link: `/usr/lib/libiconv.la' is not a valid libtool archive > make[3]: *** [liboctinterp.la] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > Using Fink a dynamic (shared) version of libiconv is installed on Mac OSX, but no static version. > > $ ls -l /usr/lib/libiconv* > lrwxr-xr-x 1 root wheel 16 2009-08-28 12:08 /usr/lib/libiconv.2.4.0.dylib -> libiconv.2.dylib > -rw-r--r-- 1 root wheel 3098592 2009-05-18 19:09 /usr/lib/libiconv.2.dylib > lrwxr-xr-x 1 root wheel 20 2009-08-28 12:08 /usr/lib/libiconv.dylib -> libiconv.2.4.0.dylib > > Can this be fixed during the configure process, or is there a configure option I can specify to resolve this? > > If not, I can try to have the package maintainer at Fink modify the libiconv package. > > Ben opps ... posted before engaging my brian :-( My Fink install shows ... $ ls -l /sw/lib/libiconv* -rw-r--r-- 1 root admin 1111236 2009-09-28 20:17 /sw/lib/libiconv.2.4.0.dylib lrwxr-xr-x 1 root admin 20 2009-09-28 20:17 /sw/lib/libiconv.2.dylib -> libiconv.2.4.0.dylib lrwxr-xr-x 1 root admin 20 2009-09-28 20:17 /sw/lib/libiconv.dylib -> libiconv.2.4.0.dylib -rw-r--r-- 1 root admin 804 2009-09-28 20:17 /sw/lib/libiconv.la There *is* a static version, but the build process has missed it. My config.log includes ... Configured with: ../gcc-4.4.2/configure --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib --with-arch=nocona --with-tune=generic --build=i686-apple-darwin10 --host=i686-apple-darwin10 --target=i686-apple-darwin10 I'm quite unfamiliar with autotools, so if these is additional info that would be useful to resolving this, please let me know. Ben From jwe at octave.org Sun Nov 15 12:44:18 2009 From: jwe at octave.org (John W. Eaton) Date: Sun, 15 Nov 2009 13:44:18 -0500 Subject: build failure - no static version of libiconv.la In-Reply-To: References: Message-ID: <19200.19458.719054.21830@segfault.lan> On 15-Nov-2009, Ben Abbott wrote: | On Nov 15, 2009, at 1:09 PM, Ben Abbott wrote: | | > /bin/sh ../libtool --tag=CXX --mode=link g++-4 -O3 -I/sw/include/freetype2 -I/sw/include -DHAVE_CONFIG_H -mieee-fp -I/usr/X11/include -Wall -W -Wshadow -Wold-style-cast -Wformat -O3 -I/sw/include/freetype2 -I/sw/include -D_THREAD_SAFE -O3 -I/sw/include/freetype2 -I/sw/include -release 3.3.50+ -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 -o liboctinterp.la -rpath /sw/lib/octave-3.3.50+ liboctinterp_la-Cell.lo [$,1s&(B] ../libcruft/libcruft.la -lfftw3 -lfftw3f -lhdf5 -lz -L/usr/X11/lib -lfontconfig -Wl,-framework -Wl,OpenGL -L/usr/X11/lib -lX11 -lreadline -lncurses -framework Accelerate -lm -L/sw/lib -lfreetype -lz -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices -Wl,-framework -Wl,OpenGL /sw/lib/gcc4.4/lib/libgfortran.dylib -lm -L/sw/lib -lfreetype -lz -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices -Wl,-framework -Wl,OpenGL | > libtool: link: warning: `/sw/lib/gcc4.4/lib//libgfortran.la' seems to be moved | > libtool: link: warning: `/sw/lib/gcc4.4/lib//libgfortran.la' seems to be moved | > libtool: link: warning: `/sw/lib/gcc4.4/lib//libgfortran.la' seems to be moved | > grep: /usr/lib/libiconv.la: No such file or directory | > /sw/bin/sed: can't read /usr/lib/libiconv.la: No such file or directory | > libtool: link: `/usr/lib/libiconv.la' is not a valid libtool archive | > make[3]: *** [liboctinterp.la] Error 1 | > make[2]: *** [all] Error 2 | > make[1]: *** [all-recursive] Error 1 | > make: *** [all] Error 2 | > | > Using Fink a dynamic (shared) version of libiconv is installed on Mac OSX, but no static version. | > | > $ ls -l /usr/lib/libiconv* | > lrwxr-xr-x 1 root wheel 16 2009-08-28 12:08 /usr/lib/libiconv.2.4.0.dylib -> libiconv.2.dylib | > -rw-r--r-- 1 root wheel 3098592 2009-05-18 19:09 /usr/lib/libiconv.2.dylib | > lrwxr-xr-x 1 root wheel 20 2009-08-28 12:08 /usr/lib/libiconv.dylib -> libiconv.2.4.0.dylib | > | > Can this be fixed during the configure process, or is there a configure option I can specify to resolve this? | > | > If not, I can try to have the package maintainer at Fink modify the libiconv package. | > | > Ben | | opps ... posted before engaging my brian :-( | | My Fink install shows ... | | $ ls -l /sw/lib/libiconv* | -rw-r--r-- 1 root admin 1111236 2009-09-28 20:17 /sw/lib/libiconv.2.4.0.dylib | lrwxr-xr-x 1 root admin 20 2009-09-28 20:17 /sw/lib/libiconv.2.dylib -> libiconv.2.4.0.dylib | lrwxr-xr-x 1 root admin 20 2009-09-28 20:17 /sw/lib/libiconv.dylib -> libiconv.2.4.0.dylib | -rw-r--r-- 1 root admin 804 2009-09-28 20:17 /sw/lib/libiconv.la | | There *is* a static version, but the build process has missed it. My config.log includes ... | | Configured with: ../gcc-4.4.2/configure --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib --with-arch=nocona --with-tune=generic --build=i686-apple-darwin10 --host=i686-apple-darwin10 --target=i686-apple-darwin10 | | I'm quite unfamiliar with autotools, so if these is additional info that would be useful to resolving this, please let me know. What depends on the iconv library? I don't think it is a direct dependency of Octave. jwe From highegg at gmail.com Sun Nov 15 14:21:43 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Sun, 15 Nov 2009 21:21:43 +0100 Subject: Compilation failure, template problems In-Reply-To: <128f38bd0911141308o1d544a74wffc229d7ac188843@mail.gmail.com> References: <128f38bd0911140731q4ab898c2qc52c10534a2ec587@mail.gmail.com> <69d8d540911141252t43aaaecelf4cd6957ef1eabf5@mail.gmail.com> <128f38bd0911141308o1d544a74wffc229d7ac188843@mail.gmail.com> Message-ID: <69d8d540911151221m56b1def2ye0c2ddba4efa1624@mail.gmail.com> On Sat, Nov 14, 2009 at 10:08 PM, Michael Goffioul < michael.goffioul at gmail.com> wrote: > On Sat, Nov 14, 2009 at 8:52 PM, Jaroslav Hajek wrote: > > > > > > On Sat, Nov 14, 2009 at 4:31 PM, Michael Goffioul > > wrote: > >> > >> Hi, > >> > >> Using recent octave archive, MSVC fails to compile liboctave due > >> to a template problems. The error is the following: > >> > >> ../../liboctave/CNDArray.cc(763) : error C2563: mismatch in formal > >> parameter list > >> ../../liboctave/CNDArray.cc(763) : error C2563: mismatch in formal > >> parameter list > >> ../../liboctave/CNDArray.cc(763) : error C2440: 'specialization' : > >> cannot convert from 'overloaded-function' to 'double (__cdecl *const > >> )(Complex)' > >> None of the functions with this name in scope match the target > type > >> ../../liboctave/CNDArray.cc(763) : error C2973: 'do_mx_unary_map' : > >> invalid template argument 'overloaded-function' > >> > >> c:\sources\playground\c\octave-graphics-hg\liboctave\mx-inlines.cc(264) > >> : see declaration of 'do_mx_unary_map' > >> ../../liboctave/CNDArray.cc(763) : error C2668: 'do_mx_unary_map' : > >> ambiguous call to overloaded function > >> > >> > c:\sources\playground\c\octave-graphics-hg\liboctave\mx-inlines.cc(271): > >> could be 'RNDA do_mx_unary_map >> std::abs(const std::complex &)>(const XNDA &)' > >> with > >> [ > >> RNDA=NDArray, > >> XNDA=ComplexNDArray > >> ] > >> > >> > c:\sources\playground\c\octave-graphics-hg\liboctave\mx-inlines.cc(264): > >> or 'RNDA do_mx_unary_map(const > >> XNDA &)' > >> with > >> [ > >> RNDA=NDArray, > >> XNDA=ComplexNDArray > >> ] > >> while trying to match the argument list '(const ComplexNDArray)' > >> > >> Any idea how to work around the problem? This part of the code seems > >> pretty recent. > >> > >> Michael. > > > > I think this should compile - name resolution for template function > > parameters works like for regular parameters. Here the signature is fully > > determined by the previous parameters, so a unique match should be found. > > So I think this is a bug in MSVC. > > Unfortunately, the typical way to pick a specific overload (cast the name > > reference to specific function pointer type) doesn't work in this case, > > because only integral and enum casts are allowed in template params. > Maybe > > just specifying std::abs instead of std::abs would work? > Otherwise, > > I think you'll need to wrap std::abs in a function with unique name and > > substitute that for the template parameter. > > I tried various things, but none of them work. For instance, the following: > > double d_abs(double x) { return std::abs(x); } > > NDArray > NDArray::abs (void) const > { > return do_mx_unary_map (*this); > } > > gives me the following error: > > ../../liboctave/dNDArray.cc(880) : error C2440: 'specialization' : > cannot convert from 'double (__cdecl *)(double)' to 'double (__cdecl > *const )(const double &)' > This conversion requires a reinterpret_cast, a C-style cast or > function-style cast > > Wicked. Why is it picking the wrong version? There are both `fun (T)' and `fun (const T&)' versions defined... > However, I think the problem is more than simply being unable > to resolve the ambiguity. It seems MSVC fails to handle the > situation correctly when dealing with inner types and/or overloaded > functions. For instance, the following works fine: > > double g(double x) { std::cout << "g(double)" << std::endl; return x; } > int g(int x) { std::cout << "g(int)" << std::endl; return x; } > float g(float x) { std::cout << "g(float)" << std::endl; return x; } > > template > T h(T t) > { > return fun(t); > } > > int main(int argc, char **argv) > { > std::cout << h(-10) << std::endl; > return 0; > } > > I also think this is a bug in MSVC. I'm more interested in a > workaround. Otherwise, this will mean the game is over. > What about this? If not, I'm out of ideas... diff --git a/liboctave/mx-inlines.cc b/liboctave/mx-inlines.cc --- a/liboctave/mx-inlines.cc +++ b/liboctave/mx-inlines.cc @@ -259,14 +259,7 @@ // Shortcuts for applying mx_inline_map. -template -inline RNDA -do_mx_unary_map (const XNDA& x) -{ - return do_mx_unary_op (x, mx_inline_map); -} - -template +template ::type)> inline RNDA do_mx_unary_map (const XNDA& x) { -- 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/20091115/37c58be6/attachment-0001.html From michael.goffioul at gmail.com Sun Nov 15 14:58:13 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Sun, 15 Nov 2009 20:58:13 +0000 Subject: gnulib and automake In-Reply-To: <19200.15538.278080.289867@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <19197.39757.734427.585503@segfault.lan> <19197.42624.793244.338602@segfault.lan> <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> <19198.10654.902488.247862@segfault.lan> <128f38bd0911140726v491e8e09y93786ec6a2f6f8cf@mail.gmail.com> <128f38bd0911150510k32c4bee2rcf80d32653f3d152@mail.gmail.com> <19200.6283.851214.564321@segfault.lan> <128f38bd0911150755i1b2388a1nb02cdea23d938539@mail.gmail.com> <19200.15538.278080.289867@segfault.lan> Message-ID: <128f38bd0911151258k7422509al15877ff9e3626f2c@mail.gmail.com> On Sun, Nov 15, 2009 at 5:38 PM, John W. Eaton wrote: > OK, automake is not being too smart here. ?It is generating these > rules as if __contourc__ (and other DLD-FUNCTIONS files) are part of > liboctinterp when they are not. ?The relevant part of src/Makefile.am > is > > ?if AMCOND_ENABLE_DYNAMIC_LINKING > ? ?DLD_DYNAMIC_SRC = $(DLD_FUNCTIONS_SRC) > ? ?DLD_STATIC_SRC = > ? ?OCT_FILES = $(DLD_FUNCTIONS_SRC:.cc=.oct) > ?else > ? ?DLD_DYNAMIC_SRC = > ? ?DLD_STATIC_SRC = $(DLD_FUNCTIONS_SRC) > ? ?OCT_FILES = > ?endif > > ?liboctinterp_la_SOURCES = \ > ? ?$(DIST_SRC) \ > ? ?$(DLD_STATIC_SRC) \ > ? ?$(OPERATORS_SRC) \ > ? ?$(TEMPLATE_INST_SRC) > > ?DLD_DYNAMIC_DEF_FILES = $(DLD_DYNAMIC_SRC:.cc=.df) > ?DLD_STATIC_DEF_FILES = $(DLD_STATIC_SRC:.cc=.df) > > ?SRC_DEF_FILES := $(shell $(srcdir)/find-defun-files.sh "$(srcdir)" $(DIST_SRC)) > > ?DEF_FILES = $(SRC_DEF_FILES) $(DLD_DYNAMIC_DEF_FILES) $(DLD_STATIC_DEF_FILES) > > The problem persists even if I write this as > > ?if AMCOND_ENABLE_DYNAMIC_LINKING > ? ?OCT_FILES = $(DLD_FUNCTIONS_SRC:.cc=.oct) > ? ?liboctinterp_la_SOURCES = \ > ? ? ?$(DIST_SRC) \ > ? ? ?$(OPERATORS_SRC) \ > ? ? ?$(TEMPLATE_INST_SRC) > ?else > ? ?OCT_FILES = > ? ?liboctinterp_la_SOURCES = \ > ? ? ?$(DIST_SRC) \ > ? ? ?$(OPERATORS_SRC) \ > ? ? ?$(TEMPLATE_INST_SRC) \ > ? ? ?$(DLD_FUNCTIONS_SRC) > ?endif > > ?DEF_FILES = \ > ? ?$(shell $(srcdir)/find-defun-files.sh "$(srcdir)" $(DIST_SRC)) \ > ? ?$(DLD_FUNCTIONS_SRC:.cc=.df) > > Since you want to do dynamic linking, try the following change and see > if it solves the problem. ?Then I will try to figure out if this is a > bug in automake or just pilot error. It does not solve the problem, but I think it's one step in the good direction. Now, I don't see libocrinterp_la_CPPFLAGS being used when compiling oct-files, but -DOCTINTERP_DLL is still in the compilation command, through the following path (reverse): - .cc.lo rule - LTCXXCOMPILE - AM_CXXFLAGS - DLL_CXXDEFS Michael. From michael.goffioul at gmail.com Sun Nov 15 15:11:24 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Sun, 15 Nov 2009 21:11:24 +0000 Subject: Compilation failure, template problems In-Reply-To: <69d8d540911151221m56b1def2ye0c2ddba4efa1624@mail.gmail.com> References: <128f38bd0911140731q4ab898c2qc52c10534a2ec587@mail.gmail.com> <69d8d540911141252t43aaaecelf4cd6957ef1eabf5@mail.gmail.com> <128f38bd0911141308o1d544a74wffc229d7ac188843@mail.gmail.com> <69d8d540911151221m56b1def2ye0c2ddba4efa1624@mail.gmail.com> Message-ID: <128f38bd0911151311x7dcf49aeh27d9631e396294c4@mail.gmail.com> On Sun, Nov 15, 2009 at 8:21 PM, Jaroslav Hajek wrote: > Wicked. Why is it picking the wrong version? There are both `fun (T)' and > `fun (const T&)' versions defined... My feeling is that MSVC is not able to handle the function as template parameter, when it's using inner types in the signature. When doing some testing, I could even get stupid error messages like: cannot cast 'double(__cdecl *)(double)' to 'double(__cdecl * const)(double) > What about this? > If not, I'm out of ideas... I'll give it a try, but I'm not very optimistic about the outcome. What does work is to move "fun" out of the template parameters and provide it as a function argument. When I get octave fully compiled, I'll send a patch and leave up to you to decide whether you want use/refactor it. I can live with my own patch. Michael. From highegg at gmail.com Sun Nov 15 15:21:39 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Sun, 15 Nov 2009 22:21:39 +0100 Subject: Compilation failure, template problems In-Reply-To: <128f38bd0911151311x7dcf49aeh27d9631e396294c4@mail.gmail.com> References: <128f38bd0911140731q4ab898c2qc52c10534a2ec587@mail.gmail.com> <69d8d540911141252t43aaaecelf4cd6957ef1eabf5@mail.gmail.com> <128f38bd0911141308o1d544a74wffc229d7ac188843@mail.gmail.com> <69d8d540911151221m56b1def2ye0c2ddba4efa1624@mail.gmail.com> <128f38bd0911151311x7dcf49aeh27d9631e396294c4@mail.gmail.com> Message-ID: <69d8d540911151321h6eef0b1fhdbf681e3c6cf797b@mail.gmail.com> On Sun, Nov 15, 2009 at 10:11 PM, Michael Goffioul < michael.goffioul at gmail.com> wrote: > On Sun, Nov 15, 2009 at 8:21 PM, Jaroslav Hajek wrote: > > Wicked. Why is it picking the wrong version? There are both `fun (T)' and > > `fun (const T&)' versions defined... > > My feeling is that MSVC is not able to handle the function as > template parameter, when it's using inner types in the signature. > When doing some testing, I could even get stupid error messages > like: cannot cast 'double(__cdecl *)(double)' to 'double(__cdecl * > const)(double) > > > What about this? > > If not, I'm out of ideas... > > I'll give it a try, but I'm not very optimistic about the outcome. > What does work is to move "fun" out of the template parameters > and provide it as a function argument. The reason why the function is a template argument is to unify the signature of all unary loops: (size_t, R *, const T*). This makes it possible to define separately "loops" (which do some data transformations using pointers) and "appliers" which apply these functions to Array objects. I'd like to try to keep the loops and appliers as orthogonal as possible. Besides, having a function as a template parameter means that the compiler will almost surely inline the call as direct, improving performance. > When I get octave fully > compiled, I'll send a patch and leave up to you to decide whether > you want use/refactor it. I can live with my own patch. > > Michael. > OK. -- 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/20091115/049659c2/attachment.html From jwe at octave.org Sun Nov 15 20:12:16 2009 From: jwe at octave.org (John W. Eaton) Date: Sun, 15 Nov 2009 21:12:16 -0500 Subject: gnulib and automake In-Reply-To: <128f38bd0911151258k7422509al15877ff9e3626f2c@mail.gmail.com> References: <19121.21838.419944.184758@segfault.lan> <19197.39757.734427.585503@segfault.lan> <19197.42624.793244.338602@segfault.lan> <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> <19198.10654.902488.247862@segfault.lan> <128f38bd0911140726v491e8e09y93786ec6a2f6f8cf@mail.gmail.com> <128f38bd0911150510k32c4bee2rcf80d32653f3d152@mail.gmail.com> <19200.6283.851214.564321@segfault.lan> <128f38bd0911150755i1b2388a1nb02cdea23d938539@mail.gmail.com> <19200.15538.278080.289867@segfault.lan> <128f38bd0911151258k7422509al15877ff9e3626f2c@mail.gmail.com> Message-ID: <19200.46336.629623.63081@segfault.lan> On 15-Nov-2009, Michael Goffioul wrote: | It does not solve the problem, but I think it's one step in the | good direction. Now, I don't see libocrinterp_la_CPPFLAGS being | used when compiling oct-files, but -DOCTINTERP_DLL is still | in the compilation command, through the following path (reverse): | - .cc.lo rule | - LTCXXCOMPILE | - AM_CXXFLAGS | - DLL_CXXDEFS Is the following additional change enough to fix the problem? I know that the handling of these flags needs some more cleanup... jwe -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diffs Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091115/68595470/attachment.ksh From michael.goffioul at gmail.com Mon Nov 16 02:56:44 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Mon, 16 Nov 2009 08:56:44 +0000 Subject: gnulib and automake In-Reply-To: <19200.46336.629623.63081@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> <19198.10654.902488.247862@segfault.lan> <128f38bd0911140726v491e8e09y93786ec6a2f6f8cf@mail.gmail.com> <128f38bd0911150510k32c4bee2rcf80d32653f3d152@mail.gmail.com> <19200.6283.851214.564321@segfault.lan> <128f38bd0911150755i1b2388a1nb02cdea23d938539@mail.gmail.com> <19200.15538.278080.289867@segfault.lan> <128f38bd0911151258k7422509al15877ff9e3626f2c@mail.gmail.com> <19200.46336.629623.63081@segfault.lan> Message-ID: <128f38bd0911160056q43fc4a26y84d2644b83109ad8@mail.gmail.com> Yes, it does. Now I'm able to compile liboctinterp and all oct files properly. Thanks. Michael. 2009/11/16 John W. Eaton : > Is the following additional change enough to fix the problem? > > I know that the handling of these flags needs some more cleanup... > > jwe > > > diff --git a/common.mk b/common.mk > --- a/common.mk > +++ b/common.mk > @@ -109,7 +109,7 @@ > ?CPICFLAG = @CPICFLAG@ > ?XTRA_CFLAGS = @XTRA_CFLAGS@ > ?WARN_CFLAGS = @WARN_CFLAGS@ > -ALL_CFLAGS = $(INCFLAGS) $(DLL_CDEFS) $(DEFS) $(XTRA_CFLAGS) $(WARN_CFLAGS) $(CFLAGS) $(PTHREAD_CFLAGS) > +ALL_CFLAGS = $(INCFLAGS) $(DEFS) $(XTRA_CFLAGS) $(WARN_CFLAGS) $(CFLAGS) $(PTHREAD_CFLAGS) > ?BUG_CFLAGS = $(DEFS) $(XTRA_CFLAGS) $(WARN_CFLAGS) $(CFLAGS) > > ?BUILD_CC = @BUILD_CC@ > @@ -132,7 +132,7 @@ > ?XTRA_CXXFLAGS = @XTRA_CXXFLAGS@ > ?WARN_CXXFLAGS = @WARN_CXXFLAGS@ > ?AM_CXXFLAGS = $(CONFIGURE_CXXFLAGS) \ > - ?$(INCFLAGS) $(DLL_CXXDEFS) $(DEFS) $(XTRA_CXXFLAGS) $(WARN_CXXFLAGS) $(CXXFLAGS) $(PTHREAD_CFLAGS) > + ?$(INCFLAGS) $(DEFS) $(XTRA_CXXFLAGS) $(WARN_CXXFLAGS) $(CXXFLAGS) $(PTHREAD_CFLAGS) > ?BUG_CXXFLAGS = $(DEFS) $(XTRA_CXXFLAGS) $(WARN_CXXFLAGS) $(CXXFLAGS) > > ?BUILD_CXX = @BUILD_CXX@ > > From jwe at octave.org Mon Nov 16 13:11:26 2009 From: jwe at octave.org (John W. Eaton) Date: Mon, 16 Nov 2009 14:11:26 -0500 Subject: gnulib and automake In-Reply-To: <128f38bd0911160056q43fc4a26y84d2644b83109ad8@mail.gmail.com> References: <19121.21838.419944.184758@segfault.lan> <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> <19198.10654.902488.247862@segfault.lan> <128f38bd0911140726v491e8e09y93786ec6a2f6f8cf@mail.gmail.com> <128f38bd0911150510k32c4bee2rcf80d32653f3d152@mail.gmail.com> <19200.6283.851214.564321@segfault.lan> <128f38bd0911150755i1b2388a1nb02cdea23d938539@mail.gmail.com> <19200.15538.278080.289867@segfault.lan> <128f38bd0911151258k7422509al15877ff9e3626f2c@mail.gmail.com> <19200.46336.629623.63081@segfault.lan> <128f38bd0911160056q43fc4a26y84d2644b83109ad8@mail.gmail.com> Message-ID: <19201.41950.112000.942781@segfault.lan> On 16-Nov-2009, Michael Goffioul wrote: | Yes, it does. Now I'm able to compile liboctinterp and | all oct files properly. Thanks. OK, I checked in this change. jwe From marco_atzeri at yahoo.it Mon Nov 16 13:47:30 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Mon, 16 Nov 2009 19:47:30 +0000 (GMT) Subject: WIN32 problem on liboctave/kpse.cc In-Reply-To: <581560.61031.qm@web25505.mail.ukl.yahoo.com> Message-ID: <124458.5837.qm@web25506.mail.ukl.yahoo.com> --- Mer 11/11/09, Marco Atzeri ha scritto: > --- Mer 11/11/09, John W. Eaton > ha scritto: > > > Data: Mercoled? 11 novembre 2009, 16:04 > > On 11-Nov-2009, Michael Goffioul > > wrote: > > > > | On Wed, Nov 11, 2009 at 7:51 AM, Marco Atzeri > > wrote: > > | > Hi, > > | > building on latest > > | > $ hg tip > > | > changeset: ? 9799:cfd0aa788ae1 > > | > tag: ? ? ? ? tip > > | > user: ? ? ? ?John W. Eaton > > | > date: ? ? ? ?Tue Nov 10 23:07:25 2009 > -0500 > > | > summary: ? ? remove reference blas and > lapack > > sources > > | > > > | > this block on liboctave/kpse.cc > > | > is causing win32lib.h (that does not esist) to > be > > | > included in cygwin. > > | > > > | > #if defined(__MINGW32__) > > | > #include > > | > #include > > | > #include > > | > #elif defined(WIN32) > > | > #define __STDC__ 1 > > | > #ifndef _MSC_VER > > | > #include "win32lib.h" > > | > #endif > > | > #endif /* not WIN32 */ > > | > > > | > This fault is really new, so some of the > latest > > changesets > > | > caused it, but kpse.cc seems untouched from > > longtime > > | > so I am bit puzzled. > > | > > | Maybe because WIN32 is now defined under cygwin, > while it > > used > > | to not be defined before. Might be a configure > issue. > > > > What is defining WIN32 on Cygwin systems?? Is GCC > > defining that by > > default now?? Or is it some (unintentional) change > in > > the configure > > script that is doing it? > > > > jwe it seems that WIN32 is defined as on liboctave/lo-utils.h this piece of code is pulling "windows.h", and folllowing all the /usr/include/w32api/* that should not be used for cygwin only program. #ifdef HAVE_LOADLIBRARY_API #include extern "C" OCTAVE_API void * octave_w32_library_search (HINSTANCE handle, const char *name); #undef min #undef max #endif #endif Marco From jwe at octave.org Mon Nov 16 14:32:20 2009 From: jwe at octave.org (John W. Eaton) Date: Mon, 16 Nov 2009 15:32:20 -0500 Subject: WIN32 problem on liboctave/kpse.cc In-Reply-To: <124458.5837.qm@web25506.mail.ukl.yahoo.com> References: <581560.61031.qm@web25505.mail.ukl.yahoo.com> <124458.5837.qm@web25506.mail.ukl.yahoo.com> Message-ID: <19201.46804.32427.92639@segfault.lan> On 16-Nov-2009, Marco Atzeri wrote: | --- Mer 11/11/09, Marco Atzeri ha scritto: | | | > --- Mer 11/11/09, John W. Eaton | > ha scritto: | > | | > > Data: Mercoled? 11 novembre 2009, 16:04 | > > On 11-Nov-2009, Michael Goffioul | > > wrote: | > > | > > | On Wed, Nov 11, 2009 at 7:51 AM, Marco Atzeri | > > wrote: | > > | > Hi, | > > | > building on latest | > > | > $ hg tip | > > | > changeset: ? 9799:cfd0aa788ae1 | > > | > tag: ? ? ? ? tip | > > | > user: ? ? ? ?John W. Eaton | > > | > date: ? ? ? ?Tue Nov 10 23:07:25 2009 | > -0500 | > > | > summary: ? ? remove reference blas and | > lapack | > > sources | > > | > | > > | > this block on liboctave/kpse.cc | > > | > is causing win32lib.h (that does not esist) to | > be | > > | > included in cygwin. | > > | > | > > | > #if defined(__MINGW32__) | > > | > #include | > > | > #include | > > | > #include | > > | > #elif defined(WIN32) | > > | > #define __STDC__ 1 | > > | > #ifndef _MSC_VER | > > | > #include "win32lib.h" | > > | > #endif | > > | > #endif /* not WIN32 */ | > > | > | > > | > This fault is really new, so some of the | > latest | > > changesets | > > | > caused it, but kpse.cc seems untouched from | > > longtime | > > | > so I am bit puzzled. | > > | | > > | Maybe because WIN32 is now defined under cygwin, | > while it | > > used | > > | to not be defined before. Might be a configure | > issue. | > > | > > What is defining WIN32 on Cygwin systems?? Is GCC | > > defining that by | > > default now?? Or is it some (unintentional) change | > in | > > the configure | > > script that is doing it? | > > | > > jwe | | it seems that WIN32 is defined as on | liboctave/lo-utils.h | | this piece of code is pulling "windows.h", and folllowing | all the /usr/include/w32api/* that should not be used | for cygwin only program. | | #ifdef HAVE_LOADLIBRARY_API | #include | extern "C" OCTAVE_API void * octave_w32_library_search (HINSTANCE handle, const char *name); | #undef min | #undef max | #endif | #endif The configure script currently has ### Dynamic linking is now enabled only if we are building shared ### libs and some API for dynamic linking is detected. ## FIXME -- a lot of the following duplicates the functionality of ## code generated by the dlopen option for LT_INIT. LD_CXX='$(CXX)' RDYNAMIC_FLAG= DL_API_MSG="" dlopen_api=false shl_load_api=false loadlibrary_api=false dyld_api=false if $SHARED_LIBS || $ENABLE_DYNAMIC_LINKING; then ## Check for dyld first since OS X can have a non-standard libdl save_LIBS="$LIBS" use_mach_dyld=false AC_ARG_ENABLE(mach-dyld, [AS_HELP_STRING([--enable-mach-dyld], [enable older Mach-O dyld interface])], [if test "x$enableval" = xno; then use_mach_dyld=false; else use_mach_dyld=true; fi], []) if $use_mach_dyld; then AC_CHECK_HEADER(mach-o/dyld.h) if test "$ac_cv_header_mach_o_dyld_h" = yes; then dyld_api=true fi elif test "$dyld_api" = false; then AC_CHECK_LIB(dld, shl_load, [DL_LIBS=-ldld; LIBS="$LIBS $DL_LIBS"]) AC_CHECK_FUNCS(shl_load shl_findsym) if test "$ac_cv_func_shl_load" = yes \ && test "$ac_cv_func_shl_findsym" = yes; then shl_load_api=true else AC_CHECK_LIB(wsock32, LoadLibrary, [ DL_LIBS=-lwsock32; LIBS="$LIBS $DL_LIBS"]) AC_CHECK_FUNCS(LoadLibrary) if test "$ac_cv_func_loadlibrary" = yes; then loadlibrary_api=true else ## With the dlopen option, LT_INIT has already checked for ## dlopen and the -ldl library. So we just look at cache values. if test "x$ac_cv_lib_dl_dlopen" = xyes; then DL_LIBS=-ldl; LIBS="$LIBS $DL_LIBS" fi if test "x$ac_cv_func_dlopen" = xyes \ || test "x$ac_cv_lib_dl_dlopen" = xyes; then AC_CHECK_FUNCS(dlsym dlerror dlclose) if test "x$ac_cv_func_dlclose" = xyes \ && test "x$ac_cv_func_dlerror" = xyes \ && test "x$ac_cv_func_dlsym" = xyes; then dlopen_api=true else case "$canonical_host_type" in i[[3456]]86-*-sco3.2v5*) LD_CXX='LD_RUN_PATH=$LD_RUN_PATH:$(octlibdir) $(CXX)' dlopen_api= ;; esac fi fi fi fi fi LIBS="$save_LIBS" AC_SUBST(DL_LIBS) ## autoconf test for LoadLibrary appears broken. Bypass for cygwin/mingw if $dlopen_api || $shl_load_api || $loadlibrary_api || $dyld_api; then true else case "$canonical_host_type" in *-*-cygwin* | *-*-mingw* | *-*-msdosmsvc) loadlibrary_api=true; ;; esac fi if $dlopen_api; then DL_API_MSG="(dlopen)" AC_DEFINE(HAVE_DLOPEN_API, 1, [Define if your system has dlopen, dlsym, dlerror, and dlclose for dynamic linking]) OCTAVE_CXX_FLAG(-rdynamic, [RDYNAMIC_FLAG=-rdynamic]) elif $shl_load_api; then DL_API_MSG="(shl_load)" AC_DEFINE(HAVE_SHL_LOAD_API, 1, [Define if your system has shl_load and shl_findsym for dynamic linking]) elif $loadlibrary_api; then DL_API_MSG="(LoadLibrary)" AC_DEFINE(HAVE_LOADLIBRARY_API, 1, [Define if your system has LoadLibrary for dynamic linking]) elif $dyld_api; then DL_API_MSG="(dyld)" AC_DEFINE(HAVE_DYLD_API, 1, [Define if your system has dyld for dynamic linking]) fi if $dlopen_api || $shl_load_api || $loadlibrary_api || $dyld_api; then ENABLE_DYNAMIC_LINKING=true AC_DEFINE(ENABLE_DYNAMIC_LINKING, 1, [Define if using dynamic linking]) fi fi What is this doing? Can you find out whether this is detecting the LoadLibrary API with the test AC_CHECK_LIB(wsock32, LoadLibrary, [ DL_LIBS=-lwsock32; LIBS="$LIBS $DL_LIBS"]) AC_CHECK_FUNCS(LoadLibrary) if test "$ac_cv_func_loadlibrary" = yes; then loadlibrary_api=true or whether it is the subsequent ## autoconf test for LoadLibrary appears broken. Bypass for cygwin/mingw if $dlopen_api || $shl_load_api || $loadlibrary_api || $dyld_api; then true else case "$canonical_host_type" in *-*-cygwin* | *-*-mingw* | *-*-msdosmsvc) loadlibrary_api=true; ;; esac fi that is setting loadlibrary_api to true? If it is the latter, then I think the fix is to remove *-*-cygwin* from the case statement. If it is detecting LoadLibrary in the wsock32 library, then maybe we need to switch the order of the tests, or disable the check on Cygwin systems? I think this same information is computed by the LT_INIT macro, so as the comment in configure.ac states, I would ultimately like to just use that information and omit our (apparently duplicate) checks. What do the libtool checks determine on your system? Do they find LoadLibrary or dlopen? If you're not sure, then send me your config.log file and a copy of the messages that go to the terminal when you run the configure script. jwe From thorsten.meyier at gmx.de Mon Nov 16 16:11:53 2009 From: thorsten.meyier at gmx.de (Thorsten Meyer) Date: Mon, 16 Nov 2009 23:11:53 +0100 Subject: build fail on debian Message-ID: I've just tried to build from the current tip (a262b41eaa15) on my debian machine. It's been my first time after the introduction of the gnulib stuff. So I have rerun autogen and configure. The make command succeeded. However, if I try to do ./run-octave afterwards I get the following: thorsten at ole:$ ./run-octave GNU Octave, version 3.3.50+ 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-linux-gnu". 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 (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'. error: `nargout' undefined near line 112 column 7 error: called from: error: /home/thorsten/hg/octave/scripts/set/unique.m at line 112, column 3 error: /home/thorsten/hg/octave/scripts/set/unique.m at line 112, column 3 error: /home/thorsten/hg/octave/scripts/set/unique.m at line 112, column 3 error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! error: scope not found! lt-octave: octave.cc:198: void intern_argv(int, char**): Assertion `symbol_table::at_top_level ()' failed. panic: Aborted -- stopping myself... attempting to save variables to `octave-core'... save to `octave-core' complete Aborted From daniel.sebald at ieee.org Mon Nov 16 22:14:45 2009 From: daniel.sebald at ieee.org (Daniel J Sebald) Date: Mon, 16 Nov 2009 22:14:45 -0600 Subject: Default Plot Characteristics, was Re: [OctDev] zplane.m marker size In-Reply-To: <1258406967.2754.12.camel@Umbriel> References: <1258287171.6324.15.camel@Umbriel> <1258290728.23873.40.camel@hauberg-laptop> <1258293975.6324.22.camel@Umbriel> <4B003DA4.7020501@ieee.org> <1258406967.2754.12.camel@Umbriel> Message-ID: <4B022335.1010803@ieee.org> Simon Schwarz wrote: > In the version of zplane.m the marker size was set explicitly to 2 I > just changed this value to 12 and added a parameter for it. > > I just tried to remove the markersize code - it works also. The markers > are tiny but bigger than before. That's odd. Perhaps a marker size of 2 is some legacy code not updated to fit the new Octave graphics scheme. I just tried id = plot(1:10, 'ro') get(id) and found a marker size of 6. I can't find exactly where the default properties are set searching through the Octave source. Anyone on the maintainers list familiar with graphics, should scripts be setting any absolute sizes anymore? Or just relative (e.g., divide by 2, multiply by 3)? > So maybe it's a good way to add a markersize option. But if it is left > empty use the defaults? Perhaps. However, if a plot is the main result of the zplane() command, the output of the plot command could be returned as the output of zplane(). Then one would have access to all the plot properties, not just marker size. One could use gcf() just as easily too. zplane(); id = gcf(); set(id, 'markersize', 1234) If you want to go with the markersize option in zplane, I'd say pass all unused options onto the plot routine, not just markersize. Dan From highegg at gmail.com Tue Nov 17 02:47:33 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 17 Nov 2009 09:47:33 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911130346y68d8c15eqff0e870b12c9cdfc@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19196.14788.828621.761029@segfault.lan> <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> <19196.31786.833114.405812@segfault.lan> <69d8d540911122227s5d80ecbbkb3b57eae7b9e9aa9@mail.gmail.com> <69d8d540911130346y68d8c15eqff0e870b12c9cdfc@mail.gmail.com> Message-ID: <69d8d540911170047s5e11d83dt2c5351b46bf793ba@mail.gmail.com> On Fri, Nov 13, 2009 at 12:46 PM, Jaroslav Hajek wrote: > > > On Fri, Nov 13, 2009 at 7:27 AM, Jaroslav Hajek wrote: > >> >> >> On Thu, Nov 12, 2009 at 10:20 PM, John W. Eaton wrote: >> >>> On 12-Nov-2009, Jaroslav Hajek wrote: >>> >>> | Sorry, but what is that good for? I still don't get the point. I don't >>> think >>> | Matlab supports this, does it? So what is the motivation? Why does >>> Octave >>> | distinguish signed and unsigned zeros? >>> >>> IEEE 754? We've discussed this before: >>> >>> http://old.nabble.com/Negative-zeros--to844605.html#a845854 >>> >>> jwe >>> >> >> Thanks for the pointer. This thread mainly discusses the existence of >> signed zero which I'm OK with. It's also fine that Octave prints negative >> zeros. But why are complex numbers with negative zero parts excluded from >> automatic narrowing? >> >> I found this message: >> >> http://old.nabble.com/Negative-zeros--to844605.html#a845854 >> >> "I don't see a quick fix for these problems, but the following patch >> does allow you to write >> >> 0*(-i) >> >> to produce (0, -0). >> >> jwe >> " >> >> So it seems you made this change so that 0*(-i) produces a 0 - 0i. I think >> it's a good time to rethink this decision. >> First, you probably overlooked the fact that 0 - 0i is constructible with >> complex (0, -0) - because complex() is the (only) function that bypasses the >> narrowing. So the primary motivation is not strong - these numbers *would >> be* constructible, albeit less conveniently. >> >> On the other hand, there are disadvantages: >> >> 1. It's not Matlab-compatible. Matlab seems to discard all zero imaginary >> parts. >> 2. isreal produces confusing results (isreal (i*i) vs. isreal (-i*i)). >> 3. When numbers like x-0i are excluded from simplifying, you want >> real-only mappers (erf, gamma etc) to still work on them. Currently that >> requires each real-only mapper to have a complex wrapper counterpart. That's >> cumbersome and easy to forget when new mappers are added. >> 4. a' * a is not always real if a is a complex scalar. On the contrary, if >> a is a complex vector, the result *is* always real, as computed by BLAS. >> Should we try to fix BLAS? >> >> The advantages, for recap: >> >> 1. Numbers with negative zero imaginary parts, should they be needed for >> consistency, can be constructed like x + 0*(-i). However, even without the >> discussed behaviour, these numbers could be constructed using complex (), so >> this is pretty weak. >> 2. more? >> >> Unless there are more advantages that I just don't see, it seems to me >> that the losses far outweigh the benefits. So I vote for a change. The >> overall impact is probably minor and won't affect most existing >> computations, because the issues being dealt with are quite subtle anyway. >> >> comments? >> >> > Attached is a proposed changeset. This eliminates the remaining test > failures and gives: > > octave:1> i*i > ans = -1 > octave:2> -i*i > ans = 1 > octave:3> 0*(-i) > ans = -0 > octave:4> complex (0, -0) > ans = 0 - 0i > octave:5> a = complex (1, -0); a'*a > ans = 1 > > regards > > Any further comments? Is it OK if I apply this? -- 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/20091117/9fc39769/attachment-0001.html From michael.goffioul at gmail.com Tue Nov 17 02:56:07 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Tue, 17 Nov 2009 08:56:07 +0000 Subject: gnulib and automake In-Reply-To: <19201.41950.112000.942781@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <128f38bd0911140726v491e8e09y93786ec6a2f6f8cf@mail.gmail.com> <128f38bd0911150510k32c4bee2rcf80d32653f3d152@mail.gmail.com> <19200.6283.851214.564321@segfault.lan> <128f38bd0911150755i1b2388a1nb02cdea23d938539@mail.gmail.com> <19200.15538.278080.289867@segfault.lan> <128f38bd0911151258k7422509al15877ff9e3626f2c@mail.gmail.com> <19200.46336.629623.63081@segfault.lan> <128f38bd0911160056q43fc4a26y84d2644b83109ad8@mail.gmail.com> <19201.41950.112000.942781@segfault.lan> Message-ID: <128f38bd0911170056p553688a6idd453920270678d7@mail.gmail.com> On Mon, Nov 16, 2009 at 7:11 PM, John W. Eaton wrote: > On 16-Nov-2009, Michael Goffioul wrote: > > | Yes, it does. Now I'm able to compile liboctinterp and > | all oct files properly. Thanks. > > OK, I checked in this change. Thanks. There is an additional problem I forgot to mention. In libcruft, mkf77def is applied to all files within libcruft, including C/C++ files. This leads to the extraction of a garbage symbol 's' in cruft.def and MSVC fails to link, because of the undefined reference. Michael. From shaiay at gmail.com Tue Nov 17 03:24:10 2009 From: shaiay at gmail.com (Shai Ayal) Date: Tue, 17 Nov 2009 11:24:10 +0200 Subject: Default Plot Characteristics, was Re: [OctDev] zplane.m marker size In-Reply-To: <4B022335.1010803@ieee.org> References: <1258287171.6324.15.camel@Umbriel> <1258290728.23873.40.camel@hauberg-laptop> <1258293975.6324.22.camel@Umbriel> <4B003DA4.7020501@ieee.org> <1258406967.2754.12.camel@Umbriel> <4B022335.1010803@ieee.org> Message-ID: <420fb9e60911170124m2ac90b3ey7ea4186176a9dbbf@mail.gmail.com> On Tue, Nov 17, 2009 at 6:14 AM, Daniel J Sebald wrote: > Simon Schwarz wrote: >> >> In the version of zplane.m the marker size was set explicitly to 2 I >> just changed this value to 12 and added a parameter for it. >> >> I just tried to remove the markersize code - it works also. The markers >> are tiny but bigger than before. > > That's odd. ?Perhaps a marker size of 2 is some legacy code not updated to > fit the new Octave graphics scheme. ?I just tried > id = plot(1:10, 'ro') > get(id) > > and found a marker size of 6. ?I can't find exactly where the default > properties are set searching through the Octave source. the defaults for properties are set in src/graphics.h.in. search for markersize inside this file and you'll find it. > Anyone on the maintainers list familiar with graphics, should scripts be > setting any absolute sizes anymore? ?Or just relative (e.g., divide by 2, > multiply by 3)? I'm not sure where the default came from, and also I'm not sure that marker size is consistent across backends. for the open-gl based backends (currently fltk) markersize is in points (i.e. 1/72 inch), assuming 72dpi for the screen. There still remains some work to be done ... > > Perhaps. ?However, if a plot is the main result of the zplane() command, the > output of the plot command could be returned as the output of zplane(). > ?Then one would have access to all the plot properties, not just marker > size. ?One could use gcf() just as easily too. > > ?zplane(); > ?id = gcf(); > ?set(id, 'markersize', 1234) This would not work -- markersize is a property of the line object, not the figure object, so you would have to get the handle of the line object into id Shai From jwe at octave.org Tue Nov 17 06:54:14 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 17 Nov 2009 07:54:14 -0500 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911130346y68d8c15eqff0e870b12c9cdfc@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19196.14788.828621.761029@segfault.lan> <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> <19196.31786.833114.405812@segfault.lan> <69d8d540911122227s5d80ecbbkb3b57eae7b9e9aa9@mail.gmail.com> <69d8d540911130346y68d8c15eqff0e870b12c9cdfc@mail.gmail.com> Message-ID: <19202.40182.630322.830837@segfault.lan> On 13-Nov-2009, Jaroslav Hajek wrote: | > So it seems you made this change so that 0*(-i) produces a 0 - 0i. I think | > it's a good time to rethink this decision. | > First, you probably overlooked the fact that 0 - 0i is constructible with | > complex (0, -0) - because complex() is the (only) function that bypasses the | > narrowing. So the primary motivation is not strong - these numbers *would | > be* constructible, albeit less conveniently. It's not only about the construction of -0 imaginary parts. It's also about preserving the result of a computation that generates a -0 imaginary part. | > On the other hand, there are disadvantages: | > | > 1. It's not Matlab-compatible. Matlab seems to discard all zero imaginary | > parts. We do a number of other things that are not completely compatible. | > 2. isreal produces confusing results (isreal (i*i) vs. isreal (-i*i)). | > 3. When numbers like x-0i are excluded from simplifying, you want real-only | > mappers (erf, gamma etc) to still work on them. Currently that requires each | > real-only mapper to have a complex wrapper counterpart. That's cumbersome | > and easy to forget when new mappers are added. | > 4. a' * a is not always real if a is a complex scalar. On the contrary, if | > a is a complex vector, the result *is* always real, as computed by BLAS. | > Should we try to fix BLAS? I'm still not convinced that we should discard -0 when it appears as the imaginary part of a complex number but not -0 when it appears as a real number. I think the real problem here is that we have no pure imaginary type. Perhaps instead of changing the narrowing operation so that it always drops -0 imaginary parts we should have the negation operation for complex (0, y) generate complex (0, -y) instead of (-0, -y). If we had a way of narrowing to pure imaginary, this is the result we would get, isn't it?. Then at least we would not thow away zero imaginary parts in all cases (for example, something like (1+i)/(-inf)). Or would that cause more problems than it solves? jwe From jwe at octave.org Tue Nov 17 07:12:57 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 17 Nov 2009 08:12:57 -0500 Subject: gnulib and automake In-Reply-To: <128f38bd0911170056p553688a6idd453920270678d7@mail.gmail.com> References: <19121.21838.419944.184758@segfault.lan> <128f38bd0911140726v491e8e09y93786ec6a2f6f8cf@mail.gmail.com> <128f38bd0911150510k32c4bee2rcf80d32653f3d152@mail.gmail.com> <19200.6283.851214.564321@segfault.lan> <128f38bd0911150755i1b2388a1nb02cdea23d938539@mail.gmail.com> <19200.15538.278080.289867@segfault.lan> <128f38bd0911151258k7422509al15877ff9e3626f2c@mail.gmail.com> <19200.46336.629623.63081@segfault.lan> <128f38bd0911160056q43fc4a26y84d2644b83109ad8@mail.gmail.com> <19201.41950.112000.942781@segfault.lan> <128f38bd0911170056p553688a6idd453920270678d7@mail.gmail.com> Message-ID: <19202.41305.618958.634300@segfault.lan> On 17-Nov-2009, Michael Goffioul wrote: | On Mon, Nov 16, 2009 at 7:11 PM, John W. Eaton wrote: | > On 16-Nov-2009, Michael Goffioul wrote: | > | > | Yes, it does. Now I'm able to compile liboctinterp and | > | all oct files properly. Thanks. | > | > OK, I checked in this change. | | Thanks. There is an additional problem I forgot to mention. | In libcruft, mkf77def is applied to all files within libcruft, including | C/C++ files. This leads to the extraction of a garbage symbol 's' | in cruft.def and MSVC fails to link, because of the undefined reference. Does this patch fix the problem? http://hg.savannah.gnu.org/hgweb/octave/rev/64270d3ad469 Thanks, jwe From highegg at gmail.com Tue Nov 17 11:26:13 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 17 Nov 2009 18:26:13 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: <19202.40182.630322.830837@segfault.lan> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19196.14788.828621.761029@segfault.lan> <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> <19196.31786.833114.405812@segfault.lan> <69d8d540911122227s5d80ecbbkb3b57eae7b9e9aa9@mail.gmail.com> <69d8d540911130346y68d8c15eqff0e870b12c9cdfc@mail.gmail.com> <19202.40182.630322.830837@segfault.lan> Message-ID: <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> On Tue, Nov 17, 2009 at 1:54 PM, John W. Eaton wrote: > On 13-Nov-2009, Jaroslav Hajek wrote: > > | > So it seems you made this change so that 0*(-i) produces a 0 - 0i. I > think > | > it's a good time to rethink this decision. > | > First, you probably overlooked the fact that 0 - 0i is constructible > with > | > complex (0, -0) - because complex() is the (only) function that > bypasses the > | > narrowing. So the primary motivation is not strong - these numbers > *would > | > be* constructible, albeit less conveniently. > > It's not only about the construction of -0 imaginary parts. It's also > about preserving the result of a computation that generates a -0 > imaginary part. > > Understood. But why is that desirable? Can you demonstrate practical needs? > | > On the other hand, there are disadvantages: > | > > | > 1. It's not Matlab-compatible. Matlab seems to discard all zero > imaginary > | > parts. > > We do a number of other things that are not completely compatible. > > Yes. But I got the impression that you were amongst those who ranked Matlab compatibility quite high. > | > 2. isreal produces confusing results (isreal (i*i) vs. isreal (-i*i)). > | > 3. When numbers like x-0i are excluded from simplifying, you want > real-only > | > mappers (erf, gamma etc) to still work on them. Currently that requires > each > | > real-only mapper to have a complex wrapper counterpart. That's > cumbersome > | > and easy to forget when new mappers are added. > | > 4. a' * a is not always real if a is a complex scalar. On the contrary, > if > | > a is a complex vector, the result *is* always real, as computed by > BLAS. > | > Should we try to fix BLAS? > > I'm still not convinced that we should discard -0 when it appears as > the imaginary part of a complex number but not -0 when it appears as a > real number. > > Why? Signed zero is not a mathematical concept; it's a feature of the IEEE 754 standard. I bet lots of Octave don't know anything about signed zeros. "discard zeros" is surely easier to understand and remember (and also to check) than "discard positive zeros". It's not like converting negative zeros to positive ones - it's about simplifying certain complex numbers to reals. I think the real problem here is that we have no pure imaginary type. > > Yes this has been talked about previously but the potential consistency advantages are still left to be narrowed down and it would surely complicate the existing implementation a lot. > Perhaps instead of changing the narrowing operation so that it always > drops -0 imaginary parts we should have the negation operation for > complex (0, y) generate complex (0, -y) instead of (-0, -y). If we > had a way of narrowing to pure imaginary, this is the result we would > get, isn't it?. Then at least we would not thow away zero imaginary > parts in all cases (for example, something like (1+i)/(-inf)). Or > would that cause more problems than it solves? > > My suggestion is to avoid unnecessary special cases. There is no imaginary type in Octave, there probably never will be, it is neither in Matlab nor any other mathematical software I know of, so behaving "as if" there was one simply lacks sense IMHO. What I suggest is to revert back to the plain stupid: let's do the complex operation as nature (C++/BLAS) intended them to work, and let's automatically simplify purely real complex numbers to true reals. Admittedly, it doesn't work that well if you think about the reals as just an economized special case of complex, but it works best in practice. This strategy also requires the least special casing throughout the code, which I think is a desirable goal if you want to keep the Octave project attractive for future contributors. -- 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/20091117/bd9e5c6e/attachment.html From jwe at octave.org Tue Nov 17 12:21:52 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 17 Nov 2009 13:21:52 -0500 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19196.14788.828621.761029@segfault.lan> <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> <19196.31786.833114.405812@segfault.lan> <69d8d540911122227s5d80ecbbkb3b57eae7b9e9aa9@mail.gmail.com> <69d8d540911130346y68d8c15eqff0e870b12c9cdfc@mail.gmail.com> <19202.40182.630322.830837@segfault.lan> <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> Message-ID: <19202.59840.196494.11389@segfault.lan> On 17-Nov-2009, Jaroslav Hajek wrote: | > It's not only about the construction of -0 imaginary parts. It's also | > about preserving the result of a computation that generates a -0 | > imaginary part. | > | > | Understood. But why is that desirable? Can you demonstrate practical needs? I think 1/(-0) should result in -Inf, not Inf. Hey, that's even Matlab compatible (:-), so it seems that Matlab does store the sign of zero even if it doesn't display it. If you preserve the -0 for real values, then I think you should also preserve them for imaginary values. | > I'm still not convinced that we should discard -0 when it appears as | > the imaginary part of a complex number but not -0 when it appears as a | > real number. | > | > | Why? Signed zero is not a mathematical concept; it's a feature of the IEEE | 754 standard. I bet lots of Octave don't know anything about signed | zeros. Lot's of Octave users don't know much about floating point numbers generally. | I think the real problem here is that we have no pure imaginary type. | > | > | Yes this has been talked about previously but the potential consistency | advantages are still left to be narrowed down and it would surely complicate | the existing implementation a lot. I don't really expect to be able to implement a pure imaginary type without some support from the implementation language (C++). | My suggestion is to avoid unnecessary special cases. Narrowing is already a special case. | What I suggest is to revert back to the plain stupid: let's do the complex | operation as nature (C++/BLAS) intended them to work, and let's | automatically simplify purely real complex numbers to true reals. C++ does not do that. There is no automatic conversion from complex to real. jwe From highegg at gmail.com Tue Nov 17 13:24:00 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 17 Nov 2009 20:24:00 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: <19202.59840.196494.11389@segfault.lan> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19196.14788.828621.761029@segfault.lan> <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> <19196.31786.833114.405812@segfault.lan> <69d8d540911122227s5d80ecbbkb3b57eae7b9e9aa9@mail.gmail.com> <69d8d540911130346y68d8c15eqff0e870b12c9cdfc@mail.gmail.com> <19202.40182.630322.830837@segfault.lan> <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> <19202.59840.196494.11389@segfault.lan> Message-ID: <69d8d540911171124s2ac64df2jfb3cfd579bafdf46@mail.gmail.com> On Tue, Nov 17, 2009 at 7:21 PM, John W. Eaton wrote: > On 17-Nov-2009, Jaroslav Hajek wrote: > > | > It's not only about the construction of -0 imaginary parts. It's also > | > about preserving the result of a computation that generates a -0 > | > imaginary part. > | > > | > > | Understood. But why is that desirable? Can you demonstrate practical > needs? > > I think 1/(-0) should result in -Inf, not Inf. > > Yes. This would be still satisfied. > Hey, that's even Matlab compatible (:-), so it seems that Matlab does > store the sign of zero even if it doesn't display it. > Yes. > If you preserve the -0 for real values, then I think you should also > preserve them for imaginary values. > > This is the "why?" I think you still haven't answered. If we do the auto-narrowing, why do we do it only for positive zeros? Dropping both would actually be more symmetric than the current behavior. > | > I'm still not convinced that we should discard -0 when it appears as > | > the imaginary part of a complex number but not -0 when it appears as a > | > real number. > | > > | > > | Why? Signed zero is not a mathematical concept; it's a feature of the > IEEE > | 754 standard. I bet lots of Octave don't know anything about signed > | zeros. > > Lot's of Octave users don't know much about floating point numbers > generally. > > Yeah, and that's a good reason to keep things simple. > | I think the real problem here is that we have no pure imaginary type. > | > > | > > | Yes this has been talked about previously but the potential consistency > | advantages are still left to be narrowed down and it would surely > complicate > | the existing implementation a lot. > > I don't really expect to be able to implement a pure imaginary type > without some support from the implementation language (C++). > > You mean like more than the general support for user classes? I guess you can safely forget that. Or do you have any information that this feature is planned? > | My suggestion is to avoid unnecessary special cases. > > Narrowing is already a special case. > Yes. But we do want the narrowing, right? And if we want it, why not keep it simple? | What I suggest is to revert back to the plain stupid: let's do the complex | operation as nature (C++/BLAS) intended them to work, and let's | automatically simplify purely real complex numbers to true reals. C++ does not do that. There is no automatic conversion from complex > to real. > C++ is a statically typed language so nothing of that sort is possible (unless polymorphic types are in question). OTOH, in the Matlab/Octave language automatic conversions are common. It's just different language. Do you suggest dropping the narrowing completely as a third alternative? -- 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/20091117/de712cc0/attachment.html From jwe at octave.org Tue Nov 17 14:04:41 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 17 Nov 2009 15:04:41 -0500 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911171124s2ac64df2jfb3cfd579bafdf46@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19196.14788.828621.761029@segfault.lan> <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> <19196.31786.833114.405812@segfault.lan> <69d8d540911122227s5d80ecbbkb3b57eae7b9e9aa9@mail.gmail.com> <69d8d540911130346y68d8c15eqff0e870b12c9cdfc@mail.gmail.com> <19202.40182.630322.830837@segfault.lan> <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> <19202.59840.196494.11389@segfault.lan> <69d8d540911171124s2ac64df2jfb3cfd579bafdf46@mail.gmail.com> Message-ID: <19203.473.700414.872994@segfault.lan> On 17-Nov-2009, Jaroslav Hajek wrote: | > If you preserve the -0 for real values, then I think you should also | > preserve them for imaginary values. | > | > | This is the "why?" I think you still haven't answered. If we do the | auto-narrowing, why do we do it only for positive zeros? Dropping both would | actually be more symmetric than the current behavior. Try this: x = logspace (300, 309, 10)' y = complex (0, -1) ./ x z = log (y) What happens? What should happen? I see a jump in the last value when I think the result should be continuous. Shouldn't the imaginary part always be -pi/2? I think the result I'm seeing is a bug in the Complex log function. It should be using the information provided by the negative zero imaginary part. If you throw away the negative zero imaginary part before it even gets to the log function, then there is no way to fix this problem. jwe From Rolf.Schirmacher at MuellerBBM.de Tue Nov 17 14:20:56 2009 From: Rolf.Schirmacher at MuellerBBM.de (Schirmacher, Rolf) Date: Tue, 17 Nov 2009 21:20:56 +0100 Subject: unary mapper system redesigned + a few questions Message-ID: <2417729F3416D511A27E0090273A963B0291117A@smex01.mbbm.de> John, I highly appreciate your intention and reasoning, but I think for most users the astonishment about not narrowing at -0i while doing so for +0i is much greater than this Inf - inconsistency. I think that the appropriate software for getting infinite limits right might be some CAS like maxima, not a numerical system like octave. So we should try to get these cases as right as possible in octave, but focus more on the practical numerical usage. And for the latter, I think narrowing both imag zeros is preferable. Just my 2 ct, Rolf > -----Original Message----- > From: John W. Eaton [mailto:jwe at octave.org] > Sent: Tuesday, November 17, 2009 9:05 PM > To: Jaroslav Hajek > Cc: octave maintainers list > Subject: Re: unary mapper system redesigned + a few questions > > > On 17-Nov-2009, Jaroslav Hajek wrote: > > | > If you preserve the -0 for real values, then I think you > should also > | > preserve them for imaginary values. > | > > | > > | This is the "why?" I think you still haven't answered. If we do the > | auto-narrowing, why do we do it only for positive zeros? > Dropping both would > | actually be more symmetric than the current behavior. > > Try this: > > x = logspace (300, 309, 10)' > y = complex (0, -1) ./ x > z = log (y) > > What happens? What should happen? I see a jump in the last value > when I think the result should be continuous. Shouldn't the imaginary > part always be -pi/2? > > I think the result I'm seeing is a bug in the Complex log function. > It should be using the information provided by the negative zero > imaginary part. > > If you throw away the negative zero imaginary part before it even gets > to the log function, then there is no way to fix this problem. > > jwe > From highegg at gmail.com Tue Nov 17 14:23:56 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 17 Nov 2009 21:23:56 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: <19203.473.700414.872994@segfault.lan> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> <19196.31786.833114.405812@segfault.lan> <69d8d540911122227s5d80ecbbkb3b57eae7b9e9aa9@mail.gmail.com> <69d8d540911130346y68d8c15eqff0e870b12c9cdfc@mail.gmail.com> <19202.40182.630322.830837@segfault.lan> <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> <19202.59840.196494.11389@segfault.lan> <69d8d540911171124s2ac64df2jfb3cfd579bafdf46@mail.gmail.com> <19203.473.700414.872994@segfault.lan> Message-ID: <69d8d540911171223s66a432f9i9b956c0ad0792572@mail.gmail.com> On Tue, Nov 17, 2009 at 9:04 PM, John W. Eaton wrote: > On 17-Nov-2009, Jaroslav Hajek wrote: > > | > If you preserve the -0 for real values, then I think you should also > | > preserve them for imaginary values. > | > > | > > | This is the "why?" I think you still haven't answered. If we do the > | auto-narrowing, why do we do it only for positive zeros? Dropping both > would > | actually be more symmetric than the current behavior. > > Try this: > > x = logspace (300, 309, 10)' > y = complex (0, -1) ./ x > z = log (y) > > What happens? What should happen? I see a jump in the last value > when I think the result should be continuous. Shouldn't the imaginary > part always be -pi/2? > > No. Quoting the C++ standard: template complex log(const complex& x); Notes: the branch cuts are along the negative real axis. Returns: the complex natural (base e) logarithm of x, in the range of a strip mathematically unbounded along the real axis and in the interval [-i times pi, i times pi ] along the imaginary axis. When x is a negative real number, imag(log(x)) is pi. ..end of story. An implementation is not required to distinguish the sign of zero, probably for practical reasons: it's more difficult to implement (requires the signbit check) and it's also usually more difficult to use - in most computations, users don't distinguish signed zeros either, so this would simply mean that the sign of imag(log(x)) is random. > I think the result I'm seeing is a bug in the Complex log function. > It should be using the information provided by the negative zero > imaginary part. > > According to the C++ standard, apparently not. It's certainly not Octave's bug. > If you throw away the negative zero imaginary part before it even gets > to the log function, then there is no way to fix this problem. > Surely there is; just do y = complex (0, -1 ./ x) instead. "complex" skips the narrowing. -- 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/20091117/ab624044/attachment-0001.html From jwe at octave.org Tue Nov 17 14:40:54 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 17 Nov 2009 15:40:54 -0500 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911171223s66a432f9i9b956c0ad0792572@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <69d8d540911121303r193e3b6cmabf491701b111587@mail.gmail.com> <19196.31786.833114.405812@segfault.lan> <69d8d540911122227s5d80ecbbkb3b57eae7b9e9aa9@mail.gmail.com> <69d8d540911130346y68d8c15eqff0e870b12c9cdfc@mail.gmail.com> <19202.40182.630322.830837@segfault.lan> <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> <19202.59840.196494.11389@segfault.lan> <69d8d540911171124s2ac64df2jfb3cfd579bafdf46@mail.gmail.com> <19203.473.700414.872994@segfault.lan> <69d8d540911171223s66a432f9i9b956c0ad0792572@mail.gmail.com> Message-ID: <19203.2646.775971.108268@segfault.lan> On 17-Nov-2009, Jaroslav Hajek wrote: | No. Quoting the C++ standard: | | template complex log(const complex& x); | Notes: the branch cuts are along the negative real axis. | | Returns: the complex natural (base e) logarithm of x, in the range of a | strip mathematically unbounded | along the real axis and in the interval [-i times pi, i times pi ] | along the imaginary axis. When x is a | negative real number, imag(log(x)) is pi. | | ..end of story. Sorry, but I don't see why (0, -1) / (large representable number) should be considered to have a complex imaginary part yet (0, -1) / inf should not. | > If you throw away the negative zero imaginary part before it even gets | > to the log function, then there is no way to fix this problem. | > | | Surely there is; just do | | y = complex (0, -1 ./ x) | | instead. "complex" skips the narrowing. I don't see any practical way to do this for every computation which might result in an underflow on the negative side of zero. jwe From michael.goffioul at gmail.com Tue Nov 17 16:46:57 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Tue, 17 Nov 2009 22:46:57 +0000 Subject: gnulib and automake In-Reply-To: <19200.15538.278080.289867@segfault.lan> References: <19121.21838.419944.184758@segfault.lan> <19197.39757.734427.585503@segfault.lan> <19197.42624.793244.338602@segfault.lan> <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> <19198.10654.902488.247862@segfault.lan> <128f38bd0911140726v491e8e09y93786ec6a2f6f8cf@mail.gmail.com> <128f38bd0911150510k32c4bee2rcf80d32653f3d152@mail.gmail.com> <19200.6283.851214.564321@segfault.lan> <128f38bd0911150755i1b2388a1nb02cdea23d938539@mail.gmail.com> <19200.15538.278080.289867@segfault.lan> Message-ID: <128f38bd0911171446o298aba5chb1676f6133a0e42b@mail.gmail.com> I see on http://www.octave.org/hg/octave/ that you didn't apply the changes above. Did you find another solution? While continuing with the compilation, I noticed that the proposed changes below prevents to create PKG_ADD correctly in DLD-FUNCTIONS subdir, because DLD_DYNAMIC_DEF_FILES is not defined anymore. Michael. On Sun, Nov 15, 2009 at 5:38 PM, John W. Eaton wrote: > OK, automake is not being too smart here. ?It is generating these > rules as if __contourc__ (and other DLD-FUNCTIONS files) are part of > liboctinterp when they are not. ?The relevant part of src/Makefile.am > is > > ?if AMCOND_ENABLE_DYNAMIC_LINKING > ? ?DLD_DYNAMIC_SRC = $(DLD_FUNCTIONS_SRC) > ? ?DLD_STATIC_SRC = > ? ?OCT_FILES = $(DLD_FUNCTIONS_SRC:.cc=.oct) > ?else > ? ?DLD_DYNAMIC_SRC = > ? ?DLD_STATIC_SRC = $(DLD_FUNCTIONS_SRC) > ? ?OCT_FILES = > ?endif > > ?liboctinterp_la_SOURCES = \ > ? ?$(DIST_SRC) \ > ? ?$(DLD_STATIC_SRC) \ > ? ?$(OPERATORS_SRC) \ > ? ?$(TEMPLATE_INST_SRC) > > ?DLD_DYNAMIC_DEF_FILES = $(DLD_DYNAMIC_SRC:.cc=.df) > ?DLD_STATIC_DEF_FILES = $(DLD_STATIC_SRC:.cc=.df) > > ?SRC_DEF_FILES := $(shell $(srcdir)/find-defun-files.sh "$(srcdir)" $(DIST_SRC)) > > ?DEF_FILES = $(SRC_DEF_FILES) $(DLD_DYNAMIC_DEF_FILES) $(DLD_STATIC_DEF_FILES) > > The problem persists even if I write this as > > ?if AMCOND_ENABLE_DYNAMIC_LINKING > ? ?OCT_FILES = $(DLD_FUNCTIONS_SRC:.cc=.oct) > ? ?liboctinterp_la_SOURCES = \ > ? ? ?$(DIST_SRC) \ > ? ? ?$(OPERATORS_SRC) \ > ? ? ?$(TEMPLATE_INST_SRC) > ?else > ? ?OCT_FILES = > ? ?liboctinterp_la_SOURCES = \ > ? ? ?$(DIST_SRC) \ > ? ? ?$(OPERATORS_SRC) \ > ? ? ?$(TEMPLATE_INST_SRC) \ > ? ? ?$(DLD_FUNCTIONS_SRC) > ?endif > > ?DEF_FILES = \ > ? ?$(shell $(srcdir)/find-defun-files.sh "$(srcdir)" $(DIST_SRC)) \ > ? ?$(DLD_FUNCTIONS_SRC:.cc=.df) > > Since you want to do dynamic linking, try the following change and see > if it solves the problem. ?Then I will try to figure out if this is a > bug in automake or just pilot error. > > jwe > > > diff --git a/src/Makefile.am b/src/Makefile.am > --- a/src/Makefile.am > +++ b/src/Makefile.am > @@ -430,28 +430,15 @@ > ?include OPERATORS/module.mk > ?include TEMPLATE-INST/module.mk > > -if AMCOND_ENABLE_DYNAMIC_LINKING > - ?DLD_DYNAMIC_SRC = $(DLD_FUNCTIONS_SRC) > - ?DLD_STATIC_SRC = > - ?OCT_FILES = $(DLD_FUNCTIONS_SRC:.cc=.oct) > -else > - ?DLD_DYNAMIC_SRC = > - ?DLD_STATIC_SRC = $(DLD_FUNCTIONS_SRC) > - ?OCT_FILES = > -endif > - > +OCT_FILES = $(DLD_FUNCTIONS_SRC:.cc=.oct) > ?liboctinterp_la_SOURCES = \ > ? $(DIST_SRC) \ > - ?$(DLD_STATIC_SRC) \ > ? $(OPERATORS_SRC) \ > ? $(TEMPLATE_INST_SRC) > > -DLD_DYNAMIC_DEF_FILES = $(DLD_DYNAMIC_SRC:.cc=.df) > -DLD_STATIC_DEF_FILES = $(DLD_STATIC_SRC:.cc=.df) > - > -SRC_DEF_FILES := $(shell $(srcdir)/find-defun-files.sh "$(srcdir)" $(DIST_SRC)) > - > -DEF_FILES = $(SRC_DEF_FILES) $(DLD_DYNAMIC_DEF_FILES) $(DLD_STATIC_DEF_FILES) > +DEF_FILES = \ > + ?$(shell $(srcdir)/find-defun-files.sh "$(srcdir)" $(DIST_SRC)) \ > + ?$(DLD_FUNCTIONS_SRC:.cc=.df) > > ?if AMCOND_ENABLE_DYNAMIC_LINKING > ? OCTAVE_LIBS = \ > > From jwe at octave.org Tue Nov 17 16:53:34 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 17 Nov 2009 17:53:34 -0500 Subject: gnulib and automake In-Reply-To: <128f38bd0911171446o298aba5chb1676f6133a0e42b@mail.gmail.com> References: <19121.21838.419944.184758@segfault.lan> <19197.39757.734427.585503@segfault.lan> <19197.42624.793244.338602@segfault.lan> <128f38bd0911131221n56404039g86617fe040dce69@mail.gmail.com> <19198.10654.902488.247862@segfault.lan> <128f38bd0911140726v491e8e09y93786ec6a2f6f8cf@mail.gmail.com> <128f38bd0911150510k32c4bee2rcf80d32653f3d152@mail.gmail.com> <19200.6283.851214.564321@segfault.lan> <128f38bd0911150755i1b2388a1nb02cdea23d938539@mail.gmail.com> <19200.15538.278080.289867@segfault.lan> <128f38bd0911171446o298aba5chb1676f6133a0e42b@mail.gmail.com> Message-ID: <19203.10606.956531.287481@segfault.lan> On 17-Nov-2009, Michael Goffioul wrote: | I see on http://www.octave.org/hg/octave/ that you didn't | apply the changes above. No, because it removes the possibility of linking the DLD-FUNCTIONS files together with Octave (i.e., Octave without .oct files). | Did you find another solution? Not yet. I haven't had time to try to debug this problem. | While continuing with the compilation, I noticed that the | proposed changes below prevents to create PKG_ADD | correctly in DLD-FUNCTIONS subdir, because | DLD_DYNAMIC_DEF_FILES is not defined anymore. OK, I'll keep that in mind when looking for a solution that will still allow the possibility of linking these files together with Octave or separately as individual .oct files. jwe From daniel.sebald at ieee.org Tue Nov 17 20:14:21 2009 From: daniel.sebald at ieee.org (Daniel J Sebald) Date: Tue, 17 Nov 2009 20:14:21 -0600 Subject: Default Plot Characteristics, was Re: [OctDev] zplane.m marker size In-Reply-To: <420fb9e60911170124m2ac90b3ey7ea4186176a9dbbf@mail.gmail.com> References: <1258287171.6324.15.camel@Umbriel> <1258290728.23873.40.camel@hauberg-laptop> <1258293975.6324.22.camel@Umbriel> <4B003DA4.7020501@ieee.org> <1258406967.2754.12.camel@Umbriel> <4B022335.1010803@ieee.org> <420fb9e60911170124m2ac90b3ey7ea4186176a9dbbf@mail.gmail.com> Message-ID: <4B03587D.4080809@ieee.org> Shai Ayal wrote: > On Tue, Nov 17, 2009 at 6:14 AM, Daniel J Sebald wrote: > >>Simon Schwarz wrote: >> >>>In the version of zplane.m the marker size was set explicitly to 2 I >>>just changed this value to 12 and added a parameter for it. >>> >>>I just tried to remove the markersize code - it works also. The markers >>>are tiny but bigger than before. >> >>That's odd. Perhaps a marker size of 2 is some legacy code not updated to >>fit the new Octave graphics scheme. I just tried >>id = plot(1:10, 'ro') >>get(id) >> >>and found a marker size of 6. I can't find exactly where the default >>properties are set searching through the Octave source. > > > the defaults for properties are set in src/graphics.h.in. search for > markersize inside this file and you'll find it. Oh, OK thanks. I was searching through *.h files. >>Anyone on the maintainers list familiar with graphics, should scripts be >>setting any absolute sizes anymore? Or just relative (e.g., divide by 2, >>multiply by 3)? > > I'm not sure where the default came from, Well, I would think that a markersize default of one makes sense, if it doesn't reflect an absolute measurement system... > and also I'm not sure that > marker size is consistent across backends. for the open-gl based > backends (currently fltk) markersize is in points (i.e. 1/72 inch), > assuming 72dpi for the screen. That is likely where the 6 comes from, i.e., 6/72 in (1/12 in) seems a good default. > There still remains some work to be done ... OK. >>Perhaps. However, if a plot is the main result of the zplane() command, the >>output of the plot command could be returned as the output of zplane(). >> Then one would have access to all the plot properties, not just marker >>size. One could use gcf() just as easily too. >> >> zplane(); >> id = gcf(); >> set(id, 'markersize', 1234) > > This would not work -- markersize is a property of the line object, > not the figure object, so you would have to get the handle of the line > object into id Good point. It would be a little more involved than that. Thanks Shai, Dan From highegg at gmail.com Wed Nov 18 00:35:24 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 18 Nov 2009 07:35:24 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: <19203.2646.775971.108268@segfault.lan> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <69d8d540911122227s5d80ecbbkb3b57eae7b9e9aa9@mail.gmail.com> <69d8d540911130346y68d8c15eqff0e870b12c9cdfc@mail.gmail.com> <19202.40182.630322.830837@segfault.lan> <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> <19202.59840.196494.11389@segfault.lan> <69d8d540911171124s2ac64df2jfb3cfd579bafdf46@mail.gmail.com> <19203.473.700414.872994@segfault.lan> <69d8d540911171223s66a432f9i9b956c0ad0792572@mail.gmail.com> <19203.2646.775971.108268@segfault.lan> Message-ID: <69d8d540911172235j75971314u863b7cd959828940@mail.gmail.com> On Tue, Nov 17, 2009 at 9:40 PM, John W. Eaton wrote: > On 17-Nov-2009, Jaroslav Hajek wrote: > > | No. Quoting the C++ standard: > | > | template complex log(const complex& x); > | Notes: the branch cuts are along the negative real axis. > | > | Returns: the complex natural (base e) logarithm of x, in the range of a > | strip mathematically unbounded > | along the real axis and in the interval [-i times pi, i times pi ] > | along the imaginary axis. When x is a > | negative real number, imag(log(x)) is pi. > | > | ..end of story. > > Sorry, but I don't see why > > (0, -1) / (large representable number) > > should be considered to have a complex imaginary part yet > > (0, -1) / inf > > should not. > > This is what Octave does for (0, 1), so substitute in (0, 1) and use the same reason. > | > If you throw away the negative zero imaginary part before it even gets > | > to the log function, then there is no way to fix this problem. > | > > | > | Surely there is; just do > | > | y = complex (0, -1 ./ x) > | > | instead. "complex" skips the narrowing. > > I don't see any practical way to do this for every computation which > might result in an underflow on the negative side of zero. > > I seriously doubt you need this done for every computation. In fact I'm interested if you have any real-life script that starts producing wrong results after the discussed patch is applied. -- 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/20091118/644d2166/attachment.html From storrsjm at email.uc.edu Wed Nov 18 01:42:30 2009 From: storrsjm at email.uc.edu (Judd Storrs) Date: Wed, 18 Nov 2009 02:42:30 -0500 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911172235j75971314u863b7cd959828940@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <69d8d540911130346y68d8c15eqff0e870b12c9cdfc@mail.gmail.com> <19202.40182.630322.830837@segfault.lan> <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> <19202.59840.196494.11389@segfault.lan> <69d8d540911171124s2ac64df2jfb3cfd579bafdf46@mail.gmail.com> <19203.473.700414.872994@segfault.lan> <69d8d540911171223s66a432f9i9b956c0ad0792572@mail.gmail.com> <19203.2646.775971.108268@segfault.lan> <69d8d540911172235j75971314u863b7cd959828940@mail.gmail.com> Message-ID: On Wed, Nov 18, 2009 at 1:35 AM, Jaroslav Hajek wrote: > I seriously doubt you need this done for every computation. In fact I'm > interested if you have any real-life script that starts producing wrong > results after the discussed patch is applied. I have a quick question while I'm pondering this to think whether this change would affect what I do. Does this demotion behaviour only happen for scalars or will the type mangling affect matrices? I assume it doesn't affect matrices because it would be a pretty heavy operation to check all elements of a matrix. I guess my response to the isreal() problem was that it was a bug in isreal() not checking the magnitude of the imaginary component. (1,-0) and (1,0) are should be real because the imaginary component is zero. Personally, I prefer to be explicit when a narrowing is expected e.g. use real() when I want it to happen. >From a performance tweaking/optimization point of view, I'm not liking that type conversions become data-driven rather than programmer driven if you know what I mean. Won't it be confusing if some functions runs faster or uses more memory on some input data compared to others? If you're doing something time critical, how do you know if you've found the worst case? It would suck if things crash/fail randomly based on data representation of the input as a result. --judd From jwe at octave.org Wed Nov 18 01:56:31 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 18 Nov 2009 02:56:31 -0500 Subject: unary mapper system redesigned + a few questions In-Reply-To: References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <69d8d540911130346y68d8c15eqff0e870b12c9cdfc@mail.gmail.com> <19202.40182.630322.830837@segfault.lan> <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> <19202.59840.196494.11389@segfault.lan> <69d8d540911171124s2ac64df2jfb3cfd579bafdf46@mail.gmail.com> <19203.473.700414.872994@segfault.lan> <69d8d540911171223s66a432f9i9b956c0ad0792572@mail.gmail.com> <19203.2646.775971.108268@segfault.lan> <69d8d540911172235j75971314u863b7cd959828940@mail.gmail.com> Message-ID: <19203.43183.788464.512790@segfault.lan> On 18-Nov-2009, Judd Storrs wrote: | On Wed, Nov 18, 2009 at 1:35 AM, Jaroslav Hajek wrote: | > I seriously doubt you need this done for every computation. In fact I'm | > interested if you have any real-life script that starts producing wrong | > results after the discussed patch is applied. | | I have a quick question while I'm pondering this to think whether this | change would affect what I do. Does this demotion behaviour only | happen for scalars or will the type mangling affect matrices? I assume | it doesn't affect matrices because it would be a pretty heavy | operation to check all elements of a matrix. | | I guess my response to the isreal() problem was that it was a bug in | isreal() not checking the magnitude of the imaginary component. (1,-0) | and (1,0) are should be real because the imaginary component is zero. | Personally, I prefer to be explicit when a narrowing is expected e.g. | use real() when I want it to happen. | | >From a performance tweaking/optimization point of view, I'm not liking | that type conversions become data-driven rather than programmer driven | if you know what I mean. Won't it be confusing if some functions runs | faster or uses more memory on some input data compared to others? If | you're doing something time critical, how do you know if you've found | the worst case? It would suck if things crash/fail randomly based on | data representation of the input as a result. Octave and Matlab both do this narrowing and it already happens for complex matrices if the complex part is all 0 (just not -0). This is nothing new. The check typically only happens when a value is stored in a variable, not at each intermediate step in a calculation inside some built-in function. I would guess that the check is also not that slow for most real-world data since most real-world complex arrays probably have many imaginary parts that are nonzero. A bad case would be a very large array with a single nonzero imaginary part in the very last element... jwe < From highegg at gmail.com Wed Nov 18 01:59:37 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 18 Nov 2009 08:59:37 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19202.40182.630322.830837@segfault.lan> <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> <19202.59840.196494.11389@segfault.lan> <69d8d540911171124s2ac64df2jfb3cfd579bafdf46@mail.gmail.com> <19203.473.700414.872994@segfault.lan> <69d8d540911171223s66a432f9i9b956c0ad0792572@mail.gmail.com> <19203.2646.775971.108268@segfault.lan> <69d8d540911172235j75971314u863b7cd959828940@mail.gmail.com> Message-ID: <69d8d540911172359y59e7b635w415f6c5ac3d93393@mail.gmail.com> On Wed, Nov 18, 2009 at 8:42 AM, Judd Storrs wrote: > On Wed, Nov 18, 2009 at 1:35 AM, Jaroslav Hajek wrote: > > I seriously doubt you need this done for every computation. In fact I'm > > interested if you have any real-life script that starts producing wrong > > results after the discussed patch is applied. > > I have a quick question while I'm pondering this to think whether this > change would affect what I do. Does this demotion behaviour only > happen for scalars or will the type mangling affect matrices? I assume > it doesn't affect matrices because it would be a pretty heavy > operation to check all elements of a matrix. > > It does affect matrices. Every time a matrix is encapsulated in octave_value, it is scanned for all zero imaginary components (currently, there's an extra check whether the zero is positive). The check is short-circuit, so for genuinely complex matrices usually only a few elements are scanned. > I guess my response to the isreal() problem was that it was a bug in > isreal() not checking the magnitude of the imaginary component. (1,-0) > and (1,0) are should be real because the imaginary component is zero. > In fact, isreal only checks the type of the result, so that you can force a complex number with zero imaginary part using complex(). > Personally, I prefer to be explicit when a narrowing is expected e.g. > use real() when I want it to happen. > > The automatic narrowing is a feature of Matlab. Dropping the narrowing entirely is something that IMHO wants a separate discussion. All that I'm saying is that if the automatic narrowing is done, constraining it to positive zeros makes little sense. > From a performance tweaking/optimization point of view, I'm not liking > that type conversions become data-driven rather than programmer driven > if you know what I mean. I know what you mean. Data-driven conversions are typical in the Matlab/Octave language. > Won't it be confusing if some functions runs > faster or uses more memory on some input data compared to others? This is happening all the time. For example, ranges try to act like row vectors wherever they can; however, in a lot of places they work much faster than the equivalent row vector. Ask yourself if you find that confusing; I don't. You just need to keep in mind that 1:10 and [1:10] are *not* the same thing, and the first one is usually more efficient. If you're doing something time critical, how do you know if you've found > the worst case? It would suck if things crash/fail randomly based on > data representation of the input as a result. > If you're doing something time critical in Octave, you should really understand a bit about how the internals work. There's no way out. -- 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/20091118/3b0f8ce1/attachment.html From jwe at octave.org Wed Nov 18 02:13:27 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 18 Nov 2009 03:13:27 -0500 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911172235j75971314u863b7cd959828940@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <69d8d540911122227s5d80ecbbkb3b57eae7b9e9aa9@mail.gmail.com> <69d8d540911130346y68d8c15eqff0e870b12c9cdfc@mail.gmail.com> <19202.40182.630322.830837@segfault.lan> <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> <19202.59840.196494.11389@segfault.lan> <69d8d540911171124s2ac64df2jfb3cfd579bafdf46@mail.gmail.com> <19203.473.700414.872994@segfault.lan> <69d8d540911171223s66a432f9i9b956c0ad0792572@mail.gmail.com> <19203.2646.775971.108268@segfault.lan> <69d8d540911172235j75971314u863b7cd959828940@mail.gmail.com> Message-ID: <19203.44199.696265.565782@segfault.lan> On 18-Nov-2009, Jaroslav Hajek wrote: | On Tue, Nov 17, 2009 at 9:40 PM, John W. Eaton wrote: | | > On 17-Nov-2009, Jaroslav Hajek wrote: | > | > | No. Quoting the C++ standard: | > | | > | template complex log(const complex& x); | > | Notes: the branch cuts are along the negative real axis. | > | | > | Returns: the complex natural (base e) logarithm of x, in the range of a | > | strip mathematically unbounded | > | along the real axis and in the interval [-i times pi, i times pi ] | > | along the imaginary axis. When x is a | > | negative real number, imag(log(x)) is pi. | > | | > | ..end of story. | > | > Sorry, but I don't see why | > | > (0, -1) / (large representable number) | > | > should be considered to have a complex imaginary part yet | > | > (0, -1) / inf | > | > should not. | > | > | This is what Octave does for (0, 1), so substitute in (0, 1) and use the | same reason. I've thought some more about the log example I gave and I can also now see some justification for the result that the math library produces. I also agree that we will have a lot of potential confusion and trouble if we try to do this operation in a way that is different from what the implementation languages (C++, C, Fortran) compute. That's also a reason for not trying to introduce a pure imaginary type in Octave without having it in the implementation languages, unless we want to rewrite those too (I don't)... Maybe these issues are also arguments against any automatic narrowing from complex to real, since that is also different from what the implementation languages do. At this point I'm not convinced that automatic narrowing from complex to real is a good thing to do. But I don't see that we have much choice about that if we want compatibility with Matlab. I'm certain that people would notice if we never narrowed complex to real. For real values, we should still preserve -0 and print it, correct? And we can still produce complex values with -0 imaginary part, using the complex function (though I guess it will easily be lost on subsequent operations)? OK, then I suppose you should check in the change. If you make this change, then we should probably also rethink what happens in functions like bool ComplexNDArray::all_elements_are_real (void) const { octave_idx_type nel = nelem (); for (octave_idx_type i = 0; i < nel; i++) { double ip = std::imag (elem (i)); if (ip != 0.0 || lo_ieee_signbit (ip)) return false; } return true; } If we are narrowing to real based on the simple check of ip != 0, then shouldn't this function also return true if the imaginary parts of all elements are != 0 and ignore signbit? If so, then I think the only place we would use lo_ieee_signbit is in printing values. jwe From highegg at gmail.com Wed Nov 18 03:09:41 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 18 Nov 2009 10:09:41 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: <19203.44199.696265.565782@segfault.lan> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19202.40182.630322.830837@segfault.lan> <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> <19202.59840.196494.11389@segfault.lan> <69d8d540911171124s2ac64df2jfb3cfd579bafdf46@mail.gmail.com> <19203.473.700414.872994@segfault.lan> <69d8d540911171223s66a432f9i9b956c0ad0792572@mail.gmail.com> <19203.2646.775971.108268@segfault.lan> <69d8d540911172235j75971314u863b7cd959828940@mail.gmail.com> <19203.44199.696265.565782@segfault.lan> Message-ID: <69d8d540911180109x6de6777ehe66e7dd37877dc93@mail.gmail.com> On Wed, Nov 18, 2009 at 9:13 AM, John W. Eaton wrote: > On 18-Nov-2009, Jaroslav Hajek wrote: > > | On Tue, Nov 17, 2009 at 9:40 PM, John W. Eaton wrote: > | > | > On 17-Nov-2009, Jaroslav Hajek wrote: > | > > | > | No. Quoting the C++ standard: > | > | > | > | template complex log(const complex& x); > | > | Notes: the branch cuts are along the negative real axis. > | > | > | > | Returns: the complex natural (base e) logarithm of x, in the range > of a > | > | strip mathematically unbounded > | > | along the real axis and in the interval [-i times pi, i times pi > ] > | > | along the imaginary axis. When x is a > | > | negative real number, imag(log(x)) is pi. > | > | > | > | ..end of story. > | > > | > Sorry, but I don't see why > | > > | > (0, -1) / (large representable number) > | > > | > should be considered to have a complex imaginary part yet > | > > | > (0, -1) / inf > | > > | > should not. > | > > | > > | This is what Octave does for (0, 1), so substitute in (0, 1) and use the > | same reason. > > I've thought some more about the log example I gave and I can also now > see some justification for the result that the math library produces. > I think this is general: you'll often want a different result from some operation because it is employed in a more complex computation that puts some corner cases into a different perspective. You simply need to figure out a way to force your logic upon the result. I think the discussion about 0*NaN we had earlier this year is similar. > I also agree that we will have a lot of potential confusion and > trouble if we try to do this operation in a way that is different from > what the implementation languages (C++, C, Fortran) compute. That's > also a reason for not trying to introduce a pure imaginary type in > Octave without having it in the implementation languages, unless we > want to rewrite those too (I don't)... > > Maybe these issues are also arguments against any automatic narrowing > from complex to real, since that is also different from what the > implementation languages do. At this point I'm not convinced that > automatic narrowing from complex to real is a good thing to do. It may be confusing and cause problems in some cases, but it has its practical merits. In the Matlab/Octave language, automatic data-driven conversions are just the way of life. > But I > don't see that we have much choice about that if we want compatibility > with Matlab. I'm certain that people would notice if we never > narrowed complex to real. > > Most likely, yes. The question is whether the increased consistency would outweigh the added complexity for user scripts. My personal guess is no, but that's just my feeling. > For real values, we should still preserve -0 and print it, correct? > And we can still produce complex values with -0 imaginary part, using > the complex function (though I guess it will easily be lost on > subsequent operations)? > > Yes, I think so. An extra information (almost) never hurts, and printing the sign of zero is also what C's printf or C++'s ostream do by default. I think we might consider the fact that Matlab hides the sign of zero (while still computing with it) as a (minor) design defect which we should not reproduce. Note that Matlab also outputs complex (0, -0) as "0", while 1 / imag (complex (0, -0)) is -Inf, hiding the potentially useful information about the complex nature of the expression from the user. I think Octave does the better thing here. OK, then I suppose you should check in the change. > > If you make this change, then we should probably also rethink what > happens in functions like > > bool > ComplexNDArray::all_elements_are_real (void) const > { > octave_idx_type nel = nelem (); > > for (octave_idx_type i = 0; i < nel; i++) > { > double ip = std::imag (elem (i)); > > if (ip != 0.0 || lo_ieee_signbit (ip)) > return false; > } > > return true; > } > > If we are narrowing to real based on the simple check of ip != 0, then > shouldn't this function also return true if the imaginary parts of all > elements are != 0 and ignore signbit? If so, then I think the only > place we would use lo_ieee_signbit is in printing values. > Yes, my patch changes these methods. -- 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/20091118/a7317ab5/attachment.html From highegg at gmail.com Wed Nov 18 04:23:42 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 18 Nov 2009 11:23:42 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911180109x6de6777ehe66e7dd37877dc93@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> <19202.59840.196494.11389@segfault.lan> <69d8d540911171124s2ac64df2jfb3cfd579bafdf46@mail.gmail.com> <19203.473.700414.872994@segfault.lan> <69d8d540911171223s66a432f9i9b956c0ad0792572@mail.gmail.com> <19203.2646.775971.108268@segfault.lan> <69d8d540911172235j75971314u863b7cd959828940@mail.gmail.com> <19203.44199.696265.565782@segfault.lan> <69d8d540911180109x6de6777ehe66e7dd37877dc93@mail.gmail.com> Message-ID: <69d8d540911180223n691d18d4kffe26927e4230489@mail.gmail.com> On Wed, Nov 18, 2009 at 10:09 AM, Jaroslav Hajek wrote: > > > On Wed, Nov 18, 2009 at 9:13 AM, John W. Eaton wrote: > >> On 18-Nov-2009, Jaroslav Hajek wrote: >> >> | On Tue, Nov 17, 2009 at 9:40 PM, John W. Eaton wrote: >> | >> | > On 17-Nov-2009, Jaroslav Hajek wrote: >> | > >> | > | No. Quoting the C++ standard: >> | > | >> | > | template complex log(const complex& x); >> | > | Notes: the branch cuts are along the negative real axis. >> | > | >> | > | Returns: the complex natural (base e) logarithm of x, in the range >> of a >> | > | strip mathematically unbounded >> | > | along the real axis and in the interval [-i times pi, i times >> pi ] >> | > | along the imaginary axis. When x is a >> | > | negative real number, imag(log(x)) is pi. >> | > | >> | > | ..end of story. >> | > >> | > Sorry, but I don't see why >> | > >> | > (0, -1) / (large representable number) >> | > >> | > should be considered to have a complex imaginary part yet >> | > >> | > (0, -1) / inf >> | > >> | > should not. >> | > >> | > >> | This is what Octave does for (0, 1), so substitute in (0, 1) and use the >> | same reason. >> >> I've thought some more about the log example I gave and I can also now >> see some justification for the result that the math library produces. >> > > I think this is general: you'll often want a different result from some > operation because it is employed in a more complex computation that puts > some corner cases into a different perspective. You simply need to figure > out a way to force your logic upon the result. I think the discussion about > 0*NaN we had earlier this year is similar. > > >> I also agree that we will have a lot of potential confusion and >> trouble if we try to do this operation in a way that is different from >> what the implementation languages (C++, C, Fortran) compute. That's >> also a reason for not trying to introduce a pure imaginary type in >> Octave without having it in the implementation languages, unless we >> want to rewrite those too (I don't)... >> >> Maybe these issues are also arguments against any automatic narrowing >> from complex to real, since that is also different from what the >> implementation languages do. At this point I'm not convinced that >> automatic narrowing from complex to real is a good thing to do. > > > It may be confusing and cause problems in some cases, but it has its > practical merits. In the Matlab/Octave language, automatic data-driven > conversions are just the way of life. > > >> But I >> don't see that we have much choice about that if we want compatibility >> with Matlab. I'm certain that people would notice if we never >> narrowed complex to real. >> >> > Most likely, yes. The question is whether the increased consistency would > outweigh the added complexity for user scripts. My personal guess is no, but > that's just my feeling. > > >> For real values, we should still preserve -0 and print it, correct? >> And we can still produce complex values with -0 imaginary part, using >> the complex function (though I guess it will easily be lost on >> subsequent operations)? >> >> > Yes, I think so. An extra information (almost) never hurts, and printing > the sign of zero is also what C's printf or C++'s ostream do by default. I > think we might consider the fact that Matlab hides the sign of zero (while > still computing with it) as a (minor) design defect which we should not > reproduce. > Note that Matlab also outputs complex (0, -0) as "0", while 1 / imag > (complex (0, -0)) is -Inf, hiding the potentially useful information about > the complex nature of the expression from the user. I think Octave does the > better thing here. > > > OK, then I suppose you should check in the change. >> > I checked it in. The remaining 7 test failures are gone, with no new ones introduced (which is a good sign). I also mentioned the change in NEWS. best regards -- 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/20091118/071242b6/attachment-0001.html From joe.vornehm at gmail.com Wed Nov 18 10:00:46 2009 From: joe.vornehm at gmail.com (Joe Vornehm Jr.) Date: Wed, 18 Nov 2009 11:00:46 -0500 Subject: [OctDev] Default Plot Characteristics, was Re: zplane.m marker size In-Reply-To: <4B03587D.4080809@ieee.org> References: <1258287171.6324.15.camel@Umbriel> <1258290728.23873.40.camel@hauberg-laptop> <1258293975.6324.22.camel@Umbriel> <4B003DA4.7020501@ieee.org> <1258406967.2754.12.camel@Umbriel> <4B022335.1010803@ieee.org> <420fb9e60911170124m2ac90b3ey7ea4186176a9dbbf@mail.gmail.com> <4B03587D.4080809@ieee.org> Message-ID: <82f1d2580911180800x2148fff9rfd12691eeee71e96@mail.gmail.com> On Tue, Nov 17, 2009 at 9:14 PM, Daniel J Sebald wrote: > Shai Ayal wrote: > > On Tue, Nov 17, 2009 at 6:14 AM, Daniel J Sebald > wrote: > > and also I'm not sure that > > marker size is consistent across backends. for the open-gl based > > backends (currently fltk) markersize is in points (i.e. 1/72 inch), > > assuming 72dpi for the screen. > > That is likely where the 6 comes from, i.e., 6/72 in (1/12 in) seems a good > default MATLAB also uses a default marker size of 6 and specifies the marker size in 1/72-inch points. I'm not sure if this was done for MATLAB compatibility but it seems likely. Joe V. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091118/695bda5d/attachment.html From storrsjm at email.uc.edu Wed Nov 18 10:35:12 2009 From: storrsjm at email.uc.edu (Judd Storrs) Date: Wed, 18 Nov 2009 11:35:12 -0500 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911172359y59e7b635w415f6c5ac3d93393@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> <19202.59840.196494.11389@segfault.lan> <69d8d540911171124s2ac64df2jfb3cfd579bafdf46@mail.gmail.com> <19203.473.700414.872994@segfault.lan> <69d8d540911171223s66a432f9i9b956c0ad0792572@mail.gmail.com> <19203.2646.775971.108268@segfault.lan> <69d8d540911172235j75971314u863b7cd959828940@mail.gmail.com> <69d8d540911172359y59e7b635w415f6c5ac3d93393@mail.gmail.com> Message-ID: On Wed, Nov 18, 2009 at 2:59 AM, Jaroslav Hajek wrote: > The automatic narrowing is a feature of Matlab. Dropping the narrowing > entirely is something that IMHO wants a separate discussion. All that I'm > saying is that if the automatic narrowing is done, constraining it to > positive zeros makes little sense. Hmm. I didn't realize this was the case, but in Matlab it isn't really that objectionable because the real and imaginary components are stored separately. e.g. tossing or adding an imaginary component doesn't require copying. In octave they are interleaved thus copies are mandatory? --judd From highegg at gmail.com Wed Nov 18 10:53:09 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Wed, 18 Nov 2009 17:53:09 +0100 Subject: unary mapper system redesigned + a few questions In-Reply-To: References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19202.59840.196494.11389@segfault.lan> <69d8d540911171124s2ac64df2jfb3cfd579bafdf46@mail.gmail.com> <19203.473.700414.872994@segfault.lan> <69d8d540911171223s66a432f9i9b956c0ad0792572@mail.gmail.com> <19203.2646.775971.108268@segfault.lan> <69d8d540911172235j75971314u863b7cd959828940@mail.gmail.com> <69d8d540911172359y59e7b635w415f6c5ac3d93393@mail.gmail.com> Message-ID: <69d8d540911180853k444afbcaie8647aa2e0c7d7ba@mail.gmail.com> On Wed, Nov 18, 2009 at 5:35 PM, Judd Storrs wrote: > On Wed, Nov 18, 2009 at 2:59 AM, Jaroslav Hajek wrote: > > The automatic narrowing is a feature of Matlab. Dropping the narrowing > > entirely is something that IMHO wants a separate discussion. All that I'm > > saying is that if the automatic narrowing is done, constraining it to > > positive zeros makes little sense. > > Hmm. I didn't realize this was the case, but in Matlab it isn't really > that objectionable because the real and imaginary components are > stored separately. e.g. tossing or adding an imaginary component > doesn't require copying. In octave they are interleaved thus copies > are mandatory? > > Yes, if a complex array is to be narrowed, a copy is required.The Matlab storage is more suitable for this particular stuff (maybe it was designed for it). However, Octave's storage is more suitable for many other applications, in particular for matrix division. Automatic narrowing is also plausible as a counterpart to the automatic widening done by some mappers: for instance, sqrt ([1, -1]) gives [1+0i, 0+1i] instead of [1, NaN], so it's nice that [1+0i, 0+1i].^2 gives [1, -1] back. It all depends on the problem at hand, but in general I found the autoconversions useful when one gets used to them a little. -- 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/20091118/00aa1762/attachment.html From jwe at octave.org Wed Nov 18 11:57:13 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 18 Nov 2009 12:57:13 -0500 Subject: unary mapper system redesigned + a few questions In-Reply-To: <69d8d540911180109x6de6777ehe66e7dd37877dc93@mail.gmail.com> References: <69d8d540911120719u1d2c097av8b73967bac9f2245@mail.gmail.com> <19202.40182.630322.830837@segfault.lan> <69d8d540911170926g6818c408qe1038f91274af294@mail.gmail.com> <19202.59840.196494.11389@segfault.lan> <69d8d540911171124s2ac64df2jfb3cfd579bafdf46@mail.gmail.com> <19203.473.700414.872994@segfault.lan> <69d8d540911171223s66a432f9i9b956c0ad0792572@mail.gmail.com> <19203.2646.775971.108268@segfault.lan> <69d8d540911172235j75971314u863b7cd959828940@mail.gmail.com> <19203.44199.696265.565782@segfault.lan> <69d8d540911180109x6de6777ehe66e7dd37877dc93@mail.gmail.com> Message-ID: <19204.13689.532575.129375@segfault.lan> On 18-Nov-2009, Jaroslav Hajek wrote: | > If we are narrowing to real based on the simple check of ip != 0, then | > shouldn't this function also return true if the imaginary parts of all | > elements are != 0 and ignore signbit? If so, then I think the only | > place we would use lo_ieee_signbit is in printing values. | > | | Yes, my patch changes these methods. Thanks. jwe From godfrey at isl.stanford.edu Wed Nov 18 12:35:17 2009 From: godfrey at isl.stanford.edu (Michael D. Godfrey) Date: Wed, 18 Nov 2009 19:35:17 +0100 Subject: Fwd: Minor updates Message-ID: <4B043E65.9080401@isl.stanford.edu> An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091118/10ec3380/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gl2ps_bbox.changeset Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091118/10ec3380/attachment.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: changeset_font_upd Url: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091118/10ec3380/attachment-0001.ksh From bpabbott at mac.com Wed Nov 18 19:22:24 2009 From: bpabbott at mac.com (Ben Abbott) Date: Wed, 18 Nov 2009 20:22:24 -0500 Subject: plot orientation feature; plot filling page In-Reply-To: <9D48700F-D0D1-4453-A015-BDA1FDC6B978@mac.com> References: <26402803.post@talk.nabble.com> <9D48700F-D0D1-4453-A015-BDA1FDC6B978@mac.com> Message-ID: On Nov 18, 2009, at 7:52 AM, Ben Abbott wrote: > On Nov 18, 2009, at 12:37 AM, octaveUser wrote: > >> I'm trying to do something simple, print a file to a certain paper size and >> have the plot fill the whole page. In matlab this is done in the following >> way: >orient tall, will fill a portrait page, >orient ladscape will flip the >> plot 90degrees and fill the page. Octave prints with the plot only filling >> a box in the center of the page with large margins at the top and bottom. >> The plotting to pdf finally works great, it just seems like it would be >> really usefull to have the plot fill the page. I understand I have to >> interact with gnuplot to get this done. This is the number one feature >> request I have, a simple way to make a plot fill a page, and rotate the plot >> and have it fit the page. Was there an easy way to do this I missed. Thanks, >> octave is wonderful. > > Currently Octave's orient() function does not recognize the "tall" option, and the "landscape", "portrait" options do not flip the "papersize" (1x2) vector. So there are both a missing feature and a bug. > > To do what you want, > > # equivalent to "orient tall" > papersize = get (gcf, "papersize"); # presently the paper units must be inches > border = 0.25; > set (gcf, "paperposition", [border, border, (papersize - 2*border)]) > > # To change orientation > orientation = get (gcf, "paperorientation"); > papersize = get (gcf, "papersize"); > paperposition = get (gcf, "paperposition"); > set (gcf, "paperposition", paperposition([2, 1, 4, 3]); > set (gcf, "papersize", papersize ([2, 1]); > set (gcf, "paperorientation", setdiff ({"landscape", "portrait"}, orientation); > > I'll prepare a changeset today. > > Ben Moving to the maintainers list. I've pushed the attached changeset. Jaroslav, this should also go into 3.2.x. Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: changeset.patch Type: application/octet-stream Size: 4217 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091118/8194f057/attachment.obj -------------- next part -------------- From jwe at octave.org Wed Nov 18 20:03:24 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 18 Nov 2009 21:03:24 -0500 Subject: changeset: Allow more relaxed font test In-Reply-To: <4AC67543.606@isl.stanford.edu> References: <4AC67543.606@isl.stanford.edu> Message-ID: <19204.42860.754745.585270@segfault.lan> On 2-Oct-2009, Michael D. Godfrey wrote: | Fedora Linux systems seem to fail the current | font test when suitable fonts are available. This | change results in fonts being found. The reason | for the additional test, which this change comments out, | seems to be unclear. I have left the test in the source | in case someone wants to explore better ways of handling | the font matching. I committed this change. Sorry for the delay. jwe From jwe at octave.org Wed Nov 18 22:14:22 2009 From: jwe at octave.org (John W. Eaton) Date: Wed, 18 Nov 2009 23:14:22 -0500 Subject: openGL printing In-Reply-To: <420fb9e60911141211i652c5e4n6ffaa11027b7bb55@mail.gmail.com> References: <4AFD3DF1.9030603@isl.stanford.edu> <420fb9e60911141211i652c5e4n6ffaa11027b7bb55@mail.gmail.com> Message-ID: <19204.50718.532477.180814@segfault.lan> On 14-Nov-2009, Shai Ayal wrote: | On Fri, Nov 13, 2009 at 1:07 PM, Michael Godfrey | wrote: | > A very minor adjustment of xlabel and ylabel is needed. | > The following example should show the problem: | > octave:1> plot([1:200]) | > octave:2> xlabel('this is xlabel'); | > octave:3> ylabel('this is ylabel'); | > octave:4> title('this is the title'); | > octave:5> print "test01.ps" | > ========================= | > The plot looks just fine with the x and y labels positioned | > correctly. ?However, the PS file has the x and y labels written | > too close to the actual x and y axes so that the text overlaps | > the numeric scale values. | | The attached changeset fixes this issue by computing the bounding box | of the text with the freetype renderer also when printing postscript. | This bounding box is used by the gl-render code to auto compute the | position of the axes labels. | Note - the on-screen fonts and the postscript fonts are not | necessarily identical, so the result might not look so good depending | on the available fonts on your system .... I committed this change. Thanks, jwe From shaiay at gmail.com Thu Nov 19 03:29:09 2009 From: shaiay at gmail.com (Shai Ayal) Date: Thu, 19 Nov 2009 11:29:09 +0200 Subject: missing symbols in tip Message-ID: <420fb9e60911190129o4b3594e0j24cd1c57b523eb1f@mail.gmail.com> perhaps related to libtool and/or the unary mapper changesets? > plot(randn(100,1)) error: deblank: /home/shaia/Download/octave-hg/src/max.oct: undefined symbol: _ZNK19SparseComplexMatrix3maxER6Array2IiEi error: called from: error: /home/shaia/Download/octave-hg/scripts/strings/deblank.m at line 52, column 4 error: /home/shaia/Download/octave-hg/scripts/plot/gnuplot_drawnow.m at line 369, column 8 error: /home/shaia/Download/octave-hg/scripts/plot/gnuplot_drawnow.m at line 144, column 19 error: /home/shaia/Download/octave-hg/scripts/plot/gnuplot_drawnow.m at line 97, column 16 compiled on debian sid, gcc version 4.3.4 (Debian 4.3.4-6), libtool --help output: host-triplet: i486-pc-linux-gnu shell: /bin/bash compiler: gcc compiler flags: -Wall -g -O2 linker: /usr/bin/ld (gnu? yes) libtool: (GNU libtool) 2.2.6 Debian-2.2.6a-4 automake: automake (GNU automake) 1.11 autoconf: autoconf (GNU Autoconf) 2.64 Shai From godfrey at isl.stanford.edu Thu Nov 19 04:00:57 2009 From: godfrey at isl.stanford.edu (Michael Godfrey) Date: Thu, 19 Nov 2009 11:00:57 +0100 Subject: missing symbols in tip In-Reply-To: <420fb9e60911190129o4b3594e0j24cd1c57b523eb1f@mail.gmail.com> References: <420fb9e60911190129o4b3594e0j24cd1c57b523eb1f@mail.gmail.com> Message-ID: <4B051759.6090407@isl.stanford.edu> > > perhaps related to libtool and/or the unary mapper changesets? > > >> > plot(randn(100,1)) >> > error: deblank: /home/shaia/Download/octave-hg/src/max.oct: undefined > symbol: _ZNK19SparseComplexMatrix3maxER6Array2IiEi > error: called from: > error: /home/shaia/Download/octave-hg/scripts/strings/deblank.m at > line 52, column 4 > error: /home/shaia/Download/octave-hg/scripts/plot/gnuplot_drawnow.m > at line 369, column 8 > error: /home/shaia/Download/octave-hg/scripts/plot/gnuplot_drawnow.m > at line 144, column 19 > error: /home/shaia/Download/octave-hg/scripts/plot/gnuplot_drawnow.m > at line 97, column 16 > > compiled on debian sid, gcc version 4.3.4 (Debian 4.3.4-6), > libtool --help output: > host-triplet: i486-pc-linux-gnu > shell: /bin/bash > compiler: gcc > compiler flags: -Wall -g -O2 > linker: /usr/bin/ld (gnu? yes) > libtool: (GNU libtool) 2.2.6 Debian-2.2.6a-4 > automake: automake (GNU automake) 1.11 > autoconf: autoconf (GNU Autoconf) 2.64 > > > Shai > Does not happen using current tip on Fedora 11 x86_64 (tested both gnuplot and fltk) libtool --help: host-triplet: x86_64-unknown-linux-gnu shell: /bin/sh compiler: gcc compiler flags: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC linker: /usr/bin/ld -m elf_x86_64 (gnu? yes) libtool: (GNU libtool) 2.2.6 automake: automake (GNU automake) 1.11 autoconf: autoconf (GNU Autoconf) 2.63 Michael From highegg at gmail.com Thu Nov 19 04:57:46 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Thu, 19 Nov 2009 11:57:46 +0100 Subject: missing symbols in tip In-Reply-To: <420fb9e60911190129o4b3594e0j24cd1c57b523eb1f@mail.gmail.com> References: <420fb9e60911190129o4b3594e0j24cd1c57b523eb1f@mail.gmail.com> Message-ID: <69d8d540911190257y3803b9d2pc9fb5e820517cd82@mail.gmail.com> On Thu, Nov 19, 2009 at 10:29 AM, Shai Ayal wrote: > perhaps related to libtool and/or the unary mapper changesets? > > libtool, probably. nothing of the unary mappers change is used in max and also the error message doesn't refer to any mapper-related symbol. -- 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/20091119/4f9330eb/attachment.html From bpabbott at mac.com Thu Nov 19 07:19:13 2009 From: bpabbott at mac.com (Ben Abbott) Date: Thu, 19 Nov 2009 08:19:13 -0500 Subject: build failure - no static version of libiconv.la In-Reply-To: <19200.19458.719054.21830@segfault.lan> References: <19200.19458.719054.21830@segfault.lan> Message-ID: <0283023D-6CFB-4956-A01D-4C1B4D069BDE@mac.com> On Nov 15, 2009, at 1:44 PM, John W. Eaton wrote: > On 15-Nov-2009, Ben Abbott wrote: > > | On Nov 15, 2009, at 1:09 PM, Ben Abbott wrote: > | > | > /bin/sh ../libtool --tag=CXX --mode=link g++-4 -O3 -I/sw/include/freetype2 -I/sw/include -DHAVE_CONFIG_H -mieee-fp -I/usr/X11/include -Wall -W -Wshadow -Wold-style-cast -Wformat -O3 -I/sw/include/freetype2 -I/sw/include -D_THREAD_SAFE -O3 -I/sw/include/freetype2 -I/sw/include -release 3.3.50+ -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 -o liboctinterp.la -rpath /sw/lib/octave-3.3.50+ liboctinterp_la-Cell.lo [$,1s&] ../libcruft/libcruft.la -lfftw3 -lfftw3f -lhdf5 -lz -L/usr/X11/lib -lfontconfig -Wl,-framework -Wl,OpenGL -L/usr/X11/lib -lX11 -lreadline -lncurses -framework Accelerate -lm -L/sw/lib -lfreetype -lz -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices -Wl,-framework -Wl,OpenGL /sw/lib/gcc4.4/lib/libgfortran.dylib -lm -L/sw/lib -lfreetype -lz -Wl,-framework,CoreServices -Wl,-framework,ApplicationServices -Wl,-framework -Wl,OpenGL > | > libtool: link: warning: `/sw/lib/gcc4.4/lib//libgfortran.la' seems to be moved > | > libtool: link: warning: `/sw/lib/gcc4.4/lib//libgfortran.la' seems to be moved > | > libtool: link: warning: `/sw/lib/gcc4.4/lib//libgfortran.la' seems to be moved > | > grep: /usr/lib/libiconv.la: No such file or directory > | > /sw/bin/sed: can't read /usr/lib/libiconv.la: No such file or directory > | > libtool: link: `/usr/lib/libiconv.la' is not a valid libtool archive > | > make[3]: *** [liboctinterp.la] Error 1 > | > make[2]: *** [all] Error 2 > | > make[1]: *** [all-recursive] Error 1 > | > make: *** [all] Error 2 > | > > | > Using Fink a dynamic (shared) version of libiconv is installed on Mac OSX, but no static version. > | > > | > $ ls -l /usr/lib/libiconv* > | > lrwxr-xr-x 1 root wheel 16 2009-08-28 12:08 /usr/lib/libiconv.2.4.0.dylib -> libiconv.2.dylib > | > -rw-r--r-- 1 root wheel 3098592 2009-05-18 19:09 /usr/lib/libiconv.2.dylib > | > lrwxr-xr-x 1 root wheel 20 2009-08-28 12:08 /usr/lib/libiconv.dylib -> libiconv.2.4.0.dylib > | > > | > Can this be fixed during the configure process, or is there a configure option I can specify to resolve this? > | > > | > If not, I can try to have the package maintainer at Fink modify the libiconv package. > | > > | > Ben > | > | opps ... posted before engaging my brian :-( > | > | My Fink install shows ... > | > | $ ls -l /sw/lib/libiconv* > | -rw-r--r-- 1 root admin 1111236 2009-09-28 20:17 /sw/lib/libiconv.2.4.0.dylib > | lrwxr-xr-x 1 root admin 20 2009-09-28 20:17 /sw/lib/libiconv.2.dylib -> libiconv.2.4.0.dylib > | lrwxr-xr-x 1 root admin 20 2009-09-28 20:17 /sw/lib/libiconv.dylib -> libiconv.2.4.0.dylib > | -rw-r--r-- 1 root admin 804 2009-09-28 20:17 /sw/lib/libiconv.la > | > | There *is* a static version, but the build process has missed it. My config.log includes ... > | > | Configured with: ../gcc-4.4.2/configure --prefix=/sw --prefix=/sw/lib/gcc4.4 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib --with-arch=nocona --with-tune=generic --build=i686-apple-darwin10 --host=i686-apple-darwin10 --target=i686-apple-darwin10 > | > | I'm quite unfamiliar with autotools, so if these is additional info that would be useful to resolving this, please let me know. > > What depends on the iconv library? I don't think it is a direct > dependency of Octave. > > jwe The problem with iconv was due to linking to the wrong static libraries. I'm guessing that using libtool changed things. Once that was fixed, I had other similar library problems. In each case, the resolution was to delete the undesired .la. These duplicates often exist on Mac OSX because Mac OSX has their libs, Fink installs their own, as does Mac Ports. This is complicated further by Mac OSX 10.6. When linking the libs built under 10.5 are not compatible. In any event, I'm now able to build, but I immediately get a "bus error" when octave is run. I'd guess that there is still some library being linked to by mistake. In any event, I thought I'd update this thread. Ben From bpabbott at mac.com Thu Nov 19 09:28:59 2009 From: bpabbott at mac.com (Ben Abbott) Date: Thu, 19 Nov 2009 10:28:59 -0500 Subject: building 3.2.3 but not finding arpack Message-ID: <31C30F04-3731-4026-BE9E-03F14D6AC9A4@mac.com> My configure has the following options. 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' '--with-hdf5' '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 -larpack -lgfortran -lGraphicsMagick -lfltk_gl -lfltk -lpthread' '--with-blas=-framework Accelerate' 'CFLAGS=-g -I /sw/include -O3' 'CXXFLAGS=-g -I /sw/include -O3' --cache-file=/dev/null --srcdir=. checking for a BSD-compatible install... /sw/bin/ginstall -c My arpack lib, which worked with the developers sources until about the time libtool was added, is /sw/lib/libarpack.a Unfortunately, configure does not find it. From config.log ... 1427 configure:19002: checking for F77_FUNC(dseupd,DSEUPD) in -larpack 1428 configure:19045: gcc-4 -o conftest -g -I /sw/include -O3 -g -I/sw/include -I/sw/include/freetype2 -I/sw/lib/flex/include -I/sw/include -L/sw/ lib/fltk-aqua/lib -L/sw/lib/flex/lib -L/sw/lib/gcc4.4/lib/ -L/sw/lib -larpack -lgfortran -lGraphicsMagick -lfltk_gl -lfltk -lpthread conftest .c -larpack /sw/lib/gcc4.4/lib/libgfortran.dylib -lhdf5 -lz -lm >&5 1429 Undefined symbols: 1430 "_dorm2r_", referenced from: 1431 _dseupd_ in libarpack.a(dseupd.o) 1432 _dseupd_ in libarpack.a(dseupd.o) 1433 "_dnrm2_", referenced from: 1434 _dseupd_ in libarpack.a(dseupd.o) 1435 "_dlacpy_", referenced from: 1436 _dseupd_ in libarpack.a(dseupd.o) 1437 "_dger_", referenced from: 1438 _dseupd_ in libarpack.a(dseupd.o) 1439 "_dsteqr_", referenced from: 1440 _dseupd_ in libarpack.a(dseupd.o) 1441 "_dlamch_", referenced from: 1442 _dseupd_ in libarpack.a(dseupd.o) 1443 "_dscal_", referenced from: 1444 _dseupd_ in libarpack.a(dseupd.o) 1445 _dseupd_ in libarpack.a(dseupd.o) 1446 "_dswap_", referenced from: 1447 _dsesrt_ in libarpack.a(dsesrt.o) 1448 _dsesrt_ in libarpack.a(dsesrt.o) 1449 _dsesrt_ in libarpack.a(dsesrt.o) 1450 _dsesrt_ in libarpack.a(dsesrt.o) 1451 _dsgets_ in libarpack.a(dsgets.o) 1452 _dsgets_ in libarpack.a(dsgets.o) 1453 "_dgeqr2_", referenced from: 1454 _dseupd_ in libarpack.a(dseupd.o) 1455 "_dcopy_", referenced from: 1456 _dseupd_ in libarpack.a(dseupd.o) 1457 _dseupd_ in libarpack.a(dseupd.o) 1458 _dseupd_ in libarpack.a(dseupd.o) 1459 _dseupd_ in libarpack.a(dseupd.o) 1460 _dseupd_ in libarpack.a(dseupd.o) 1461 _dseupd_ in libarpack.a(dseupd.o) 1462 _dseupd_ in libarpack.a(dseupd.o) 1463 _dseupd_ in libarpack.a(dseupd.o) 1464 _dseupd_ in libarpack.a(dseupd.o) 1465 _dseupd_ in libarpack.a(dseupd.o) 1466 _dseupd_ in libarpack.a(dseupd.o) 1467 _dseupd_ in libarpack.a(dseupd.o) 1468 _dseupd_ in libarpack.a(dseupd.o) 1469 _dsgets_ in libarpack.a(dsgets.o) 1470 ld: symbol(s) not found Which looks like a blas problem. However, I'm using Apple's implementation, which has been working for me. BLAS libraries: -framework Accelerate Does anyone have some advice? Ben From jwe at octave.org Thu Nov 19 09:51:48 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 19 Nov 2009 10:51:48 -0500 Subject: building 3.2.3 but not finding arpack In-Reply-To: <31C30F04-3731-4026-BE9E-03F14D6AC9A4@mac.com> References: <31C30F04-3731-4026-BE9E-03F14D6AC9A4@mac.com> Message-ID: <19205.27028.781275.224696@segfault.lan> On 19-Nov-2009, Ben Abbott wrote: | My configure has the following options. | | 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' '--with-hdf5' '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 -larpack -lgfortran -lGraphicsMagick -lfltk_gl -lfltk -lpthread' '--with-blas=-framework Accelerate' 'CFLAGS=-g -I /sw/include -O3' 'CXXFLAGS=-g -I /sw/include -O3' --cache-file=/dev/null --srcdir=. | checking for a BSD-compatible install... /sw/bin/ginstall -c | | My arpack lib, which worked with the developers sources until about the time libtool was added, is /sw/lib/libarpack.a | | Unfortunately, configure does not find it. From config.log ... | | 1427 configure:19002: checking for F77_FUNC(dseupd,DSEUPD) in -larpack | 1428 configure:19045: gcc-4 -o conftest -g -I /sw/include -O3 -g -I/sw/include -I/sw/include/freetype2 -I/sw/lib/flex/include -I/sw/include -L/sw/ lib/fltk-aqua/lib -L/sw/lib/flex/lib -L/sw/lib/gcc4.4/lib/ -L/sw/lib -larpack -lgfortran -lGraphicsMagick -lfltk_gl -lfltk -lpthread conftest .c -larpack /sw/lib/gcc4.4/lib/libgfortran.dylib -lhdf5 -lz -lm >&5 The undefined symbols you show are from LAPACK and/or BLAS. I don't see those libraries listed in the above command. The test in configure is save_LIBS="$LIBS" LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS" OCTAVE_CHECK_LIBRARY(arpack, ARPACK, [arpack not found. The eigs function will be disabled.], [], [dseupd], [Fortran 77], [don't use the ARPACK library, disable eigs function]) LIBS="$save_LIBS" so we are putting LAPACK and BLAS libraries in LIBS, then using the library checking macro. Why don't these show up in the command above? On my system, with the current sources I see configure:28523: checking for dseupd in -larpack configure:28530: gfortran -o conftest -O conftest.f -larpack -llapack -lblas -L/usr/lib/gcc/x86_64-linux-gnu/4.3.4 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.4/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.3.4/../../.. -lgfortranbegin -lgfortran -lm -lm -lfreetype -lz -L/usr/X11R6/lib -lGL -lGLU >&5 Yours says checking for F77_FUNC(dseupd,DSEUPD), which seems odd since the F77_FUNC macro is not used in the ARPACK test or the OCTAVE_CHECK_LIBRARY macro from acinclude.m4 I'm not sure why the lines in the configure script (19002 vs 28523). What version of autoconf are you using? I have 2.64. Have you run autogen.sh recently? jwe From jwe at octave.org Thu Nov 19 10:08:45 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 19 Nov 2009 11:08:45 -0500 Subject: missing symbols in tip In-Reply-To: <420fb9e60911190129o4b3594e0j24cd1c57b523eb1f@mail.gmail.com> References: <420fb9e60911190129o4b3594e0j24cd1c57b523eb1f@mail.gmail.com> Message-ID: <19205.28045.38288.609792@segfault.lan> On 19-Nov-2009, Shai Ayal wrote: | perhaps related to libtool and/or the unary mapper changesets? | | > plot(randn(100,1)) | error: deblank: /home/shaia/Download/octave-hg/src/max.oct: undefined This looks wrong if you are using the current sources. The .oct files are now stored in the src/DLD-FUNCTIONS directory as links to the shared libraries created by libtool in the src/DLD-FUNCTIONS/.libs directory. After the transition to libtool and automake, the files generated by the compiler changed significantly. Running "make maintainer-clean" after the transition won't clean up files generated by the previous build system. The simplest fix would probably be to start fresh with a new build tree. jwe From shaiay at gmail.com Thu Nov 19 12:12:34 2009 From: shaiay at gmail.com (Shai Ayal) Date: Thu, 19 Nov 2009 20:12:34 +0200 Subject: missing symbols in tip In-Reply-To: <19205.28045.38288.609792@segfault.lan> References: <420fb9e60911190129o4b3594e0j24cd1c57b523eb1f@mail.gmail.com> <19205.28045.38288.609792@segfault.lan> Message-ID: <420fb9e60911191012m5692cf3cp4da58e42ef07f856@mail.gmail.com> On Thu, Nov 19, 2009 at 6:08 PM, John W. Eaton wrote: > On 19-Nov-2009, Shai Ayal wrote: > > | perhaps related to libtool and/or the unary mapper changesets? > | > | > plot(randn(100,1)) > | error: deblank: /home/shaia/Download/octave-hg/src/max.oct: undefined > > This looks wrong if you are using the current sources. ?The .oct files > are now stored in the src/DLD-FUNCTIONS directory as links to the > shared libraries created by libtool in the src/DLD-FUNCTIONS/.libs > directory. > > After the transition to libtool and automake, the files generated by > the compiler changed significantly. ?Running "make maintainer-clean" > after the transition won't clean up files generated by the previous > build system. ?The simplest fix would probably be to start fresh with > a new build tree. a new build tree made the problem go away. Sorry for the noise Shai From octave at phaselockedsystems.com Thu Nov 19 12:37:46 2009 From: octave at phaselockedsystems.com (Robert T. Short) Date: Thu, 19 Nov 2009 10:37:46 -0800 Subject: Building from scratch under debian. Message-ID: <4B05907A.4020203@phaselockedsystems.com> I have an up-to-date debian distribution. I am trying to build octave from the tip but have not been successful recently. It is probably just something I am missing in the build process - something that has changed recently. So, could somebody please tell me the exact sequence of commands necessary to build octave from a freshly cloned, clean source directory? A link to such a sequence would be just as good of course. Bob From shaiay at gmail.com Thu Nov 19 12:40:24 2009 From: shaiay at gmail.com (Shai Ayal) Date: Thu, 19 Nov 2009 20:40:24 +0200 Subject: Building from scratch under debian. In-Reply-To: <4B05907A.4020203@phaselockedsystems.com> References: <4B05907A.4020203@phaselockedsystems.com> Message-ID: <420fb9e60911191040v4f1017d7g29bafcd0058195a8@mail.gmail.com> On Thu, Nov 19, 2009 at 8:37 PM, Robert T. Short wrote: > I have an up-to-date debian distribution. ?I am trying to build octave from > the tip but have not been successful recently. > > It is probably just something I am missing in the build process - something > that has changed recently. > > So, could somebody please tell me the exact sequence of commands necessary > to build octave from a freshly cloned, clean source directory? ?A link to > such a sequence would be just as good of course. from a clean tree: ./autogen.sh && ./configure && make From bpabbott at mac.com Thu Nov 19 13:22:25 2009 From: bpabbott at mac.com (Ben Abbott) Date: Thu, 19 Nov 2009 14:22:25 -0500 Subject: building 3.2.3 but not finding arpack In-Reply-To: <102533869451646316050226334846051191555-Webmail@me.com> References: <102533869451646316050226334846051191555-Webmail@me.com> Message-ID: <29216629490932046617741810902617041414-Webmail@me.com> On Thursday, November 19, 2009, at 10:51AM, "John W. Eaton" wrote: >On 19-Nov-2009, Ben Abbott wrote: > >| My configure has the following options. >| >| 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' '--with-hdf5' '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 -larpack -lgfortran -lGraphicsMagick -lfltk_gl -lfltk -lpthread' '--with-blas=-framework Accelerate' 'CFLAGS=-g -I /sw/include -O3' 'CXXFLAGS=-g -I /sw/include -O3' --cache-file=/dev/null --srcdir=. >| checking for a BSD-compatible install... /sw/bin/ginstall -c >| >| My arpack lib, which worked with the developers sources until about the time libtool was added, is /sw/lib/libarpack.a >| >| Unfortunately, configure does not find it. From config.log ... >| >| 1427 configure:19002: checking for F77_FUNC(dseupd,DSEUPD) in -larpack >| 1428 configure:19045: gcc-4 -o conftest -g -I /sw/include -O3 -g -I/sw/include -I/sw/include/freetype2 -I/sw/lib/flex/include -I/sw/include -L/sw/ lib/fltk-aqua/lib -L/sw/lib/flex/lib -L/sw/lib/gcc4.4/lib/ -L/sw/lib -larpack -lgfortran -lGraphicsMagick -lfltk_gl -lfltk -lpthread conftest .c -larpack /sw/lib/gcc4.4/lib/libgfortran.dylib -lhdf5 -lz -lm >&5 > >The undefined symbols you show are from LAPACK and/or BLAS. I >don't see those libraries listed in the above command. > >The test in configure is > > save_LIBS="$LIBS" > LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS" > OCTAVE_CHECK_LIBRARY(arpack, ARPACK, > [arpack not found. The eigs function will be disabled.], > [], > [dseupd], > [Fortran 77], [don't use the ARPACK library, disable eigs function]) > LIBS="$save_LIBS" > >so we are putting LAPACK and BLAS libraries in LIBS, then using the >library checking macro. Why don't these show up in the command above? > >On my system, with the current sources I see > > configure:28523: checking for dseupd in -larpack > configure:28530: gfortran -o conftest -O conftest.f -larpack -llapack -lblas -L/usr/lib/gcc/x86_64-linux-gnu/4.3.4 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.4/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.3.4/../../.. -lgfortranbegin -lgfortran -lm -lm -lfreetype -lz -L/usr/X11R6/lib -lGL -lGLU >&5 > >Yours says checking for F77_FUNC(dseupd,DSEUPD), which seems odd since >the F77_FUNC macro is not used in the ARPACK test or the >OCTAVE_CHECK_LIBRARY macro from acinclude.m4 > >I'm not sure why the lines in the configure script (19002 vs 28523). >What version of autoconf are you using? I have 2.64. > >Have you run autogen.sh recently? > >jwe I ran autogen.sh must prior to trying this build. My autoconf is 2.63. The static library business may have something to do with Mac OSX 10.6. Regarding the "Undefined symbols" (i.e. LAPACK and BLAS), I tried building a dyamic (shared) version of arpack. Which produced the same "Undefined symbols" errors. I was able to fix that by adding the "-Wl,-undefined,dynamic_lookup" option below. ( $(FC) $(FFLAGS) -dynamiclib -Wl,-undefined,dynamic_lookup $(OBJS) -o $(ARPACKDYLIB) ) I haven't experimented further, but with the resulting libarpack.dylib in /sw/lib, Octave's configure now finds arpack. ARPACK libraries: -larpack Ben From jwe at octave.org Thu Nov 19 13:34:08 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 19 Nov 2009 14:34:08 -0500 Subject: building 3.2.3 but not finding arpack In-Reply-To: <29216629490932046617741810902617041414-Webmail@me.com> References: <102533869451646316050226334846051191555-Webmail@me.com> <29216629490932046617741810902617041414-Webmail@me.com> Message-ID: <19205.40368.682892.40273@segfault.lan> On 19-Nov-2009, Ben Abbott wrote: | >Yours says checking for F77_FUNC(dseupd,DSEUPD), which seems odd since | >the F77_FUNC macro is not used in the ARPACK test or the | >OCTAVE_CHECK_LIBRARY macro from acinclude.m4 | > | >I'm not sure why the lines in the configure script (19002 vs 28523). | >What version of autoconf are you using? I have 2.64. | > | >Have you run autogen.sh recently? | > | >jwe | | I ran autogen.sh must prior to trying this build. | | My autoconf is 2.63. Are you sure your configure script is up to date? Does it have the lines save_LIBS="$LIBS" LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS" OCTAVE_CHECK_LIBRARY(arpack, ARPACK, [arpack not found. The eigs function will be disabled.], [], [dseupd], [Fortran 77], [don't use the ARPACK library, disable eigs function]) LIBS="$save_LIBS" or something else? If so, where is the "F77_FUNC(dseupd,DSEUPD)" coming from in the config.log message? The reason I suspect an old version of configure.ac is that it used to be save_LIBS="$LIBS" LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS" OCTAVE_CHECK_LIBRARY(arpack, ARPACK, [arpack not found. The eigs function will be disabled.], [], [F77_FUNC(dseupd,DSEUPD)], [], [don't use the ARPACK library, disable eigs function]) LIBS="$save_LIBS" which would account for both the missing LAPACK and BLAS libs and the "F77_FUNC(dseupd,DSEUPD)" name appearing in the checking message. If your configure.ac script really is up to date, then what are the values of LAPACK_LIBS and BLAS_LIBS at this point in the configure script? If they are defined, I didn't see them in the config.log output you posted. jwe From lindnerben at gmx.net Thu Nov 19 13:39:11 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Thu, 19 Nov 2009 20:39:11 +0100 Subject: finally actually using gnulib In-Reply-To: <4AFF17FD.8000008@gmx.net> References: <19198.60584.771475.300423@segfault.lan> <4AFEFF11.1070906@gmx.net> <420fb9e60911141224p3adbee11od4d35824be82779f@mail.gmail.com> <4AFF17FD.8000008@gmx.net> Message-ID: <4B059EDF.5070606@gmx.net> Benjamin Lindner wrote: > > Thanks for this hint. > This is probably the fastest way to get it testing. I am probably missing something trivial or simply doing something stupid. I downloaded a gnulib snapshot, and from a cloned hg repos, with john's patch imported, executed $ ./autogen.sh --gnulib-srcdir=/octmgw32/octave/gnulib generating source lists for liboctave/Makefile... vx-op-inc.mk is unchanged mx-op-inc.mk is unchanged smx-op-inc.mk is unchanged vx-op-src.mk is unchanged mx-op-src.mk is unchanged smx-op-src.mk is unchanged generating doc/interpreter/images.mk... images.mk is unchanged generating src/DLD-FUNCTIONS/module.mk... module.mk is unchanged bootstrapping... ./bootstrap: one of these is required: sha1sum gsha1sum And then the process stops. Any clues? benjamin From bpabbott at mac.com Thu Nov 19 14:13:43 2009 From: bpabbott at mac.com (Ben Abbott) Date: Thu, 19 Nov 2009 15:13:43 -0500 Subject: building 3.2.3 but not finding arpack In-Reply-To: <19205.40368.682892.40273@segfault.lan> References: <102533869451646316050226334846051191555-Webmail@me.com> <29216629490932046617741810902617041414-Webmail@me.com> <19205.40368.682892.40273@segfault.lan> Message-ID: <14183295756805254769490889717364712370-Webmail@me.com> On Thursday, November 19, 2009, at 02:34PM, "John W. Eaton" wrote: >On 19-Nov-2009, Ben Abbott wrote: > >| >Yours says checking for F77_FUNC(dseupd,DSEUPD), which seems odd since >| >the F77_FUNC macro is not used in the ARPACK test or the >| >OCTAVE_CHECK_LIBRARY macro from acinclude.m4 >| > >| >I'm not sure why the lines in the configure script (19002 vs 28523). >| >What version of autoconf are you using? I have 2.64. >| > >| >Have you run autogen.sh recently? >| > >| >jwe >| >| I ran autogen.sh must prior to trying this build. >| >| My autoconf is 2.63. > >Are you sure your configure script is up to date? Does it have the >lines > > save_LIBS="$LIBS" > LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS" > OCTAVE_CHECK_LIBRARY(arpack, ARPACK, > [arpack not found. The eigs function will be disabled.], > [], > [dseupd], > [Fortran 77], [don't use the ARPACK library, disable eigs function]) > LIBS="$save_LIBS" > >or something else? If so, where is the "F77_FUNC(dseupd,DSEUPD)" >coming from in the config.log message? The reason I suspect an old >version of configure.ac is that it used to be > > save_LIBS="$LIBS" > LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS" > OCTAVE_CHECK_LIBRARY(arpack, ARPACK, > [arpack not found. The eigs function will be disabled.], > [], > [F77_FUNC(dseupd,DSEUPD)], > [], [don't use the ARPACK library, disable eigs function]) > LIBS="$save_LIBS" > >which would account for both the missing LAPACK and BLAS libs and the >"F77_FUNC(dseupd,DSEUPD)" name appearing in the checking message. > >If your configure.ac script really is up to date, then what are the >values of LAPACK_LIBS and BLAS_LIBS at this point in the configure >script? If they are defined, I didn't see them in the config.log >output you posted. > >jwe John, I think I there is some confusion. I'm trying to build 3.2.3 http://hg.tw-math.de/release-3-2-x/ There is no configure.ac file there. As I'm having even bigger problems with ... http://hg.savannah.gnu.org/hgweb/octave/ As I'm not sure if my trouble with the devevelopers sources are related to libtool, someother recent change to octave, or a change on my end (Mac OSX, Fink, etc), I thought I'd back up and try something that has always worked. Ben From michael.goffioul at gmail.com Thu Nov 19 14:39:29 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Thu, 19 Nov 2009 20:39:29 +0000 Subject: Print to PDF under Windows Message-ID: <128f38bd0911191239r443321dao240b01ab66bb9e35@mail.gmail.com> Hi, In print.m, I see the following pieces of code: ... (line 194) elseif (ispc ()) if (~isempty (getenv ("GSC"))) persistent ghostscript_binary = getenv ("GSC"); else persistent ghostscript_binary = "gswin32c"; endif ... ... (line 265) elseif (ispc ()) [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1 ) else ( exit /B 0 )", ghostscript_binary)); have_ghostscript = (status ~= 0); endif ... Now, let's say GSC is not defined. How is this supposed to work? The "system" call will check for the existence of a file named "gswin32c" in the current directory. This will never work... or am I missing something? Wouldn't it be better to default to persistent ghostscript_binary = file_in_path(EXEC_PATH, "gswin32c.exe"); Michael. From bpabbott at mac.com Thu Nov 19 15:45:56 2009 From: bpabbott at mac.com (Ben Abbott) Date: Thu, 19 Nov 2009 16:45:56 -0500 Subject: Print to PDF under Windows In-Reply-To: <128f38bd0911191239r443321dao240b01ab66bb9e35@mail.gmail.com> References: <128f38bd0911191239r443321dao240b01ab66bb9e35@mail.gmail.com> Message-ID: <137439832808707203260296105367491456037-Webmail@me.com> On Thursday, November 19, 2009, at 03:39PM, "Michael Goffioul" wrote: >Hi, > >In print.m, I see the following pieces of code: > >... (line 194) > elseif (ispc ()) > if (~isempty (getenv ("GSC"))) > persistent ghostscript_binary = getenv ("GSC"); > else > persistent ghostscript_binary = "gswin32c"; > endif >... >... (line 265) > elseif (ispc ()) > [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1 >) else ( exit /B 0 )", ghostscript_binary)); > have_ghostscript = (status ~= 0); > endif >... > >Now, let's say GSC is not defined. How is this supposed to work? >The "system" call will check for the existence of a file named >"gswin32c" in the current directory. This will never work... or am >I missing something? > >Wouldn't it be better to default to > > persistent ghostscript_binary = file_in_path(EXEC_PATH, "gswin32c.exe"); > >Michael. I'd expect both to work. Unless the the windows binary bundles ghostscript with octave. Is that the case? Ben From jwe at octave.org Thu Nov 19 15:49:25 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 19 Nov 2009 16:49:25 -0500 Subject: finally actually using gnulib In-Reply-To: <4B059EDF.5070606@gmx.net> References: <19198.60584.771475.300423@segfault.lan> <4AFEFF11.1070906@gmx.net> <420fb9e60911141224p3adbee11od4d35824be82779f@mail.gmail.com> <4AFF17FD.8000008@gmx.net> <4B059EDF.5070606@gmx.net> Message-ID: <19205.48485.939413.654792@segfault.lan> On 19-Nov-2009, Benjamin Lindner wrote: | Benjamin Lindner wrote: | > | > Thanks for this hint. | > This is probably the fastest way to get it testing. | | I am probably missing something trivial or simply doing something | stupid. | | I downloaded a gnulib snapshot, and from a cloned hg repos, with | john's patch imported, executed | | $ ./autogen.sh --gnulib-srcdir=/octmgw32/octave/gnulib | generating source lists for liboctave/Makefile... | vx-op-inc.mk is unchanged | mx-op-inc.mk is unchanged | smx-op-inc.mk is unchanged | vx-op-src.mk is unchanged | mx-op-src.mk is unchanged | smx-op-src.mk is unchanged | generating doc/interpreter/images.mk... | images.mk is unchanged | generating src/DLD-FUNCTIONS/module.mk... | module.mk is unchanged | bootstrapping... | ./bootstrap: one of these is required: sha1sum gsha1sum The sha1sum program is part of GNU coreutils. But it looks like the bootstrap script only uses it if there are .po files to update (we don't have any), so I don't think we really need it. What happenss if you comment out the find_tool SHA1SUM sha1sum gsha1sum line in the bootstrap script? Does it work then? Also, if you see a message about no libgnu/gnulib.mk file, you will need to create a file called libgnu/Makefile.am with the contents include gnulib.mk before running autogen.sh. I think that filewas accidentally left out of my previous patch. jwe From jwe at octave.org Thu Nov 19 15:52:31 2009 From: jwe at octave.org (John W. Eaton) Date: Thu, 19 Nov 2009 16:52:31 -0500 Subject: building 3.2.3 but not finding arpack In-Reply-To: <14183295756805254769490889717364712370-Webmail@me.com> References: <102533869451646316050226334846051191555-Webmail@me.com> <29216629490932046617741810902617041414-Webmail@me.com> <19205.40368.682892.40273@segfault.lan> <14183295756805254769490889717364712370-Webmail@me.com> Message-ID: <19205.48671.671747.943213@segfault.lan> On 19-Nov-2009, Ben Abbott wrote: | | On Thursday, November 19, 2009, at 02:34PM, "John W. Eaton" wrote: | >On 19-Nov-2009, Ben Abbott wrote: | > | >| >Yours says checking for F77_FUNC(dseupd,DSEUPD), which seems odd since | >| >the F77_FUNC macro is not used in the ARPACK test or the | >| >OCTAVE_CHECK_LIBRARY macro from acinclude.m4 | >| > | >| >I'm not sure why the lines in the configure script (19002 vs 28523). | >| >What version of autoconf are you using? I have 2.64. | >| > | >| >Have you run autogen.sh recently? | >| > | >| >jwe | >| | >| I ran autogen.sh must prior to trying this build. | >| | >| My autoconf is 2.63. | > | >Are you sure your configure script is up to date? Does it have the | >lines | > | > save_LIBS="$LIBS" | > LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS" | > OCTAVE_CHECK_LIBRARY(arpack, ARPACK, | > [arpack not found. The eigs function will be disabled.], | > [], | > [dseupd], | > [Fortran 77], [don't use the ARPACK library, disable eigs function]) | > LIBS="$save_LIBS" | > | >or something else? If so, where is the "F77_FUNC(dseupd,DSEUPD)" | >coming from in the config.log message? The reason I suspect an old | >version of configure.ac is that it used to be | > | > save_LIBS="$LIBS" | > LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS" | > OCTAVE_CHECK_LIBRARY(arpack, ARPACK, | > [arpack not found. The eigs function will be disabled.], | > [], | > [F77_FUNC(dseupd,DSEUPD)], | > [], [don't use the ARPACK library, disable eigs function]) | > LIBS="$save_LIBS" | > | >which would account for both the missing LAPACK and BLAS libs and the | >"F77_FUNC(dseupd,DSEUPD)" name appearing in the checking message. | > | >If your configure.ac script really is up to date, then what are the | >values of LAPACK_LIBS and BLAS_LIBS at this point in the configure | >script? If they are defined, I didn't see them in the config.log | >output you posted. | > | >jwe | | John, I think I there is some confusion. | | I'm trying to build 3.2.3 | | http://hg.tw-math.de/release-3-2-x/ | | There is no configure.ac file there. | | As I'm having even bigger problems with ... | | http://hg.savannah.gnu.org/hgweb/octave/ | | As I'm not sure if my trouble with the devevelopers sources are related to libtool, someother recent change to octave, or a change on my end (Mac OSX, Fink, etc), I thought I'd back up and try something that has always worked. OK, sorry about the confusion. In the 3.2.3 configure.in file, we had AC_ARG_WITH(arpack, [AS_HELP_STRING([--without-arpack], [don't use ARPACK, disable some sparse functionality])], with_arpack=$withval, with_arpack=yes) warn_arpack="arpack not found. This will result in a lack of the eigs function." if test "$with_arpack" = yes; then with_arpack=no AC_CHECK_LIB(arpack, F77_FUNC(dseupd,DSEUPD), [ARPACK_LIBS="-larpack"; with_arpack=yes], , $LAPACK_LIBS $FLIBS) if test "$with_arpack" = yes; then AC_DEFINE(HAVE_ARPACK, 1, [Define if the ARPACK library is used.]) warn_arpack= fi fi if test -n "$warn_arpack"; then AC_MSG_WARN($warn_arpack) fi but given that earlier in the script we have ACX_LAPACK([BLAS_LIBS="$LAPACK_LIBS $BLAS_LIBS"], [LAPACK_DIR="lapack"]) I think the AC_CHECK_LIB macro should be using "$BLAS_LIBS" instead of "$LAPACK_LIBS". jwe From bpabbott at mac.com Thu Nov 19 16:07:43 2009 From: bpabbott at mac.com (Ben Abbott) Date: Thu, 19 Nov 2009 17:07:43 -0500 Subject: building 3.2.3 but not finding arpack In-Reply-To: <19205.48671.671747.943213@segfault.lan> References: <102533869451646316050226334846051191555-Webmail@me.com> <29216629490932046617741810902617041414-Webmail@me.com> <19205.40368.682892.40273@segfault.lan> <14183295756805254769490889717364712370-Webmail@me.com> <19205.48671.671747.943213@segfault.lan> Message-ID: <63932617819555406994652055683444817978-Webmail@me.com> On Thursday, November 19, 2009, at 04:52PM, "John W. Eaton" wrote: >On 19-Nov-2009, Ben Abbott wrote: > >| >| On Thursday, November 19, 2009, at 02:34PM, "John W. Eaton" wrote: >| >On 19-Nov-2009, Ben Abbott wrote: >| > >| >| >Yours says checking for F77_FUNC(dseupd,DSEUPD), which seems odd since >| >| >the F77_FUNC macro is not used in the ARPACK test or the >| >| >OCTAVE_CHECK_LIBRARY macro from acinclude.m4 >| >| > >| >| >I'm not sure why the lines in the configure script (19002 vs 28523). >| >| >What version of autoconf are you using? I have 2.64. >| >| > >| >| >Have you run autogen.sh recently? >| >| > >| >| >jwe >| >| >| >| I ran autogen.sh must prior to trying this build. >| >| >| >| My autoconf is 2.63. >| > >| >Are you sure your configure script is up to date? Does it have the >| >lines >| > >| > save_LIBS="$LIBS" >| > LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS" >| > OCTAVE_CHECK_LIBRARY(arpack, ARPACK, >| > [arpack not found. The eigs function will be disabled.], >| > [], >| > [dseupd], >| > [Fortran 77], [don't use the ARPACK library, disable eigs function]) >| > LIBS="$save_LIBS" >| > >| >or something else? If so, where is the "F77_FUNC(dseupd,DSEUPD)" >| >coming from in the config.log message? The reason I suspect an old >| >version of configure.ac is that it used to be >| > >| > save_LIBS="$LIBS" >| > LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS" >| > OCTAVE_CHECK_LIBRARY(arpack, ARPACK, >| > [arpack not found. The eigs function will be disabled.], >| > [], >| > [F77_FUNC(dseupd,DSEUPD)], >| > [], [don't use the ARPACK library, disable eigs function]) >| > LIBS="$save_LIBS" >| > >| >which would account for both the missing LAPACK and BLAS libs and the >| >"F77_FUNC(dseupd,DSEUPD)" name appearing in the checking message. >| > >| >If your configure.ac script really is up to date, then what are the >| >values of LAPACK_LIBS and BLAS_LIBS at this point in the configure >| >script? If they are defined, I didn't see them in the config.log >| >output you posted. >| > >| >jwe >| >| John, I think I there is some confusion. >| >| I'm trying to build 3.2.3 >| >| http://hg.tw-math.de/release-3-2-x/ >| >| There is no configure.ac file there. >| >| As I'm having even bigger problems with ... >| >| http://hg.savannah.gnu.org/hgweb/octave/ >| >| As I'm not sure if my trouble with the devevelopers sources are related to libtool, someother recent change to octave, or a change on my end (Mac OSX, Fink, etc), I thought I'd back up and try something that has always worked. > >OK, sorry about the confusion. In the 3.2.3 configure.in file, we had > > AC_ARG_WITH(arpack, > [AS_HELP_STRING([--without-arpack], > [don't use ARPACK, disable some sparse functionality])], > with_arpack=$withval, with_arpack=yes) > > warn_arpack="arpack not found. This will result in a lack of the eigs function." > if test "$with_arpack" = yes; then > with_arpack=no > AC_CHECK_LIB(arpack, F77_FUNC(dseupd,DSEUPD), [ARPACK_LIBS="-larpack"; with_arpack=yes], , $LAPACK_LIBS $FLIBS) > if test "$with_arpack" = yes; then > AC_DEFINE(HAVE_ARPACK, 1, [Define if the ARPACK library is used.]) > warn_arpack= > fi > fi > if test -n "$warn_arpack"; then > AC_MSG_WARN($warn_arpack) > fi > >but given that earlier in the script we have > > ACX_LAPACK([BLAS_LIBS="$LAPACK_LIBS $BLAS_LIBS"], [LAPACK_DIR="lapack"]) > >I think the AC_CHECK_LIB macro should be using "$BLAS_LIBS" instead of >"$LAPACK_LIBS". > >jwe Replacing "$LAPACK_LIBS" with "$BLAS_LIBS" fixed the configure problem for me. I'll try "make" and report back. Ben From bpabbott at mac.com Thu Nov 19 18:11:17 2009 From: bpabbott at mac.com (Ben Abbott) Date: Thu, 19 Nov 2009 19:11:17 -0500 Subject: building 3.2.3 but not finding arpack In-Reply-To: <63932617819555406994652055683444817978-Webmail@me.com> References: <102533869451646316050226334846051191555-Webmail@me.com> <29216629490932046617741810902617041414-Webmail@me.com> <19205.40368.682892.40273@segfault.lan> <14183295756805254769490889717364712370-Webmail@me.com> <19205.48671.671747.943213@segfault.lan> <63932617819555406994652055683444817978-Webmail@me.com> Message-ID: On Nov 19, 2009, at 5:07 PM, Ben Abbott wrote: > On Thursday, November 19, 2009, at 04:52PM, "John W. Eaton" wrote: >> On 19-Nov-2009, Ben Abbott wrote: >> >> | >> | On Thursday, November 19, 2009, at 02:34PM, "John W. Eaton" wrote: >> | >On 19-Nov-2009, Ben Abbott wrote: >> | > >> | >| >Yours says checking for F77_FUNC(dseupd,DSEUPD), which seems odd since >> | >| >the F77_FUNC macro is not used in the ARPACK test or the >> | >| >OCTAVE_CHECK_LIBRARY macro from acinclude.m4 >> | >| > >> | >| >I'm not sure why the lines in the configure script (19002 vs 28523). >> | >| >What version of autoconf are you using? I have 2.64. >> | >| > >> | >| >Have you run autogen.sh recently? >> | >| > >> | >| >jwe >> | >| >> | >| I ran autogen.sh must prior to trying this build. >> | >| >> | >| My autoconf is 2.63. >> | > >> | >Are you sure your configure script is up to date? Does it have the >> | >lines >> | > >> | > save_LIBS="$LIBS" >> | > LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS" >> | > OCTAVE_CHECK_LIBRARY(arpack, ARPACK, >> | > [arpack not found. The eigs function will be disabled.], >> | > [], >> | > [dseupd], >> | > [Fortran 77], [don't use the ARPACK library, disable eigs function]) >> | > LIBS="$save_LIBS" >> | > >> | >or something else? If so, where is the "F77_FUNC(dseupd,DSEUPD)" >> | >coming from in the config.log message? The reason I suspect an old >> | >version of configure.ac is that it used to be >> | > >> | > save_LIBS="$LIBS" >> | > LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS" >> | > OCTAVE_CHECK_LIBRARY(arpack, ARPACK, >> | > [arpack not found. The eigs function will be disabled.], >> | > [], >> | > [F77_FUNC(dseupd,DSEUPD)], >> | > [], [don't use the ARPACK library, disable eigs function]) >> | > LIBS="$save_LIBS" >> | > >> | >which would account for both the missing LAPACK and BLAS libs and the >> | >"F77_FUNC(dseupd,DSEUPD)" name appearing in the checking message. >> | > >> | >If your configure.ac script really is up to date, then what are the >> | >values of LAPACK_LIBS and BLAS_LIBS at this point in the configure >> | >script? If they are defined, I didn't see them in the config.log >> | >output you posted. >> | > >> | >jwe >> | >> | John, I think I there is some confusion. >> | >> | I'm trying to build 3.2.3 >> | >> | http://hg.tw-math.de/release-3-2-x/ >> | >> | There is no configure.ac file there. >> | >> | As I'm having even bigger problems with ... >> | >> | http://hg.savannah.gnu.org/hgweb/octave/ >> | >> | As I'm not sure if my trouble with the devevelopers sources are related to libtool, someother recent change to octave, or a change on my end (Mac OSX, Fink, etc), I thought I'd back up and try something that has always worked. >> >> OK, sorry about the confusion. In the 3.2.3 configure.in file, we had >> >> AC_ARG_WITH(arpack, >> [AS_HELP_STRING([--without-arpack], >> [don't use ARPACK, disable some sparse functionality])], >> with_arpack=$withval, with_arpack=yes) >> >> warn_arpack="arpack not found. This will result in a lack of the eigs function." >> if test "$with_arpack" = yes; then >> with_arpack=no >> AC_CHECK_LIB(arpack, F77_FUNC(dseupd,DSEUPD), [ARPACK_LIBS="-larpack"; with_arpack=yes], , $LAPACK_LIBS $FLIBS) >> if test "$with_arpack" = yes; then >> AC_DEFINE(HAVE_ARPACK, 1, [Define if the ARPACK library is used.]) >> warn_arpack= >> fi >> fi >> if test -n "$warn_arpack"; then >> AC_MSG_WARN($warn_arpack) >> fi >> >> but given that earlier in the script we have >> >> ACX_LAPACK([BLAS_LIBS="$LAPACK_LIBS $BLAS_LIBS"], [LAPACK_DIR="lapack"]) >> >> I think the AC_CHECK_LIB macro should be using "$BLAS_LIBS" instead of >> "$LAPACK_LIBS". >> >> jwe > > Replacing "$LAPACK_LIBS" with "$BLAS_LIBS" fixed the configure problem for me. > > I'll try "make" and report back. > > Ben My make failed with ... g++-4 -c -g -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 -Wall -W -Wshadow -Wold-style-cast -Wformat -g -I /sw/include -O3 pr-output.cc -o pic/pr-output.o pr-output.cc: In function ?void set_format(const Complex&, int&, int&)?: pr-output.cc:855: error: ?xr_abs? was not declared in this scope make[2]: *** [pic/pr-output.o] Error 1 make[1]: *** [src] Error 2 make: *** [all] Error 2 I'm running gcc 4.4.2. Ben From dbateman at dbateman.org Thu Nov 19 19:02:34 2009 From: dbateman at dbateman.org (David Bateman) Date: Fri, 20 Nov 2009 02:02:34 +0100 Subject: FTP objects Message-ID: <4B05EAAA.3050407@dbateman.org> One of the things I've had on my Octave ToDo list for a long time and something I thought might be easy to do (within the limits of my lack of time) is to implement matlab compatible FTP objects. Yes there is an ftp package in octave-forge, but previous discussion excluded porting that in the core of Octave as it adds a dependency on ftplib when we already have one on curl for the urlread and urlwrite functions. The ftp functions are core functions of matlab and so following the logic that Octave should have the matlab core functions re-writing them to use libcurl is needed to get them into Octave. I have a fairly complete implementation of the FTP object type in the attached, though have several problems. The first issue is that Octave currently doesn't have any code in the core using OOP and the matlab versions use OOP and so this is needed for compatibility. It appears that the new build process doesn't mind a scripts/@ftp. Is this the right place for it? The next problem is that as this type wraps libcurl it has to be implemented at least partially in an oct-file. So the oct-files should live in the @ftp directory as well. One way should probably be like @ftp/{ftp.m, display.m, ...} @ftp/private/__ftp__.oct @ftp/private/PKG_ADD ## contains autoloads for the DEFUN_DLD functions in __ftp__.oct though this doesn't work as it appears that "autoload" doesn't work in either the private or class directories. In any case such a structure is against the separation of OS dependent and independent files, and I'm sure the debian packagers at least will complain as I remember well discussions about this when the pkg installation paths were being discussed. Then I suppose a better way to do it is to have two separate @ftp directories, one in ${fcnfiledir}/@ftp/{ftp.m,display.m,...} ${octfiledir}/@ftp/private/{__ftp__.oct,PKG_ADD} Having two separate @ftp directories works, but the autoloads in the private directory doesn't yet again. I'd suggest that the autoload issue in class and private directories should be fixed before going further with this direction. As the oct-file basically does all of the work an alternative might be to have the OOP code in the oct-file itself and get rid of the mfiles. The mfiles in this changeset basically pass off all of the work to the underlying oct-file. However, I don't see how to do this within the build process. Ideas? What I did in the attached package was to just make the oct-files callable anywhere even though they are only useful for the ftp objects and added the code to urlwrite.cc so that code might be shared with these functions. This avoids needing to fix the private directories with oct-files and autoloading, but adds yet more functions starting with __ to the global function name space. The advantage for this is that nothing special needs to be done for the oct-file installation to put them in a different directory than normal. This is what this changeset implements I also have a couple of limitations on the ftp objects. The "dir" functions with an output argument returns a structure with the filenames, size, modification date and a flag for whether it is a directory or not. The ftp "dir" command to the server can't be used to fill in this information as the return from the server is dependent on the ftp server OS and ftp daemon. I instead used the MDTM command for the file modification date, though this appears to give an error for directories for all of the servers I tried. I used this fact to flag which filename defines a directory, but it also means I have no portable means of obtaining the modification date of directories. The next issue I have is how do I document an OOP class in the octave manual that overloads existing functions like cd, delete, close, mkdir, rmdir, etc? I can't use DOCSTRING on the OOP methods so basically all I can do is include the non overloaded functions and write a bit of text around those the explain the rest. Is there a better way? In any case there are a number of duplication errors signaled in the creation of the DOCSTRING file, but these don't stop the build itself. Another question is should I store the password in the FTP object? If I want to be able to save the FTP objects to a file and have them work when reloaded, then this is needed. However, it can represent a security risk, though not much of a one as the password is stored in the octave history when the handle was first created. Should I care? I haven't committed this code but will if others think its ok in its current form. Regards David PS: I create the curl_handle class in __ftp__.cc such that it might be reused for urlread and urlwrite and reduce the code duplication between this existing code and the ftp objects and used this in the urlread and urlwrite functions. -- David Bateman dbateman at dbateman.org 35 rue Gambetta +33 1 46 04 02 18 (Home) 92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob) -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.ftp.bz2 Type: application/x-bzip2 Size: 12064 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091120/ad0114c3/attachment-0001.bin From highegg at gmail.com Fri Nov 20 04:01:20 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 20 Nov 2009 11:01:20 +0100 Subject: 3.2.4 call for patches Message-ID: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> hi there, I've spent essentially no time on 3.2.x maintenance last couple of months, and it seems that the sources have again significantly diverged, but I feel like producing one more 3.2.x release before closing the branch and focusing on 3.4.0. If you have any patches that you'd like to have applied to 3.2.x, please let me know. However, I'm not willing to invest nontrivial amounts of time into the individual transplants, so unless a patch is smoothly applicable and conforms to the binary compatibility policy, someone needs to convert it or the bug will stay unfixed in 3.2.x. regards -- 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/20091120/6e21ea06/attachment.html From shaiay at gmail.com Fri Nov 20 04:21:08 2009 From: shaiay at gmail.com (Shai Ayal) Date: Fri, 20 Nov 2009 12:21:08 +0200 Subject: 3.2.4 call for patches In-Reply-To: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> References: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> Message-ID: <420fb9e60911200221q78e414a6me12be0a19a9217d1@mail.gmail.com> On Fri, Nov 20, 2009 at 12:01 PM, Jaroslav Hajek wrote: > hi there, > > I've spent essentially no time on 3.2.x maintenance last couple of months, > and it seems that the sources have again significantly diverged, but I feel > like producing one more 3.2.x release before closing the branch and focusing > on 3.4.0. > If you have any patches that you'd like to have applied to 3.2.x, please let > me know. However, I'm not willing to invest nontrivial amounts of time into > the individual transplants, so unless a patch is smoothly applicable and > conforms to the binary compatibility policy, someone needs to convert it or > the bug will stay unfixed in 3.2.x. I'm sorry I'm a bit out of touch with the 3.2.x releases, but what is the policy here? just bug fixes, or can I try to make the fltk backend work there? Shai From highegg at gmail.com Fri Nov 20 04:24:30 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Fri, 20 Nov 2009 11:24:30 +0100 Subject: 3.2.4 call for patches In-Reply-To: <420fb9e60911200221q78e414a6me12be0a19a9217d1@mail.gmail.com> References: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> <420fb9e60911200221q78e414a6me12be0a19a9217d1@mail.gmail.com> Message-ID: <69d8d540911200224i322ae249u780ef684c7f60bba@mail.gmail.com> On Fri, Nov 20, 2009 at 11:21 AM, Shai Ayal wrote: > On Fri, Nov 20, 2009 at 12:01 PM, Jaroslav Hajek > wrote: > > hi there, > > > > I've spent essentially no time on 3.2.x maintenance last couple of > months, > > and it seems that the sources have again significantly diverged, but I > feel > > like producing one more 3.2.x release before closing the branch and > focusing > > on 3.4.0. > > If you have any patches that you'd like to have applied to 3.2.x, please > let > > me know. However, I'm not willing to invest nontrivial amounts of time > into > > the individual transplants, so unless a patch is smoothly applicable and > > conforms to the binary compatibility policy, someone needs to convert it > or > > the bug will stay unfixed in 3.2.x. > > I'm sorry I'm a bit out of touch with the 3.2.x releases, but what is > the policy here? just bug fixes, or can I try to make the fltk backend > work there? > > Shai > We should not include patches that could break existing compiled functions. Basically, the point is that users should be able to upgrade Octave (minor) without needing to recompile all installed OctaveForge packages that contain compiled functions, or their own compiled functions. -- 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/20091120/d9e187a2/attachment.html From michael.goffioul at gmail.com Fri Nov 20 05:07:17 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Fri, 20 Nov 2009 11:07:17 +0000 Subject: Print to PDF under Windows In-Reply-To: <137439832808707203260296105367491456037-Webmail@me.com> References: <128f38bd0911191239r443321dao240b01ab66bb9e35@mail.gmail.com> <137439832808707203260296105367491456037-Webmail@me.com> Message-ID: <128f38bd0911200307q4fb1d13eu27e9d99ef2a98bae@mail.gmail.com> On Thu, Nov 19, 2009 at 9:45 PM, Ben Abbott wrote: > On Thursday, November 19, 2009, at 03:39PM, "Michael Goffioul" wrote: >>Hi, >> >>In print.m, I see the following pieces of code: >> >>... (line 194) >> ?elseif (ispc ()) >> ? ?if (~isempty (getenv ("GSC"))) >> ? ? ?persistent ghostscript_binary = getenv ("GSC"); >> ? ?else >> ? ? ?persistent ghostscript_binary = "gswin32c"; >> ? ?endif >>... >>... (line 265) >> ? ?elseif (ispc ()) >> ? ? ?[status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1 >>) else ( exit /B 0 )", ghostscript_binary)); >> ? ? ?have_ghostscript = (status ~= 0); >> ? ?endif >>... >> >>Now, let's say GSC is not defined. How is this supposed to work? >>The "system" call will check for the existence of a file named >>"gswin32c" in the current directory. This will never work... or am >>I missing something? >> >>Wouldn't it be better to default to >> >> ? ? ?persistent ghostscript_binary = file_in_path(EXEC_PATH, "gswin32c.exe"); >> >>Michael. > > I'd expect both to work. Unless the the windows binary bundles ghostscript with octave. Is that the case? I don't get it. The line [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1) else ( exit /B 0 )", ghostscript_binary)); will check for the existence of "gswin32c" in the current directory. First, it should be "gswin32.exe". Second you will never have "gswin32c.exe" in the current directory when using "print" in normal situation. Michael. From godfrey at isl.stanford.edu Fri Nov 20 05:08:13 2009 From: godfrey at isl.stanford.edu (Michael Godfrey) Date: Fri, 20 Nov 2009 12:08:13 +0100 Subject: 3.2.4 call for patches In-Reply-To: <420fb9e60911200221q78e414a6me12be0a19a9217d1@mail.gmail.com> References: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> <420fb9e60911200221q78e414a6me12be0a19a9217d1@mail.gmail.com> Message-ID: <4B06789D.2020507@isl.stanford.edu> > > I'm sorry I'm a bit out of touch with the 3.2.x releases, but what is > the policy here? just bug fixes, or can I try to make the fltk backend > work there? > > Shai I would definitely vote for this. These changes, in my experience, went in without any side effects on other parts of the system, they are documented in the current version of the Manual (is that what will go with the 3.2.4 release?), and they add significant functionality. Shai: if you put this together could you include my one line fix to txt-eng-ft.cc? John recently (when he committed your positioning of axis labels fix) committed this. From jwe at octave.org Fri Nov 20 07:39:19 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 20 Nov 2009 08:39:19 -0500 Subject: 3.2.4 call for patches In-Reply-To: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> References: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> Message-ID: <19206.39943.125754.303866@segfault.lan> On 20-Nov-2009, Jaroslav Hajek wrote: | I've spent essentially no time on 3.2.x maintenance last couple of months, | and it seems that the sources have again significantly diverged, but I feel | like producing one more 3.2.x release before closing the branch and focusing | on 3.4.0. | If you have any patches that you'd like to have applied to 3.2.x, please let | me know. However, I'm not willing to invest nontrivial amounts of time into | the individual transplants, so unless a patch is smoothly applicable and | conforms to the binary compatibility policy, someone needs to convert it or | the bug will stay unfixed in 3.2.x. The following patch to allow error to be called with no argument or an empty argument should also be OK. It doesn't seem to have caused any problems. http://hg.savannah.gnu.org/hgweb/octave/rev/ef45d191d833 jwe From jwe at octave.org Fri Nov 20 07:44:51 2009 From: jwe at octave.org (John W. Eaton) Date: Fri, 20 Nov 2009 08:44:51 -0500 Subject: 3.2.4 call for patches In-Reply-To: <4B06789D.2020507@isl.stanford.edu> References: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> <420fb9e60911200221q78e414a6me12be0a19a9217d1@mail.gmail.com> <4B06789D.2020507@isl.stanford.edu> Message-ID: <19206.40275.689581.673476@segfault.lan> On 20-Nov-2009, Michael Godfrey wrote: | > | > I'm sorry I'm a bit out of touch with the 3.2.x releases, but what is | > the policy here? just bug fixes, or can I try to make the fltk backend | > work there? | > | > Shai | I would definitely vote for this. These changes, in my experience, | went in without any side effects on other parts of the system, they are | documented in the current version of the Manual (is that what will | go with the 3.2.4 release?), and they add significant functionality. | | Shai: if you put this together could you include my one line fix to | txt-eng-ft.cc? John recently (when he committed your positioning | of axis labels fix) committed this. The 3.2.x sources don't even have the txt-eng-ft.cc file. I don't think we should add it. Making changes that large is not really the point of the release series. jwe From godfrey at isl.stanford.edu Fri Nov 20 08:05:57 2009 From: godfrey at isl.stanford.edu (Michael Godfrey) Date: Fri, 20 Nov 2009 15:05:57 +0100 Subject: 3.2.4 call for patches In-Reply-To: <19206.40275.689581.673476@segfault.lan> References: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> <420fb9e60911200221q78e414a6me12be0a19a9217d1@mail.gmail.com> <4B06789D.2020507@isl.stanford.edu> <19206.40275.689581.673476@segfault.lan> Message-ID: <4B06A245.7030907@isl.stanford.edu> > > The 3.2.x sources don't even have the txt-eng-ft.cc file. I don't > think we should add it. Making changes that large is not really the > point of the release series. > > jwe OK. I agree, :'( From dbateman at dbateman.org Fri Nov 20 14:35:23 2009 From: dbateman at dbateman.org (David Bateman) Date: Fri, 20 Nov 2009 21:35:23 +0100 Subject: 3.2.4 call for patches In-Reply-To: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> References: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> Message-ID: <4B06FD8B.4040703@dbateman.org> Jaroslav Hajek wrote: > hi there, > > I've spent essentially no time on 3.2.x maintenance last couple of months, > and it seems that the sources have again significantly diverged, but I feel > like producing one more 3.2.x release before closing the branch and focusing > on 3.4.0. > If you have any patches that you'd like to have applied to 3.2.x, please let > me know. However, I'm not willing to invest nontrivial amounts of time into > the individual transplants, so unless a patch is smoothly applicable and > conforms to the binary compatibility policy, someone needs to convert it or > the bug will stay unfixed in 3.2.x. > > regards > > The changeset http://hg.savannah.gnu.org/hgweb/octave/rev/97de6c916498 should probably also go into 3.2.4 D. -- David Bateman dbateman at dbateman.org 35 rue Gambetta +33 1 46 04 02 18 (Home) 92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob) From marco_atzeri at yahoo.it Fri Nov 20 15:27:02 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Fri, 20 Nov 2009 21:27:02 +0000 (GMT) Subject: WIN32 problem on liboctave/kpse.cc In-Reply-To: <19201.46804.32427.92639@segfault.lan> Message-ID: <852708.59051.qm@web25505.mail.ukl.yahoo.com> --- Lun 16/11/09, John W. Eaton ha scritto: > The configure script currently has [cut] > > ? ? ## autoconf test for LoadLibrary appears > broken. Bypass for cygwin/mingw > ? ? if $dlopen_api || $shl_load_api || > $loadlibrary_api || $dyld_api; then > ? ? ? true > ? ? else > ? ? ? case "$canonical_host_type" in > ??? *-*-cygwin* | *-*-mingw* | > *-*-msdosmsvc) > ?????loadlibrary_api=true; > ??? ;; > ? ? ? esac this solve the problem @@ -1614,7 +1616,7 @@ true else case "$canonical_host_type" in - *-*-cygwin* | *-*-mingw* | *-*-msdosmsvc) + *-*-mingw* | *-*-msdosmsvc) loadlibrary_api=true; ;; esac > > jwe > I still need to find a solution for linking static libs with libtool so likely I will join libtool mailing list to find some hint. For the time being I am using the following "orrible" hack @@ -1808,6 +1810,19 @@ AC_DEFINE(RUSAGE_TIMES_ONLY, 1, [Define if your struct rusage only has time information.]) ;; esac +### A system dependent kluge on linking. + +case "$canonical_host_type" in + *-*-cygwin*) + if test -n $AMD_LIBS ;then AMD_LIBS=-Wl,$AMD_LIBS ;fi + if test -n $CAMD_LIBS ;then CAMD_LIBS=-Wl,$CAMD_LIBS ;fi + if test -n $CCOLAMD_LIBS ;then CCOLAMD_LIBS=-Wl,$CCOLAMD_LIBS ;fi + if test -n $CHOLMOD_LIBS ;then CHOLMOD_LIBS=-Wl,$CHOLMOD_LIBS ;fi + if test -n $COLAMD_LIBS ;then COLAMD_LIBS=-Wl,$COLAMD_LIBS ;fi + if test -n $CXSPARSE_LIBS ;then CXSPARSE_LIBS=-Wl,$CXSPARSE_LIBS" -Wl,-lblas -Wl,-lcygwin" ;fi + if test -n $UMFPACK_LIBS ;then UMFPACK_LIBS=-Wl,$UMFPACK_LIBS ;fi + ;; +esac ### Checks for other programs used for building, testing, installing, ### and running Octave. Regards Marco From bpabbott at mac.com Fri Nov 20 15:53:44 2009 From: bpabbott at mac.com (Ben Abbott) Date: Fri, 20 Nov 2009 16:53:44 -0500 Subject: Print to PDF under Windows In-Reply-To: <128f38bd0911200307q4fb1d13eu27e9d99ef2a98bae@mail.gmail.com> References: <128f38bd0911191239r443321dao240b01ab66bb9e35@mail.gmail.com> <137439832808707203260296105367491456037-Webmail@me.com> <128f38bd0911200307q4fb1d13eu27e9d99ef2a98bae@mail.gmail.com> Message-ID: <589FBB87-7246-40CA-BD35-B90A38F799C6@mac.com> On Nov 20, 2009, at 6:07 AM, Michael Goffioul wrote: > On Thu, Nov 19, 2009 at 9:45 PM, Ben Abbott wrote: >> On Thursday, November 19, 2009, at 03:39PM, "Michael Goffioul" wrote: >>> Hi, >>> >>> In print.m, I see the following pieces of code: >>> >>> ... (line 194) >>> elseif (ispc ()) >>> if (~isempty (getenv ("GSC"))) >>> persistent ghostscript_binary = getenv ("GSC"); >>> else >>> persistent ghostscript_binary = "gswin32c"; >>> endif >>> ... >>> ... (line 265) >>> elseif (ispc ()) >>> [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1 >>> ) else ( exit /B 0 )", ghostscript_binary)); >>> have_ghostscript = (status ~= 0); >>> endif >>> ... >>> >>> Now, let's say GSC is not defined. How is this supposed to work? >>> The "system" call will check for the existence of a file named >>> "gswin32c" in the current directory. This will never work... or am >>> I missing something? >>> >>> Wouldn't it be better to default to >>> >>> persistent ghostscript_binary = file_in_path(EXEC_PATH, "gswin32c.exe"); >>> >>> Michael. >> >> I'd expect both to work. Unless the the windows binary bundles ghostscript with octave. Is that the case? > > I don't get it. The line > > [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1) else > ( exit /B 0 )", ghostscript_binary)); > > will check for the existence of "gswin32c" in the current directory. > First, it should be "gswin32.exe". Second you will never have "gswin32c.exe" > in the current directory when using "print" in normal situation. > > Michael. Ok. I get it ... sorry for being so dense. I'll put together a changeset. Ben From marco_atzeri at yahoo.it Fri Nov 20 16:14:23 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Fri, 20 Nov 2009 22:14:23 +0000 (GMT) Subject: compiling without opengl Message-ID: <905415.16012.qm@web25503.mail.ukl.yahoo.com> on latest $ hg tip changeset:???9840:c0b54271904b tag:? ? ? ???tip user:? ? ? ? Jaroslav Hajek date:? ? ? ? Thu Nov 19 15:48:33 2009+0100 summary:? ???improve safe numel()calculation for arrays configured as $ ../octave/configure --libexecdir=/usr/lib --without-framework-opengl F77=gfortran-4 CXX=g++-4 CPP=cpp-4 CC=gcc-4 LDFLAGS=-no-undefined there is still some gl dependency Creating library file: .libs/liboctinterp.dll.a.libs/liboctinterp_la-gl2ps.o: In function `gl2psPrintPrimitives': /pub/hg/octave_build_automake/src/../../octave/src/gl2ps.c:5472: undefined reference to `_glRenderMode at 4' .libs/liboctinterp_la-gl2ps.o: In function `gl2psPrintPGFBeginViewport': /pub/hg/octave_build_automake/src/../../octave/src/gl2ps.c:5370: undefined reference to `_glRenderMode at 4' /pub/hg/octave_build_automake/src/../../octave/src/gl2ps.c:5380: undefined reference to `_glGetFloatv at 8' /pub/hg/octave_build_automake/src/../../octave/src/gl2ps.c:5383: undefined reference to `_glGetIntegerv at 8' .libs/liboctinterp_la-gl2ps.o: In function `gl2psPrintPostScriptBeginViewport': Regards Marco From bpabbott at mac.com Fri Nov 20 16:56:05 2009 From: bpabbott at mac.com (Ben Abbott) Date: Fri, 20 Nov 2009 17:56:05 -0500 Subject: Print to PDF under Windows [changeset] In-Reply-To: <589FBB87-7246-40CA-BD35-B90A38F799C6@mac.com> References: <128f38bd0911191239r443321dao240b01ab66bb9e35@mail.gmail.com> <137439832808707203260296105367491456037-Webmail@me.com> <128f38bd0911200307q4fb1d13eu27e9d99ef2a98bae@mail.gmail.com> <589FBB87-7246-40CA-BD35-B90A38F799C6@mac.com> Message-ID: On Nov 20, 2009, at 4:53 PM, Ben Abbott wrote: > On Nov 20, 2009, at 6:07 AM, Michael Goffioul wrote: > >> On Thu, Nov 19, 2009 at 9:45 PM, Ben Abbott wrote: >>> On Thursday, November 19, 2009, at 03:39PM, "Michael Goffioul" wrote: >>>> Hi, >>>> >>>> In print.m, I see the following pieces of code: >>>> >>>> ... (line 194) >>>> elseif (ispc ()) >>>> if (~isempty (getenv ("GSC"))) >>>> persistent ghostscript_binary = getenv ("GSC"); >>>> else >>>> persistent ghostscript_binary = "gswin32c"; >>>> endif >>>> ... >>>> ... (line 265) >>>> elseif (ispc ()) >>>> [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1 >>>> ) else ( exit /B 0 )", ghostscript_binary)); >>>> have_ghostscript = (status ~= 0); >>>> endif >>>> ... >>>> >>>> Now, let's say GSC is not defined. How is this supposed to work? >>>> The "system" call will check for the existence of a file named >>>> "gswin32c" in the current directory. This will never work... or am >>>> I missing something? >>>> >>>> Wouldn't it be better to default to >>>> >>>> persistent ghostscript_binary = file_in_path(EXEC_PATH, "gswin32c.exe"); >>>> >>>> Michael. >>> >>> I'd expect both to work. Unless the the windows binary bundles ghostscript with octave. Is that the case? >> >> I don't get it. The line >> >> [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1) else >> ( exit /B 0 )", ghostscript_binary)); >> >> will check for the existence of "gswin32c" in the current directory. >> First, it should be "gswin32.exe". Second you will never have "gswin32c.exe" >> in the current directory when using "print" in normal situation. >> >> Michael. > > Ok. I get it ... sorry for being so dense. > > I'll put together a changeset. > > Ben Michael or other Window users, Can you confirm the attached works? Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: changeset.patch Type: application/octet-stream Size: 1490 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091120/37161b00/attachment.obj -------------- next part -------------- From tmacchant at yahoo.co.jp Fri Nov 20 18:56:35 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sat, 21 Nov 2009 09:56:35 +0900 (JST) Subject: 3.2.4 call for patches In-Reply-To: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> Message-ID: <20091121005635.90199.qmail@web3805.mail.bbt.yahoo.co.jp> Hello This is not a bug fix. However I would like to propose to remove 'pgnuplot' check in aclocal.m4. Now on windows there exist 'gnuplot.exe' in cvs trees, which can be used from octave. The combination of pgnuplot+wgnuplot cannot be worked from octave 3.2. Checking 'pgnuplot' existence is no loner be useful but is rather harmful. Regards Tatsuro --- Jaroslav Hajek wrote: > hi there, > > I've spent essentially no time on 3.2.x maintenance last couple of months, > and it seems that the sources have again significantly diverged, but I feel > like producing one more 3.2.x release before closing the branch and focusing > on 3.4.0. > If you have any patches that you'd like to have applied to 3.2.x, please let > me know. However, I'm not willing to invest nontrivial amounts of time into > the individual transplants, so unless a patch is smoothly applicable and > conforms to the binary compatibility policy, someone needs to convert it or > the bug will stay unfixed in 3.2.x. > regards > > -- > RNDr. Jaroslav Hajek > computing expert & GNU Octave developer > Aeronautical Research and Test Institute (VZLU) > Prague, Czech Republic > url: www.highegg.matfyz.cz > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ -------------- next part -------------- A non-text attachment was scrubbed... Name: remove_pgnuplot_check.changeset Type: application/x-unknown Size: 812 bytes Desc: 35479976-remove_pgnuplot_check.changeset Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091121/11097f48/attachment.bin From bpabbott at mac.com Fri Nov 20 19:07:09 2009 From: bpabbott at mac.com (Ben Abbott) Date: Fri, 20 Nov 2009 20:07:09 -0500 Subject: building 3.2.3 but not finding arpack In-Reply-To: References: <102533869451646316050226334846051191555-Webmail@me.com> <29216629490932046617741810902617041414-Webmail@me.com> <19205.40368.682892.40273@segfault.lan> <14183295756805254769490889717364712370-Webmail@me.com> <19205.48671.671747.943213@segfault.lan> <63932617819555406994652055683444817978-Webmail@me.com> Message-ID: On Nov 19, 2009, at 7:11 PM, Ben Abbott wrote: > On Nov 19, 2009, at 5:07 PM, Ben Abbott wrote: > >> On Thursday, November 19, 2009, at 04:52PM, "John W. Eaton" wrote: >>> On 19-Nov-2009, Ben Abbott wrote: >>> >>> | >>> | On Thursday, November 19, 2009, at 02:34PM, "John W. Eaton" wrote: >>> | >On 19-Nov-2009, Ben Abbott wrote: >>> | > >>> | >| >Yours says checking for F77_FUNC(dseupd,DSEUPD), which seems odd since >>> | >| >the F77_FUNC macro is not used in the ARPACK test or the >>> | >| >OCTAVE_CHECK_LIBRARY macro from acinclude.m4 >>> | >| > >>> | >| >I'm not sure why the lines in the configure script (19002 vs 28523). >>> | >| >What version of autoconf are you using? I have 2.64. >>> | >| > >>> | >| >Have you run autogen.sh recently? >>> | >| > >>> | >| >jwe >>> | >| >>> | >| I ran autogen.sh must prior to trying this build. >>> | >| >>> | >| My autoconf is 2.63. >>> | > >>> | >Are you sure your configure script is up to date? Does it have the >>> | >lines >>> | > >>> | > save_LIBS="$LIBS" >>> | > LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS" >>> | > OCTAVE_CHECK_LIBRARY(arpack, ARPACK, >>> | > [arpack not found. The eigs function will be disabled.], >>> | > [], >>> | > [dseupd], >>> | > [Fortran 77], [don't use the ARPACK library, disable eigs function]) >>> | > LIBS="$save_LIBS" >>> | > >>> | >or something else? If so, where is the "F77_FUNC(dseupd,DSEUPD)" >>> | >coming from in the config.log message? The reason I suspect an old >>> | >version of configure.ac is that it used to be >>> | > >>> | > save_LIBS="$LIBS" >>> | > LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS" >>> | > OCTAVE_CHECK_LIBRARY(arpack, ARPACK, >>> | > [arpack not found. The eigs function will be disabled.], >>> | > [], >>> | > [F77_FUNC(dseupd,DSEUPD)], >>> | > [], [don't use the ARPACK library, disable eigs function]) >>> | > LIBS="$save_LIBS" >>> | > >>> | >which would account for both the missing LAPACK and BLAS libs and the >>> | >"F77_FUNC(dseupd,DSEUPD)" name appearing in the checking message. >>> | > >>> | >If your configure.ac script really is up to date, then what are the >>> | >values of LAPACK_LIBS and BLAS_LIBS at this point in the configure >>> | >script? If they are defined, I didn't see them in the config.log >>> | >output you posted. >>> | > >>> | >jwe >>> | >>> | John, I think I there is some confusion. >>> | >>> | I'm trying to build 3.2.3 >>> | >>> | http://hg.tw-math.de/release-3-2-x/ >>> | >>> | There is no configure.ac file there. >>> | >>> | As I'm having even bigger problems with ... >>> | >>> | http://hg.savannah.gnu.org/hgweb/octave/ >>> | >>> | As I'm not sure if my trouble with the devevelopers sources are related to libtool, someother recent change to octave, or a change on my end (Mac OSX, Fink, etc), I thought I'd back up and try something that has always worked. >>> >>> OK, sorry about the confusion. In the 3.2.3 configure.in file, we had >>> >>> AC_ARG_WITH(arpack, >>> [AS_HELP_STRING([--without-arpack], >>> [don't use ARPACK, disable some sparse functionality])], >>> with_arpack=$withval, with_arpack=yes) >>> >>> warn_arpack="arpack not found. This will result in a lack of the eigs function." >>> if test "$with_arpack" = yes; then >>> with_arpack=no >>> AC_CHECK_LIB(arpack, F77_FUNC(dseupd,DSEUPD), [ARPACK_LIBS="-larpack"; with_arpack=yes], , $LAPACK_LIBS $FLIBS) >>> if test "$with_arpack" = yes; then >>> AC_DEFINE(HAVE_ARPACK, 1, [Define if the ARPACK library is used.]) >>> warn_arpack= >>> fi >>> fi >>> if test -n "$warn_arpack"; then >>> AC_MSG_WARN($warn_arpack) >>> fi >>> >>> but given that earlier in the script we have >>> >>> ACX_LAPACK([BLAS_LIBS="$LAPACK_LIBS $BLAS_LIBS"], [LAPACK_DIR="lapack"]) >>> >>> I think the AC_CHECK_LIB macro should be using "$BLAS_LIBS" instead of >>> "$LAPACK_LIBS". >>> >>> jwe >> >> Replacing "$LAPACK_LIBS" with "$BLAS_LIBS" fixed the configure problem for me. >> >> I'll try "make" and report back. >> >> Ben > > My make failed with ... > > g++-4 -c -g -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 -Wall -W -Wshadow -Wold-style-cast -Wformat -g -I /sw/include -O3 pr-output.cc -o pic/pr-output.o > pr-output.cc: In function ?void set_format(const Complex&, int&, int&)?: > pr-output.cc:855: error: ?xr_abs? was not declared in this scope > make[2]: *** [pic/pr-output.o] Error 1 > make[1]: *** [src] Error 2 > make: *** [all] Error 2 > > I'm running gcc 4.4.2. > > Ben After looking a the c-code, and comparing to the repo, it appears that my copy of pr-output.cc had been modified or corrupted. I deleted and pulled a fresh copy. I'm now able to build 3.2.x. Ben From tmacchant at yahoo.co.jp Sat Nov 21 01:42:36 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sat, 21 Nov 2009 16:42:36 +0900 (JST) Subject: Print to PDF under Windows [changeset] In-Reply-To: Message-ID: <20091121074240.90341.qmail@web3809.mail.bbt.yahoo.co.jp> Hello Perhaps Ben's patch is better to be applied. However it is no effect for pdf printing on octave/MinGW32 on the OctaveForge because the gnuplot bundled supports the pdfcairo terminal and pdf printing seems to be carried out by it. Regards Tatsuro --- Ben Abbott wrote: > > On Nov 20, 2009, at 4:53 PM, Ben Abbott wrote: > > > On Nov 20, 2009, at 6:07 AM, Michael Goffioul wrote: > > > >> On Thu, Nov 19, 2009 at 9:45 PM, Ben Abbott wrote: > >>> On Thursday, November 19, 2009, at 03:39PM, "Michael Goffioul" > wrote: > >>>> Hi, > >>>> > >>>> In print.m, I see the following pieces of code: > >>>> > >>>> ... (line 194) > >>>> elseif (ispc ()) > >>>> if (~isempty (getenv ("GSC"))) > >>>> persistent ghostscript_binary = getenv ("GSC"); > >>>> else > >>>> persistent ghostscript_binary = "gswin32c"; > >>>> endif > >>>> ... > >>>> ... (line 265) > >>>> elseif (ispc ()) > >>>> [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1 > >>>> ) else ( exit /B 0 )", ghostscript_binary)); > >>>> have_ghostscript = (status ~= 0); > >>>> endif > >>>> ... > >>>> > >>>> Now, let's say GSC is not defined. How is this supposed to work? > >>>> The "system" call will check for the existence of a file named > >>>> "gswin32c" in the current directory. This will never work... or am > >>>> I missing something? > >>>> > >>>> Wouldn't it be better to default to > >>>> > >>>> persistent ghostscript_binary = file_in_path(EXEC_PATH, "gswin32c.exe"); > >>>> > >>>> Michael. > >>> > >>> I'd expect both to work. Unless the the windows binary bundles ghostscript with octave. Is > that the case? > >> > >> I don't get it. The line > >> > >> [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1) else > >> ( exit /B 0 )", ghostscript_binary)); > >> > >> will check for the existence of "gswin32c" in the current directory. > >> First, it should be "gswin32.exe". Second you will never have "gswin32c.exe" > >> in the current directory when using "print" in normal situation. > >> > >> Michael. > > > > Ok. I get it ... sorry for being so dense. > > > > I'll put together a changeset. > > > > Ben > > Michael or other Window users, > > Can you confirm the attached works? > > Ben > > > > > > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From tmacchant at yahoo.co.jp Sat Nov 21 02:42:29 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sat, 21 Nov 2009 17:42:29 +0900 (JST) Subject: Print to PDF under Windows [changeset] In-Reply-To: <20091121074240.90341.qmail@web3809.mail.bbt.yahoo.co.jp> Message-ID: <20091121084233.50256.qmail@web3801.mail.bbt.yahoo.co.jp> Hello I have tested http://gnuplot.sourceforge.net/development/binaries/ gp43-Nov21_2008-winbin.zip The gnuplot.exe in this Package does not support pdfcairo. However it does not any problem to make pdf file with out Ben's patch if the location of gswin32c.exe is included in the PATH environmental variable. The EXEC_PATH of octave add the Octave related PATHs to prior to the PATH environmental vairable. I cannot find reason why full path of ghostscript to be gotten. Without it, it works without problem. BTW in the ghostscript manual it is written ************** The actual executable files, in the gs#.##\bin subdirectory, are: GSWIN32C.EXE Ghostscript as a command line Windows program. This is usually the preferred executable. GSWIN32.EXE 32-bit Ghostscript using its own window for commands GSDLL32.DLL 32-bit dynamic link library containing most of Ghostscript's functionality **************** I do not find any reason why we should use GSWIN32.EXE but not GSWIN32C.EXE. Octave is win32 console application so that GSWIN32C.EXE is preferable, I think. If we use GSWIN32.EXE, we see always GSWIN32.EXE execution flash at each pdf creation. It would be annoying, I think. Regards Tatsuro --- Tatsuro MATSUOKA wrote: > Hello > > Perhaps Ben's patch is better to be applied. > However it is no effect for pdf printing on octave/MinGW32 on the OctaveForge because the > gnuplot > bundled supports the pdfcairo terminal and pdf printing seems to be carried out by it. > > Regards > > Tatsuro > > > > --- Ben Abbott wrote: > > > > > On Nov 20, 2009, at 4:53 PM, Ben Abbott wrote: > > > > > On Nov 20, 2009, at 6:07 AM, Michael Goffioul wrote: > > > > > >> On Thu, Nov 19, 2009 at 9:45 PM, Ben Abbott wrote: > > >>> On Thursday, November 19, 2009, at 03:39PM, "Michael Goffioul" > > > wrote: > > >>>> Hi, > > >>>> > > >>>> In print.m, I see the following pieces of code: > > >>>> > > >>>> ... (line 194) > > >>>> elseif (ispc ()) > > >>>> if (~isempty (getenv ("GSC"))) > > >>>> persistent ghostscript_binary = getenv ("GSC"); > > >>>> else > > >>>> persistent ghostscript_binary = "gswin32c"; > > >>>> endif > > >>>> ... > > >>>> ... (line 265) > > >>>> elseif (ispc ()) > > >>>> [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1 > > >>>> ) else ( exit /B 0 )", ghostscript_binary)); > > >>>> have_ghostscript = (status ~= 0); > > >>>> endif > > >>>> ... > > >>>> > > >>>> Now, let's say GSC is not defined. How is this supposed to work? > > >>>> The "system" call will check for the existence of a file named > > >>>> "gswin32c" in the current directory. This will never work... or am > > >>>> I missing something? > > >>>> > > >>>> Wouldn't it be better to default to > > >>>> > > >>>> persistent ghostscript_binary = file_in_path(EXEC_PATH, "gswin32c.exe"); > > >>>> > > >>>> Michael. > > >>> > > >>> I'd expect both to work. Unless the the windows binary bundles ghostscript with octave. Is > > that the case? > > >> > > >> I don't get it. The line > > >> > > >> [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1) else > > >> ( exit /B 0 )", ghostscript_binary)); > > >> > > >> will check for the existence of "gswin32c" in the current directory. > > >> First, it should be "gswin32.exe". Second you will never have "gswin32c.exe" > > >> in the current directory when using "print" in normal situation. > > >> > > >> Michael. > > > > > > Ok. I get it ... sorry for being so dense. > > > > > > I'll put together a changeset. > > > > > > Ben > > > > Michael or other Window users, > > > > Can you confirm the attached works? > > > > Ben > > > > > > > > > > > > > > -------------------------------------- > GyaO! - Anime, Dramas, Movies, and Music videos [FREE] > http://pr.mail.yahoo.co.jp/gyao/ > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From tmacchant at yahoo.co.jp Sat Nov 21 03:37:53 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sat, 21 Nov 2009 18:37:53 +0900 (JST) Subject: Chageset for delting the check for pgnuplot for developmet branch source trees Message-ID: <20091121093757.92321.qmail@web3815.mail.bbt.yahoo.co.jp> Hello I have proposed to delete check for pgnuplot for octave 3.2.4 as, http://old.nabble.com/Re:-3.2.4-call-for-patches-p26452663.html This changeset is for the development branch for the same purpose. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ -------------- next part -------------- A non-text attachment was scrubbed... Name: develop.pgnuplot.changeset Type: application/x-unknown Size: 844 bytes Desc: 1360441299-develop.pgnuplot.changeset Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091121/81ce975e/attachment.bin From lindnerben at gmx.net Sat Nov 21 08:06:57 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sat, 21 Nov 2009 15:06:57 +0100 Subject: Print to PDF under Windows In-Reply-To: <128f38bd0911200307q4fb1d13eu27e9d99ef2a98bae@mail.gmail.com> References: <128f38bd0911191239r443321dao240b01ab66bb9e35@mail.gmail.com> <137439832808707203260296105367491456037-Webmail@me.com> <128f38bd0911200307q4fb1d13eu27e9d99ef2a98bae@mail.gmail.com> Message-ID: <4B07F401.2020606@gmx.net> > > I don't get it. The line > > [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1) else > ( exit /B 0 )", ghostscript_binary)); > > will check for the existence of "gswin32c" in the current directory. > First, it should be "gswin32.exe". No, the console version of ghostscript is called "gswin32c.exe" Why should one use the GUI version (which is called "gswin32.exe")? Especially if perhaps commands are piped to it? benjamin From lindnerben at gmx.net Sat Nov 21 08:15:07 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sat, 21 Nov 2009 15:15:07 +0100 Subject: Print to PDF under Windows [changeset] In-Reply-To: References: <128f38bd0911191239r443321dao240b01ab66bb9e35@mail.gmail.com> <137439832808707203260296105367491456037-Webmail@me.com> <128f38bd0911200307q4fb1d13eu27e9d99ef2a98bae@mail.gmail.com> <589FBB87-7246-40CA-BD35-B90A38F799C6@mac.com> Message-ID: <4B07F5EB.9090202@gmx.net> > > Michael or other Window users, > > Can you confirm the attached works? > > Ben The console version of ghostscript on win32 is called "gswin32c.exe". There is also a GUI version, which is called "gswin32.exe". I don't see the reason for using the gui version. What if you want to pipe commands to ghostscript? If one insists on using the GUI version, well then you can specify it in GSC anyway, but in my opinion the correct version to use by default is the console version. Hence "gswin32c.exe" benjamin From bpabbott at mac.com Sat Nov 21 09:05:08 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sat, 21 Nov 2009 10:05:08 -0500 Subject: Print to PDF under Windows [changeset-2] In-Reply-To: <4B07F5EB.9090202@gmx.net> References: <128f38bd0911191239r443321dao240b01ab66bb9e35@mail.gmail.com> <137439832808707203260296105367491456037-Webmail@me.com> <128f38bd0911200307q4fb1d13eu27e9d99ef2a98bae@mail.gmail.com> <589FBB87-7246-40CA-BD35-B90A38F799C6@mac.com> <4B07F5EB.9090202@gmx.net> Message-ID: On Nov 21, 2009, at 9:15 AM, Benjamin Lindner wrote: >> Michael or other Window users, >> Can you confirm the attached works? >> Ben > > The console version of ghostscript on win32 is called "gswin32c.exe". > There is also a GUI version, which is called "gswin32.exe". > I don't see the reason for using the gui version. What if you want to > pipe commands to ghostscript? > > If one insists on using the GUI version, well then you can specify > it in GSC anyway, but in my opinion the correct version to use > by default is the console version. Hence "gswin32c.exe" > > benjamin Ok, my understanding is that EXEC_PATH is equivalent to the PATH environment variable that was in place when Octave was run. Which is likely to include the default shell's PATH as well as additions needed to run Octave. In the event ghostscript is bundled with Octave, then EXEC_PATH is preferred over PATH. The attached changeset looks for the console version of ghostscript, "gswin32c.exe", and still searches EXEC_PATH for gswin32c.exe. Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: changeset.patch Type: application/octet-stream Size: 1122 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091121/73c56e1d/attachment.obj From lindnerben at gmx.net Sat Nov 21 10:05:49 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sat, 21 Nov 2009 17:05:49 +0100 Subject: finally actually using gnulib In-Reply-To: <19205.48485.939413.654792@segfault.lan> References: <19198.60584.771475.300423@segfault.lan> <4AFEFF11.1070906@gmx.net> <420fb9e60911141224p3adbee11od4d35824be82779f@mail.gmail.com> <4AFF17FD.8000008@gmx.net> <4B059EDF.5070606@gmx.net> <19205.48485.939413.654792@segfault.lan> Message-ID: <4B080FDD.3030806@gmx.net> John W. Eaton wrote: > On 19-Nov-2009, Benjamin Lindner wrote: > > | Benjamin Lindner wrote: > | > > | > Thanks for this hint. > | > This is probably the fastest way to get it testing. > | > | I am probably missing something trivial or simply doing something > | stupid. > | > | I downloaded a gnulib snapshot, and from a cloned hg repos, with > | john's patch imported, executed > | > | $ ./autogen.sh --gnulib-srcdir=/octmgw32/octave/gnulib > | generating source lists for liboctave/Makefile... > | vx-op-inc.mk is unchanged > | mx-op-inc.mk is unchanged > | smx-op-inc.mk is unchanged > | vx-op-src.mk is unchanged > | mx-op-src.mk is unchanged > | smx-op-src.mk is unchanged > | generating doc/interpreter/images.mk... > | images.mk is unchanged > | generating src/DLD-FUNCTIONS/module.mk... > | module.mk is unchanged > | bootstrapping... > | ./bootstrap: one of these is required: sha1sum gsha1sum > > The sha1sum program is part of GNU coreutils. But it looks like the > bootstrap script only uses it if there are .po files to update (we > don't have any), so I > don't think we really need it. What happenss if you comment out the > > find_tool SHA1SUM sha1sum gsha1sum > > line in the bootstrap script? Does it work then? I used sha1sum from http://lists.gnupg.org/pipermail/gnupg-announce/2004q4/000184.html but apparently this one does not work. Then I saw that msys distributes coreutils in two parts, and sha1sum is in the second part, which I did not have installed. Now it works. > Also, if you see a message about no libgnu/gnulib.mk file, you will > need to create a file called libgnu/Makefile.am with the contents > > include gnulib.mk > > before running autogen.sh. I think that filewas accidentally left out > of my previous patch. thanks for this info. bootstrap, autoconf-ing and configure complete fine. During building I get the following two errors ../../run-octave -f -q -H /octmgw32/octave/octave-tip-automake/doc/interpreter/mk_doc_cache.m doc-cache ../../src/DOCSTRINGS ../../scripts/DOCSTRINGS || rm -f doc-cache error: : mkstemp: not supported on this sytem and make[2]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2' make[2]: *** No rule to make target `mkoctfile.exe', needed by `all-am'. Stop. benjamin From lindnerben at gmx.net Sat Nov 21 10:05:57 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sat, 21 Nov 2009 17:05:57 +0100 Subject: Print to PDF under Windows [changeset-2] In-Reply-To: References: <128f38bd0911191239r443321dao240b01ab66bb9e35@mail.gmail.com> <137439832808707203260296105367491456037-Webmail@me.com> <128f38bd0911200307q4fb1d13eu27e9d99ef2a98bae@mail.gmail.com> <589FBB87-7246-40CA-BD35-B90A38F799C6@mac.com> <4B07F5EB.9090202@gmx.net> Message-ID: <4B080FE5.9080001@gmx.net> Ben Abbott wrote: > Ok, my understanding is that EXEC_PATH is equivalent to the PATH environment variable that was in place when Octave was run. Which is likely to include the default shell's PATH as well as additions needed to run Octave. In the event ghostscript is bundled with Octave, then EXEC_PATH is preferred over PATH. I see your point. It's currently not bundled, but maybe will be > The attached changeset looks for the console version of ghostscript, "gswin32c.exe", and still searches EXEC_PATH for gswin32c.exe. looks fine to me. Although I haven't checked in action yet, as I'm working on getting the build process to run again. benjamin From jwe at octave.org Sat Nov 21 10:14:21 2009 From: jwe at octave.org (John W. Eaton) Date: Sat, 21 Nov 2009 11:14:21 -0500 Subject: finally actually using gnulib In-Reply-To: <4B080FDD.3030806@gmx.net> References: <19198.60584.771475.300423@segfault.lan> <4AFEFF11.1070906@gmx.net> <420fb9e60911141224p3adbee11od4d35824be82779f@mail.gmail.com> <4AFF17FD.8000008@gmx.net> <4B059EDF.5070606@gmx.net> <19205.48485.939413.654792@segfault.lan> <4B080FDD.3030806@gmx.net> Message-ID: <19208.4573.362823.144589@segfault.lan> On 21-Nov-2009, Benjamin Lindner wrote: | I used sha1sum from | http://lists.gnupg.org/pipermail/gnupg-announce/2004q4/000184.html | but apparently this one does not work. | Then I saw that msys distributes coreutils in two parts, and sha1sum | is in the second part, which I did not have installed. | Now it works. | | > Also, if you see a message about no libgnu/gnulib.mk file, you will | > need to create a file called libgnu/Makefile.am with the contents | > | > include gnulib.mk | > | > before running autogen.sh. I think that filewas accidentally left out | > of my previous patch. | | thanks for this info. | bootstrap, autoconf-ing and configure complete fine. That's good news. Thanks for working on this. | During building I get the following two errors | | ../../run-octave -f -q -H | /octmgw32/octave/octave-tip-automake/doc/interpreter/mk_doc_cache.m | doc-cache ../../src/DOCSTRINGS ../../scripts/DOCSTRINGS || rm -f doc-cache | error: : mkstemp: not supported on this sytem I think we can fix this problem by using the mkstemp function that gnulib provides. Or, you can try modifying this code in src/file-io.cc: #if defined (HAVE_MKSTEMPS) // Prototype for mkstemps in libiberty extern "C" int mkstemps (char *pattern, int suffix_len); #endif #if ! defined (HAVE_MKSTEMP) && ! defined (HAVE_MKSTEMPS) && defined (_MSC_VER) # if defined (HAVE_FCNTL_H) # include # endif # if defined (HAVE_SYS_STAT_H) # include # endif int mkstemp (char *tmpl) { int ret=-1; mktemp (tmpl); ret = open (tmpl, O_RDWR | O_BINARY | O_CREAT | O_EXCL | _O_SHORT_LIVED, _S_IREAD | _S_IWRITE); return ret; } #define HAVE_MKSTEMP 1 #endif I don't see why it should be restricted to just _MSC_VER. It looks to me like it should work on any system that has the open system call and all the needed O_x, _O_x, and _S_x macros defined. | make[2]: Entering directory | `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2' | make[2]: *** No rule to make target `mkoctfile.exe', needed by `all-am'. | Stop. At what point in the build process did this error occur? jwe From bpabbott at mac.com Sat Nov 21 10:17:30 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sat, 21 Nov 2009 11:17:30 -0500 Subject: Print to PDF under Windows [changeset-2] In-Reply-To: <4B080FE5.9080001@gmx.net> References: <128f38bd0911191239r443321dao240b01ab66bb9e35@mail.gmail.com> <137439832808707203260296105367491456037-Webmail@me.com> <128f38bd0911200307q4fb1d13eu27e9d99ef2a98bae@mail.gmail.com> <589FBB87-7246-40CA-BD35-B90A38F799C6@mac.com> <4B07F5EB.9090202@gmx.net> <4B080FE5.9080001@gmx.net> Message-ID: <3F154C90-E21E-4A05-A3A8-8E2CADA737ED@mac.com> On Nov 21, 2009, at 11:05 AM, Benjamin Lindner wrote: > Ben Abbott wrote: > >> Ok, my understanding is that EXEC_PATH is equivalent to the PATH environment variable that was in place when Octave was run. Which is likely to include the default shell's PATH as well as additions needed to run Octave. In the event ghostscript is bundled with Octave, then EXEC_PATH is preferred over PATH. > > I see your point. > It's currently not bundled, but maybe will be > >> The attached changeset looks for the console version of ghostscript, "gswin32c.exe", and still searches EXEC_PATH for gswin32c.exe. > > looks fine to me. > Although I haven't checked in action yet, as I'm working on getting > the build process to run again. > > benjamin I'm also not able to build the developers sources at the moment. So I'm testing m-files under 3.2.3. Can you/somone-else test this changeset under 3.2.3? TiA Ben From lindnerben at gmx.net Sat Nov 21 11:10:26 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sat, 21 Nov 2009 18:10:26 +0100 Subject: finally actually using gnulib In-Reply-To: <19208.4573.362823.144589@segfault.lan> References: <19198.60584.771475.300423@segfault.lan> <4AFEFF11.1070906@gmx.net> <420fb9e60911141224p3adbee11od4d35824be82779f@mail.gmail.com> <4AFF17FD.8000008@gmx.net> <4B059EDF.5070606@gmx.net> <19205.48485.939413.654792@segfault.lan> <4B080FDD.3030806@gmx.net> <19208.4573.362823.144589@segfault.lan> Message-ID: <4B081F02.2030406@gmx.net> > | During building I get the following two errors > | > | ../../run-octave -f -q -H > | /octmgw32/octave/octave-tip-automake/doc/interpreter/mk_doc_cache.m > | doc-cache ../../src/DOCSTRINGS ../../scripts/DOCSTRINGS || rm -f doc-cache > | error: : mkstemp: not supported on this sytem > > I think we can fix this problem by using the mkstemp function that > gnulib provides. Or, you can try modifying this code in > src/file-io.cc: > > #if defined (HAVE_MKSTEMPS) > // Prototype for mkstemps in libiberty > extern "C" int mkstemps (char *pattern, int suffix_len); > #endif > > #if ! defined (HAVE_MKSTEMP) && ! defined (HAVE_MKSTEMPS) && defined (_MSC_VER) > # if defined (HAVE_FCNTL_H) > # include > # endif > # if defined (HAVE_SYS_STAT_H) > # include > # endif > int mkstemp (char *tmpl) > { > int ret=-1; > mktemp (tmpl); > ret = open (tmpl, O_RDWR | O_BINARY | O_CREAT | O_EXCL | _O_SHORT_LIVED, > _S_IREAD | _S_IWRITE); > return ret; > } > #define HAVE_MKSTEMP 1 > #endif > > I don't see why it should be restricted to just _MSC_VER. It looks to > me like it should work on any system that has the open system call and > all the needed O_x, _O_x, and _S_x macros defined. > No, mingw's gcc provides the required function in -liberty. There's a check for this in configure, but I see in the log file that it fails. I don't know what has been changed in configure, but the problem is the wrong declaration in the test code. configure:47870: checking for mkstemps in libiberty configure:47905: mingw32-g++-4.4.0-dw2 -shared-libgcc -o conftest.exe -march=i686 -mtune=generic -O3 -Wall -I/usr/local/octmgw32_gcc-4.4.0-dw2/include -shared-libgcc -Wl,--allow-multiple-definition conftest.cpp -liberty -lm -lfreetype -lz -lopengl32 -lglu32 -lgdi32 -lws2_32 -luser32 -lkernel32 >&5 onftest.cpp: In function 'int main()': conftest.cpp:212: warning: deprecated conversion from string constant to 'char*' C:\Users\ben\LOCALS~1\Temp\ccwNHOio.o:conftest.cpp:(.text+0x1e): undefined reference to `mkstemps(char*, int)' collect2: ld returned 1 exit status configure:47912: $? = 1 configure: failed program was: | | | int mkstemps (char *pattern, int suffix_len); | #ifdef F77_DUMMY_MAIN | | # ifdef __cplusplus | extern "C" | # endif | int F77_DUMMY_MAIN() { return 1; } | | #endif | int | main () | { | mkstemps ("XXXXXX", 0); | | ; | return 0; | } Since g++ is used for compiling the test code, mkstemps' declaration is missing a extern "C" as it is a C-Function in -liberty. If I compare it to config.log from octave 3.2.3, I see that there it reads: configure:27134: checking for mkstemps in libiberty configure:27169: mingw32-gcc-4.4.0-dw2 -o conftest.exe -march=i686 -mtune=generic -O3 -Wall -shared-libgcc -Wl,--allow-multiple-definition conftest.c -liberty -lhdf5 -lz -lm -lgdi32 -lws2_32 -luser32 -lkernel32 >&5 configure:27176: $? = 0 configure:27184: result: yes So here gcc is used, in contrast to g++ above. I don't see why it picks a different compiler here. > | make[2]: Entering directory > | `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2' > | make[2]: *** No rule to make target `mkoctfile.exe', needed by `all-am'. > | Stop. > > At what point in the build process did this error occur? > The make transcript reads $ ./build-testautomake-4.sh build build time make -j8 making run-octave from /octmgw32/octave/octave-tip-automake/run-octave.in run-octave is unchanged chmod a+rx "run-octave" make all-recursive make[1]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2' Making all in libgnu make[2]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libgnu' make all-recursive make[3]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libgnu' make[4]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libgnu' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libgnu' make[3]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libgnu' make[2]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libgnu' Making all in libcruft make[2]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/libcruft' Making all in liboctave make[2]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/liboctave' make all-am make[3]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/liboctave' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/liboctave' make[2]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/liboctave' Making all in src make[2]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src' making defaults.h from /octmgw32/octave/octave-tip-automake/src/defaults.h.in defaults.h is unchanged make all-am make[3]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src' making defaults.h from /octmgw32/octave/octave-tip-automake/src/defaults.h.in defaults.h is unchanged rm -f DLD-FUNCTIONS/daspk.oct rm -f DLD-FUNCTIONS/eig.oct rm -f DLD-FUNCTIONS/find.oct la=`echo DLD-FUNCTIONS/daspk.la | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ of=`echo DLD-FUNCTIONS/daspk.oct | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ cd DLD-FUNCTIONS && \ ln -s .libs/`/usr/bin/sed -n -e "s/dlname='\([^']*\)'/\1/p" < $la` $of rm -f DLD-FUNCTIONS/fltk_backend.oct la=`echo DLD-FUNCTIONS/eig.la | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ of=`echo DLD-FUNCTIONS/eig.oct | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ cd DLD-FUNCTIONS && \ ln -s .libs/`/usr/bin/sed -n -e "s/dlname='\([^']*\)'/\1/p" < $la` $of la=`echo DLD-FUNCTIONS/find.la | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ of=`echo DLD-FUNCTIONS/find.oct | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ cd DLD-FUNCTIONS && \ ln -s .libs/`/usr/bin/sed -n -e "s/dlname='\([^']*\)'/\1/p" < $la` $of la=`echo DLD-FUNCTIONS/fltk_backend.la | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ of=`echo DLD-FUNCTIONS/fltk_backend.oct | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ cd DLD-FUNCTIONS && \ ln -s .libs/`/usr/bin/sed -n -e "s/dlname='\([^']*\)'/\1/p" < $la` $of rm -f DLD-FUNCTIONS/hess.oct rm -f DLD-FUNCTIONS/md5sum.oct rm -f DLD-FUNCTIONS/pinv.oct rm -f DLD-FUNCTIONS/sparse.oct la=`echo DLD-FUNCTIONS/hess.la | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ of=`echo DLD-FUNCTIONS/hess.oct | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ cd DLD-FUNCTIONS && \ ln -s .libs/`/usr/bin/sed -n -e "s/dlname='\([^']*\)'/\1/p" < $la` $of la=`echo DLD-FUNCTIONS/md5sum.la | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ of=`echo DLD-FUNCTIONS/md5sum.oct | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ cd DLD-FUNCTIONS && \ ln -s .libs/`/usr/bin/sed -n -e "s/dlname='\([^']*\)'/\1/p" < $la` $of la=`echo DLD-FUNCTIONS/pinv.la | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ of=`echo DLD-FUNCTIONS/pinv.oct | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ cd DLD-FUNCTIONS && \ ln -s .libs/`/usr/bin/sed -n -e "s/dlname='\([^']*\)'/\1/p" < $la` $of la=`echo DLD-FUNCTIONS/sparse.la | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ of=`echo DLD-FUNCTIONS/sparse.oct | /usr/bin/sed 's,DLD-FUNCTIONS/,,'` && \ cd DLD-FUNCTIONS && \ ln -s .libs/`/usr/bin/sed -n -e "s/dlname='\([^']*\)'/\1/p" < $la` $of make[3]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src' make[2]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/src' Making all in scripts make[2]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/scripts' making plot/gnuplot_binary.m from /octmgw32/octave/octave-tip-automake/scripts/plot/gnuplot_binary.in plot/gnuplot_binary.m is unchanged make[2]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/scripts' Making all in doc make[2]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/doc' Making all in faq make[3]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/doc/faq' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/doc/faq' Making all in interpreter make[3]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/doc/interpreter' ../../run-octave -f -q -H /octmgw32/octave/octave-tip-automake/doc/interpreter/mk_doc_cache.m doc-cache ../../src/DOCSTRINGS ../../scripts/DOCSTRINGS || rm -f doc-cache error: : mkstemp: not supported on this sytem make[3]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/doc/interpreter' Making all in liboctave make[3]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/doc/liboctave' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/doc/liboctave' Making all in refcard make[3]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/doc/refcard' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/doc/refcard' make[3]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/doc' making conf.texi from /octmgw32/octave/octave-tip-automake/doc/conf.texi.in /bin/sh: line 0: cd: /usr/local/octmgw32_gcc-4.4.0-dw2/octave/tip-automake-4: No such file or directory if [ -s conf.texi-t ]; then /octmgw32/octave/octave-tip-automake/move-if-change conf.texi-t conf.texi; else echo "conf.texi-t is empty!" 1>&2; rm -f conf.texi-t; exit 1; fi conf.texi is unchanged make[3]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/doc' make[2]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/doc' Making all in examples make[2]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/examples' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/examples' Making all in test make[2]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/test' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2/test' make[2]: Entering directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2' make[2]: *** No rule to make target `mkoctfile.exe', needed by `all-am'. Stop. make[2]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/octmgw32/octave/.build_mingw32_octave-tip-automake-4_gcc-4.4.0-dw2' make: *** [all] Error 2 benjamin From michael.goffioul at gmail.com Sat Nov 21 11:39:02 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Sat, 21 Nov 2009 17:39:02 +0000 Subject: Print to PDF under Windows In-Reply-To: <4B07F401.2020606@gmx.net> References: <128f38bd0911191239r443321dao240b01ab66bb9e35@mail.gmail.com> <137439832808707203260296105367491456037-Webmail@me.com> <128f38bd0911200307q4fb1d13eu27e9d99ef2a98bae@mail.gmail.com> <4B07F401.2020606@gmx.net> Message-ID: <128f38bd0911210939k6f26db86h894685126f8619cc@mail.gmail.com> On Sat, Nov 21, 2009 at 2:06 PM, Benjamin Lindner wrote: >> >> I don't get it. The line >> >> [status, output] = system (sprintf ("if exist \"%s\" ( exit /B 1) else >> ( exit /B 0 )", ghostscript_binary)); >> >> will check for the existence of "gswin32c" in the current directory. >> First, it should be "gswin32.exe". > > No, the console version of ghostscript is called "gswin32c.exe" > Why should one use the GUI version (which is called "gswin32.exe")? > Especially if perhaps commands are piped to it? Sorry, typo. My point was to emphasize the .exe suffix. It sould be indeed gswin32c.exe. Michael. From michael.goffioul at gmail.com Sat Nov 21 11:43:44 2009 From: michael.goffioul at gmail.com (Michael Goffioul) Date: Sat, 21 Nov 2009 17:43:44 +0000 Subject: Print to PDF under Windows [changeset] In-Reply-To: <4B07F5EB.9090202@gmx.net> References: <128f38bd0911191239r443321dao240b01ab66bb9e35@mail.gmail.com> <137439832808707203260296105367491456037-Webmail@me.com> <128f38bd0911200307q4fb1d13eu27e9d99ef2a98bae@mail.gmail.com> <589FBB87-7246-40CA-BD35-B90A38F799C6@mac.com> <4B07F5EB.9090202@gmx.net> Message-ID: <128f38bd0911210943w6445736ep68bbd31286bf5947@mail.gmail.com> On Sat, Nov 21, 2009 at 2:15 PM, Benjamin Lindner wrote: >> >> Michael or other Window users, >> >> Can you confirm the attached works? >> >> Ben > > The console version of ghostscript on win32 is called "gswin32c.exe". > There is also a GUI version, which is called "gswin32.exe". > I don't see the reason for using the gui version. What if you want to > pipe commands to ghostscript? > > If one insists on using the GUI version, well then you can specify > it in GSC anyway, but in my opinion the correct version to use > by default is the console version. Hence "gswin32c.exe" Sorry, there has been some misunderstanding here. The problems I wanted to point out are: 1) the missing ".exe" suffix 2) "if exist gswin32c.exe (... do something...)" will not work if gswin32c.exe is not in the current directory. For instance, try this in a cmd prompt: if exist notepad.exe (echo "hello") this only works when the current directory is C:\WINDOWS\system32. So the above is really not equivalent to "which gswin32c.exe". Michael. From lindnerben at gmx.net Sat Nov 21 11:56:18 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sat, 21 Nov 2009 18:56:18 +0100 Subject: finally actually using gnulib In-Reply-To: <4B081F02.2030406@gmx.net> References: <19198.60584.771475.300423@segfault.lan> <4AFEFF11.1070906@gmx.net> <420fb9e60911141224p3adbee11od4d35824be82779f@mail.gmail.com> <4AFF17FD.8000008@gmx.net> <4B059EDF.5070606@gmx.net> <19205.48485.939413.654792@segfault.lan> <4B080FDD.3030806@gmx.net> <19208.4573.362823.144589@segfault.lan> <4B081F02.2030406@gmx.net> Message-ID: <4B0829C2.2010007@gmx.net> Benjamin Lindner wrote: > I don't see why it picks a different compiler here. Aha, there is an unmatched AC_LANG_PUSH(C++) in configure.ac If I remove it, then the check succeeds. I am not sure if it is the right thing to so, though diff -r 4664de8669b2 configure.ac --- a/configure.ac Thu Nov 19 20:34:21 2009 +0100 +++ b/configure.ac Sat Nov 21 18:54:29 2009 +0100 @@ -757,7 +757,6 @@ AC_CHECK_FT2([9.0.3],[AC_DEFINE(HAVE_FREETYPE, 1, [Define to 1 if you have Freetype library.])], [warn_freetype="FreeType library not found. Native renderer will not have on-screen text"]) if test -z "$warn_freetype"; then - AC_LANG_PUSH(C++) save_LIBS="$LIBS" save_CXXFLAGS="$CXXFLAGS" save_CPPFLAGS="$CPPFLAGS" benjamin From lindnerben at gmx.net Sat Nov 21 12:14:07 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sat, 21 Nov 2009 19:14:07 +0100 Subject: Print to PDF under Windows [changeset] In-Reply-To: <128f38bd0911210943w6445736ep68bbd31286bf5947@mail.gmail.com> References: <128f38bd0911191239r443321dao240b01ab66bb9e35@mail.gmail.com> <137439832808707203260296105367491456037-Webmail@me.com> <128f38bd0911200307q4fb1d13eu27e9d99ef2a98bae@mail.gmail.com> <589FBB87-7246-40CA-BD35-B90A38F799C6@mac.com> <4B07F5EB.9090202@gmx.net> <128f38bd0911210943w6445736ep68bbd31286bf5947@mail.gmail.com> Message-ID: <4B082DEF.3080406@gmx.net> Michael Goffioul wrote: > On Sat, Nov 21, 2009 at 2:15 PM, Benjamin Lindner wrote: >>> Michael or other Window users, >>> >>> Can you confirm the attached works? >>> >>> Ben >> The console version of ghostscript on win32 is called "gswin32c.exe". >> There is also a GUI version, which is called "gswin32.exe". >> I don't see the reason for using the gui version. What if you want to >> pipe commands to ghostscript? >> >> If one insists on using the GUI version, well then you can specify >> it in GSC anyway, but in my opinion the correct version to use >> by default is the console version. Hence "gswin32c.exe" > > Sorry, there has been some misunderstanding here. The problems > I wanted to point out are: > 1) the missing ".exe" suffix > 2) "if exist gswin32c.exe (... do something...)" will not work if > gswin32c.exe is not in the current directory. For instance, try this > in a cmd prompt: > > if exist notepad.exe (echo "hello") > > this only works when the current directory is C:\WINDOWS\system32. > So the above is really not equivalent to "which gswin32c.exe". > Sorry, misinterpretation on my side. Yes, of course, you are right in both points. Thanks for pointing them out! benjamin From tmacchant at yahoo.co.jp Sat Nov 21 16:03:37 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sun, 22 Nov 2009 07:03:37 +0900 (JST) Subject: libtool build of development source on mingw : libstdc++.dll.a: No such file or directory Message-ID: <20091121220337.17002.qmail@web3810.mail.bbt.yahoo.co.jp> Hello This is first time try to build octave on mingw using libtool. I have encounter the error at linking libcruft. ***************** libtool: link: g++ -shared-libgcc -D_DLL -DPIC -shared -nostdlib .......... ....../mingw/lib/gcc/mingw32/4.4.0/libstdc++.dll.a -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt c:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0/crtend.o -mieee-fp -o .libs/libcruft-3-3-50+.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libcruft.dll.a g++.exe: c:/Programs/MinGW/lib/gcc/mingw32/4.4.0/libstdc++.dll.a: No such file or directory make[2]: *** [libcruft.la] Error 1 make[2]: Leaving directory `/home/octaves/OctBuild/octave-develop/libcruft' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/octaves/OctBuild/octave-develop' make: *** [all] Error 2 ******************** There is no c:/Programs/MinGW/lib/gcc/mingw32/4.4.0/libstdc++.dll.a. The library file'libstdc++_s.a' is the correct library file for shared building for MinGW gcc complier. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From tmacchant at yahoo.co.jp Sat Nov 21 16:42:42 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sun, 22 Nov 2009 07:42:42 +0900 (JST) Subject: OCTAVE_PROG_GHOSTSCRIPT for windows Message-ID: <20091121224242.3866.qmail@web3804.mail.bbt.yahoo.co.jp> Hello In 'acinclude.m4' in the development source, I found dnl OCTAVE_PROG_GHOSTSCRIPT AC_DEFUN([OCTAVE_PROG_GHOSTSCRIPT], [ case "$canonical_host_type" in *-*-cygwin* | *-*-mingw32* | *-*-msdosmsvc) gs_names="gs gswin32" ;; *) gs_names=gs ;; esac ********** In Cygwin, is gs_names="gs gswin32" required? On cygwin, I am using 'gs.exe' on cygwin. gs_names="gs gswin32" Is it better to be gs_names="gs gswin32c" This has been discussed in quite recently for pdf printing on windows. http://old.nabble.com/Print-to-PDF-under-Windows-to26433734.html Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From bpabbott at mac.com Sat Nov 21 18:01:49 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sat, 21 Nov 2009 19:01:49 -0500 Subject: OCTAVE_PROG_GHOSTSCRIPT for windows In-Reply-To: <20091121224242.3866.qmail@web3804.mail.bbt.yahoo.co.jp> References: <20091121224242.3866.qmail@web3804.mail.bbt.yahoo.co.jp> Message-ID: <6580A36A-51FF-4CA5-9D87-09667143F452@mac.com> On Nov 21, 2009, at 5:42 PM, Tatsuro MATSUOKA wrote: > Hello > > > In 'acinclude.m4' in the development source, I found > > dnl OCTAVE_PROG_GHOSTSCRIPT > AC_DEFUN([OCTAVE_PROG_GHOSTSCRIPT], [ > case "$canonical_host_type" in > *-*-cygwin* | *-*-mingw32* | *-*-msdosmsvc) > gs_names="gs gswin32" > ;; > *) > gs_names=gs > ;; > esac > ********** > In Cygwin, is gs_names="gs gswin32" required? On cygwin, I am using 'gs.exe' on cygwin. > > > gs_names="gs gswin32" > > Is it better to be > gs_names="gs gswin32c" > > This has been discussed in quite recently for pdf printing on windows. > > http://old.nabble.com/Print-to-PDF-under-Windows-to26433734.html > > Regards For the print() function, should we look for "gs.exe" if the "gswin32c.exe" is not found? Ben From bpabbott at mac.com Sat Nov 21 19:44:44 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sat, 21 Nov 2009 20:44:44 -0500 Subject: build trouble on MacOS 10.5 Message-ID: The build looks good until Octave is run. Making all in interpreter ../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'txt');" make[3]: *** [voronoi.txt] Bus error make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 When I try to run octave ... > $ ./run-octave > Bus error >From the gdb > .warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/loaders/.libs/libltdl_libltdl_la-preopen.o" - no debug information available for "libltdl/loaders/preopen.c". > > warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/libltdl_libltdl_la-lt__alloc.o" - no debug information available for "libltdl/lt__alloc.c". > > warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/libltdl_libltdl_la-lt_dlloader.o" - no debug information available for "libltdl/lt_dlloader.c". > > warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/libltdl_libltdl_la-lt_error.o" - no debug information available for "libltdl/lt_error.c". > > warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/libltdl_libltdl_la-ltdl.o" - no debug information available for "libltdl/ltdl.c". > > warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/libltdl_libltdl_la-slist.o" - no debug information available for "libltdl/slist.c". > > warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/argz.o" - no debug information available for "libltdl/argz.c". > > warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/libltdlS.o" - no debug information available for "libltdlS.c". > > warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/libltdl.lax/dlopen.a/dlopen.o" - no debug information available for "libltdl/loaders/dlopen.c". > > ..................................... done > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 > 0x02c0702f in std::locale::operator= () > (gdb) > (gdb) bt > No stack. I thought the problem might have to do with linking to a bad library, so I hope to use the Mac OSX alternative to ldd to track it down ... > $ otool -L ./src/octave > ./src/octave: is not an object file As I'm not having any trouble compiling fortran programs and/or libraries, I tried ... > $ otool -L ./libcruft/odepack/vnorm.lo > ./libcruft/odepack/vnorm.lo: is not an object file And then the actual fortran object file. > $ otool -L ./libcruft/odepack/.libs/vnorm.o > ./libcruft/odepack/.libs/vnorm.o: I have two questions. (1) Does anyone have any insight / advice? (2) Are there any Mac OSX who have been successful building the current sources? Ben From jwe at octave.org Sat Nov 21 20:07:39 2009 From: jwe at octave.org (John W. Eaton) Date: Sat, 21 Nov 2009 21:07:39 -0500 Subject: build trouble on MacOS 10.5 In-Reply-To: References: Message-ID: <19208.40171.911211.78147@segfault.lan> On 21-Nov-2009, Ben Abbott wrote: | I thought the problem might have to do with linking to a bad library, so I hope to use the Mac OSX alternative to ldd to track it down ... | | > $ otool -L ./src/octave | > ./src/octave: is not an object file That's a script, generated by libtool. Try this instead in the top-level directory in your build tree: ./libtool --mode execute ldd src/octave jwe From jwe at octave.org Sat Nov 21 20:09:48 2009 From: jwe at octave.org (John W. Eaton) Date: Sat, 21 Nov 2009 21:09:48 -0500 Subject: build trouble on MacOS 10.5 In-Reply-To: References: Message-ID: <19208.40300.113031.396400@segfault.lan> On 21-Nov-2009, Ben Abbott wrote: | The build looks good until Octave is run. | | Making all in interpreter | ../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'txt');" | make[3]: *** [voronoi.txt] Bus error | make[2]: *** [all-recursive] Error 1 | make[1]: *** [all-recursive] Error 1 | make: *** [all] Error 2 | | When I try to run octave ... | | > $ ./run-octave | > Bus error | | >From the gdb | | > .warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/loaders/.libs/libltdl_libltdl_la-preopen.o" - no debug information available for "libltdl/loaders/preopen.c". I don't understand why libltdl is being used. Octave should still be using dlopen directly, not libtool's libltdl interface. jwe From jwe at octave.org Sat Nov 21 20:14:52 2009 From: jwe at octave.org (John W. Eaton) Date: Sat, 21 Nov 2009 21:14:52 -0500 Subject: libtool build of development source on mingw : libstdc++.dll.a: No such file or directory In-Reply-To: <20091121220337.17002.qmail@web3810.mail.bbt.yahoo.co.jp> References: <20091121220337.17002.qmail@web3810.mail.bbt.yahoo.co.jp> Message-ID: <19208.40604.158846.2688@segfault.lan> On 22-Nov-2009, Tatsuro MATSUOKA wrote: | Hello | | This is first time try to build octave on mingw using libtool. | | I have encounter the error at linking libcruft. | | ***************** | libtool: link: g++ -shared-libgcc -D_DLL -DPIC -shared -nostdlib .......... | ....../mingw/lib/gcc/mingw32/4.4.0/libstdc++.dll.a -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex | -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex | -lmsvcrt c:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0/crtend.o -mieee-fp -o | .libs/libcruft-3-3-50+.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker | .libs/libcruft.dll.a | g++.exe: c:/Programs/MinGW/lib/gcc/mingw32/4.4.0/libstdc++.dll.a: No such file or directory | make[2]: *** [libcruft.la] Error 1 | make[2]: Leaving directory `/home/octaves/OctBuild/octave-develop/libcruft' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/home/octaves/OctBuild/octave-develop' | make: *** [all] Error 2 | ******************** | | There is no c:/Programs/MinGW/lib/gcc/mingw32/4.4.0/libstdc++.dll.a. | The library file'libstdc++_s.a' is the correct library file for shared building for MinGW gcc | complier. What is adding .../mingw/lib/gcc/mingw32/4.4.0/libstdc++.dll.a to the link command, what was really there in place of the ...? There is no mention of libstdc++ in the Octave Makefile.am files, so that is coming from somewhere else. Most likely it is libtool or GCC. So which one is it, and why? jwe From tmacchant at yahoo.co.jp Sat Nov 21 20:25:19 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sun, 22 Nov 2009 11:25:19 +0900 (JST) Subject: OCTAVE_PROG_GHOSTSCRIPT for windows In-Reply-To: <6580A36A-51FF-4CA5-9D87-09667143F452@mac.com> Message-ID: <20091122022523.37277.qmail@web3806.mail.bbt.yahoo.co.jp> Hello --- Ben Abbott > wrote: > > On Nov 21, 2009, at 5:42 PM, Tatsuro MATSUOKA wrote: > > > Hello > > > > > > In 'acinclude.m4' in the development source, I found > > > > dnl OCTAVE_PROG_GHOSTSCRIPT > > AC_DEFUN([OCTAVE_PROG_GHOSTSCRIPT], [ > > case "$canonical_host_type" in > > *-*-cygwin* | *-*-mingw32* | *-*-msdosmsvc) > > gs_names="gs gswin32" > > ;; > > *) > > gs_names=gs > > ;; > > esac > > ********** > > In Cygwin, is gs_names="gs gswin32" required? On cygwin, I am using 'gs.exe' on cygwin. > > > > > > gs_names="gs gswin32" > > > > Is it better to be > > gs_names="gs gswin32c" > > > > This has been discussed in quite recently for pdf printing on windows. > > > > http://old.nabble.com/Print-to-PDF-under-Windows-to26433734.html > > > > Regards > > For the print() function, should we look for "gs.exe" if the "gswin32c.exe" is not found? if (isunix ()) persistent ghostscript_binary = "gs"; elseif (ispc ()) If isunix() is false on cygwin, print() function shoud look for "gs.exe" because "gs.exe" is default ghostscript command on cygwin. BTW, what I thought about why cygwin is included in the 'case esac' after the first post. I suspect that the 'case' here cares cygwin users who use native windows version ghostscript but do not use cygwin version of ghostscript. However is this kind of care really necessary? If it is necessary, the 'case esac' is to be **** case "$canonical_host_type" in *-*-cygwin* | *-*-mingw32* | *-*-msdosmsvc) gs_names="gs gswin32c" ;; *) gs_names=gs ;; esac ******* otherwise, **** case "$canonical_host_type" in *-*-mingw32* | *-*-msdosmsvc) gs_names="gswin32c" ;; *) gs_names=gs ;; esac ******* It would be better to hear Marco's comments. Marco is the maintainer of the cygwin version of the octave. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From jwe at octave.org Sat Nov 21 20:37:06 2009 From: jwe at octave.org (John W. Eaton) Date: Sat, 21 Nov 2009 21:37:06 -0500 Subject: finally actually using gnulib In-Reply-To: <4B0829C2.2010007@gmx.net> References: <19198.60584.771475.300423@segfault.lan> <4AFEFF11.1070906@gmx.net> <420fb9e60911141224p3adbee11od4d35824be82779f@mail.gmail.com> <4AFF17FD.8000008@gmx.net> <4B059EDF.5070606@gmx.net> <19205.48485.939413.654792@segfault.lan> <4B080FDD.3030806@gmx.net> <19208.4573.362823.144589@segfault.lan> <4B081F02.2030406@gmx.net> <4B0829C2.2010007@gmx.net> Message-ID: <19208.41938.960858.438958@segfault.lan> On 21-Nov-2009, Benjamin Lindner wrote: | Benjamin Lindner wrote: | > I don't see why it picks a different compiler here. | | Aha, there is an unmatched AC_LANG_PUSH(C++) in configure.ac | If I remove it, then the check succeeds. | I am not sure if it is the right thing to so, though | | diff -r 4664de8669b2 configure.ac | --- a/configure.ac Thu Nov 19 20:34:21 2009 +0100 | +++ b/configure.ac Sat Nov 21 18:54:29 2009 +0100 | @@ -757,7 +757,6 @@ | AC_CHECK_FT2([9.0.3],[AC_DEFINE(HAVE_FREETYPE, 1, [Define to 1 if | you have Freetype library.])], | [warn_freetype="FreeType library not found. Native renderer will | not have on-screen text"]) | if test -z "$warn_freetype"; then | - AC_LANG_PUSH(C++) | save_LIBS="$LIBS" | save_CXXFLAGS="$CXXFLAGS" | save_CPPFLAGS="$CPPFLAGS" I checked in the following change. http://hg.savannah.gnu.org/hgweb/octave/rev/722bd8f6a750 Thanks, jwe From tmacchant at yahoo.co.jp Sat Nov 21 20:49:26 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sun, 22 Nov 2009 11:49:26 +0900 (JST) Subject: libtool build of development source on mingw : libstdc++.dll.a: No such file or directory In-Reply-To: <19208.40604.158846.2688@segfault.lan> Message-ID: <20091122024930.43487.qmail@web3806.mail.bbt.yahoo.co.jp> Hello --- "John W. Eaton" wrote: > On 22-Nov-2009, Tatsuro MATSUOKA wrote: > > | Hello > | > | This is first time try to build octave on mingw using libtool. > | > | I have encounter the error at linking libcruft. > | > | ***************** > | libtool: link: g++ -shared-libgcc -D_DLL -DPIC -shared -nostdlib .......... > | ....../mingw/lib/gcc/mingw32/4.4.0/libstdc++.dll.a -lmingw32 -lgcc_s -lgcc -lmoldname > -lmingwex > | -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex > | -lmsvcrt c:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0/crtend.o -mieee-fp -o > | .libs/libcruft-3-3-50+.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker > | .libs/libcruft.dll.a > | g++.exe: c:/Programs/MinGW/lib/gcc/mingw32/4.4.0/libstdc++.dll.a: No such file or directory > | make[2]: *** [libcruft.la] Error 1 > | make[2]: Leaving directory `/home/octaves/OctBuild/octave-develop/libcruft' > | make[1]: *** [all-recursive] Error 1 > | make[1]: Leaving directory `/home/octaves/OctBuild/octave-develop' > | make: *** [all] Error 2 > | ******************** > | > | There is no c:/Programs/MinGW/lib/gcc/mingw32/4.4.0/libstdc++.dll.a. > | The library file'libstdc++_s.a' is the correct library file for shared building for MinGW gcc > | complier. > > What is adding .../mingw/lib/gcc/mingw32/4.4.0/libstdc++.dll.a to > the link command, what was really there in place of the ...? There is > no mention of libstdc++ in the Octave Makefile.am files, so that is > coming from somewhere else. Most likely it is libtool or GCC. So > which one is it, and why? > > jwe > OK. I will look into msys libtool (libtool-2.2.7a-1-msys-1.0.11-bin) downloaded from http://sourceforge.net/projects/mingw/files/ Thanks for your information. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From tmacchant at yahoo.co.jp Sat Nov 21 21:57:23 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sun, 22 Nov 2009 12:57:23 +0900 (JST) Subject: libtool build of development source on mingw : libstdc++.dll.a: No such file or directory In-Reply-To: <20091122024930.43487.qmail@web3806.mail.bbt.yahoo.co.jp> Message-ID: <20091122035724.25860.qmail@web3802.mail.bbt.yahoo.co.jp> Hello --- Tatsuro MATSUOKA wrote: > OK. I will look into msys libtool (libtool-2.2.7a-1-msys-1.0.11-bin) downloaded from > http://sourceforge.net/projects/mingw/files/ > Perhaps I should use libtool-mingw. But I'm now in confusion. I will try both and try to find which one is to be used for octave building. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From tmacchant at yahoo.co.jp Sat Nov 21 23:34:29 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sun, 22 Nov 2009 14:34:29 +0900 (JST) Subject: libtool build of development source on mingw : libstdc++.dll.a: No such file or directory In-Reply-To: <19208.40604.158846.2688@segfault.lan> Message-ID: <20091122053433.88879.qmail@web3806.mail.bbt.yahoo.co.jp> Hello --- "John W. Eaton" wrote: > What is adding .../mingw/lib/gcc/mingw32/4.4.0/libstdc++.dll.a to > the link command, what was really there in place of the ...? There is > no mention of libstdc++ in the Octave Makefile.am files, so that is > coming from somewhere else. Most likely it is libtool or GCC. So > which one is it, and why? > What is adding .../mingw/lib/gcc/mingw32/4.4.0/libstdc++.dll.a to the link command That was /mingw/lib/gcc/mingw32/4.4.0/libstdc++.la. In libstdc++.la , # Names of this library. library_names='libstdc++.dll.a' Hmmmm! This problem was already reported in the MinGW web http://old.nabble.com/GCC-4.4.0-fails-with-GMP-td24191439.html I also leave the above as a record. I will try it again. BTW, what is need to autogen.sh is libtoolize but not libtool. I did not understand it. There are two libtoolize commands in Msys+MinGW system. One is in msys version, the other is MinGW one. According to the description, I might have to use MinGW version libtool for windows native application. However, if use of the tool limited to libtoolize, the situation might be to different. Anyway I will try further. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From tmacchant at yahoo.co.jp Sun Nov 22 00:46:17 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sun, 22 Nov 2009 15:46:17 +0900 (JST) Subject: libiberty problem : mingw build on latest development source Message-ID: <20091122064621.40866.qmail@web3812.mail.bbt.yahoo.co.jp> Hello I have been trying to build current development trees. ********************* description GNU Octave (development branch) owner John W. Eaton last change Sat, 21 Nov 2009 21:44:51 -0500 project home http://savannah.gnu.org/projects/octave ***** In linking libcruft, I have get the following. *** Warning: This system can not link to static lib archive c:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0/libgfortranbe gin.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: linker path does not have real file for library -liberty. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libiberty and none of the candidates passed a file format test *** using a file magic. Last file checked: /mingw/lib/libiberty.a *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. /mingw/lib/libiberty.a seemed to be a problem. I have googled and find one of the MinGW ML threads. *** can not create dll when linking against libiberty.a or libbfd.a*** at http://old.nabble.com/can-not-create-dll-when-linking-against-libiberty.a-or-libbfd.a-td26368803.html The library libiberty.a is provided in binutils-2.19.1-mingw32-bin.tar.gz In binutils-2.19.1-mingw32-bin.tar.gz, there is no libiberty.la nor shared version of it so that I cannot get "The inter-library dependencies" Should Ilook at source files of "binutils-2.19.1-mingw32-bin" ? This is current status in my build. I have try to struggling a little bit. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From bpabbott at mac.com Sat Nov 21 19:52:59 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sat, 21 Nov 2009 20:52:59 -0500 Subject: build trouble on MacOS 10.5 In-Reply-To: References: Message-ID: On Nov 21, 2009, at 8:44 PM, Ben Abbott wrote: > The build looks good until Octave is run. > > Making all in interpreter > ../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'txt');" > make[3]: *** [voronoi.txt] Bus error > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > When I try to run octave ... > >> $ ./run-octave >> Bus error > >> From the gdb > >> .warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/loaders/.libs/libltdl_libltdl_la-preopen.o" - no debug information available for "libltdl/loaders/preopen.c". >> >> warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/libltdl_libltdl_la-lt__alloc.o" - no debug information available for "libltdl/lt__alloc.c". >> >> warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/libltdl_libltdl_la-lt_dlloader.o" - no debug information available for "libltdl/lt_dlloader.c". >> >> warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/libltdl_libltdl_la-lt_error.o" - no debug information available for "libltdl/lt_error.c". >> >> warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/libltdl_libltdl_la-ltdl.o" - no debug information available for "libltdl/ltdl.c". >> >> warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/libltdl_libltdl_la-slist.o" - no debug information available for "libltdl/slist.c". >> >> warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/argz.o" - no debug information available for "libltdl/argz.c". >> >> warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/libltdlS.o" - no debug information available for "libltdlS.c". >> >> warning: Could not find object file "/sw/src/fink.build/libtool2-2.2.6-3/libtool-2.2.6/libltdl/.libs/libltdl.lax/dlopen.a/dlopen.o" - no debug information available for "libltdl/loaders/dlopen.c". >> >> ..................................... done >> >> Program received signal EXC_BAD_ACCESS, Could not access memory. >> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 >> 0x02c0702f in std::locale::operator= () >> (gdb) > >> (gdb) bt >> No stack. > > I thought the problem might have to do with linking to a bad library, so I hope to use the Mac OSX alternative to ldd to track it down ... > >> $ otool -L ./src/octave >> ./src/octave: is not an object file > > As I'm not having any trouble compiling fortran programs and/or libraries, I tried ... > >> $ otool -L ./libcruft/odepack/vnorm.lo >> ./libcruft/odepack/vnorm.lo: is not an object file > > And then the actual fortran object file. > >> $ otool -L ./libcruft/odepack/.libs/vnorm.o >> ./libcruft/odepack/.libs/vnorm.o: > > I have two questions. > > (1) Does anyone have any insight / advice? > > (2) Are there any Mac OSX who have been successful building the current sources? > > Ben I hit to quick. My Mac OS version is 10.6 not 10.5. Ben From bpabbott at mac.com Sat Nov 21 20:32:48 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sat, 21 Nov 2009 21:32:48 -0500 Subject: build trouble on MacOS 10.5 In-Reply-To: <19208.40171.911211.78147@segfault.lan> References: <19208.40171.911211.78147@segfault.lan> Message-ID: <55FF98C5-C5F7-416D-9129-31C25F5FA8CA@mac.com> On Nov 21, 2009, at 9:07 PM, John W. Eaton wrote: > On 21-Nov-2009, Ben Abbott wrote: > > | I thought the problem might have to do with linking to a bad library, so I hope to use the Mac OSX alternative to ldd to track it down ... > | > | > $ otool -L ./src/octave > | > ./src/octave: is not an object file > > That's a script, generated by libtool. > > Try this instead in the top-level directory in your build tree: > > ./libtool --mode execute ldd src/octave > > jwe Great! That works. I assume, that for Linux systems, "ldd ./src/octave" also complains? > $ ./libtool --mode execute otool -L src/octave > /Users/bpabbott/Development/mercurial/local_clone/src/.libs/octave: > /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) > /sw/lib/gcc4.4/lib/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0) > /sw/lib/octave-3.3.50+/liboctinterp-3.3.50+.dylib (compatibility version 0.0.0, current version 0.0.0) > /sw/lib/octave-3.3.50+/liboctave-3.3.50+.dylib (compatibility version 0.0.0, current version 0.0.0) > /sw/lib/octave-3.3.50+/libcruft-3.3.50+.dylib (compatibility version 0.0.0, current version 0.0.0) > /sw/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0) > /sw/lib/libGraphicsMagick.3.dylib (compatibility version 6.0.0, current version 6.0.0) > /sw/lib/libfftw3.3.dylib (compatibility version 6.0.0, current version 6.4.0) > /sw/lib/libfftw3f.3.dylib (compatibility version 6.0.0, current version 6.4.0) > /sw/lib/fltk-aqua/lib/libfltk_gl.1.1.dylib (compatibility version 1.1.0, current version 1.1.4) > /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0) > /sw/lib/fltk-aqua/lib/libfltk.1.1.dylib (compatibility version 1.1.0, current version 1.1.4) > /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0) > /sw/lib/libhdf5.0.dylib (compatibility version 1.0.0, current version 1.0.0) > /sw/lib/libsz.2.dylib (compatibility version 3.0.0, current version 3.0.0) > /usr/X11/lib/libfontconfig.1.dylib (compatibility version 5.0.0, current version 5.0.0) > /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current version 9.0.0) > /sw/lib/libreadline.5.dylib (compatibility version 5.0.0, current version 5.0.0) > /sw/lib/ncurses/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0) > /sw/lib/freetype219/lib/libfreetype.6.dylib (compatibility version 10.0.0, current version 10.19.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) > /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0) > /sw/lib/gcc4.4/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Comparing to 3.2.3 (which runs) > /sw/lib/gcc4.4/lib/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0) > /sw/lib/libGraphicsMagick.3.dylib (compatibility version 6.0.0, current version 6.0.0) > /sw/lib/fltk-aqua/lib/libfltk_gl.1.1.dylib (compatibility version 1.1.0, current version 1.1.4) > /sw/lib/fltk-aqua/lib/libfltk.1.1.dylib (compatibility version 1.1.0, current version 1.1.4) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0) > /sw/lib/octave-3.2.3/liboctinterp.dylib (compatibility version 0.0.0, current version 0.0.0) > /sw/lib/octave-3.2.3/liboctave.dylib (compatibility version 0.0.0, current version 0.0.0) > /sw/lib/octave-3.2.3/libcruft.dylib (compatibility version 0.0.0, current version 0.0.0) > /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0) > /sw/lib/libfftw3.3.dylib (compatibility version 6.0.0, current version 6.4.0) > /sw/lib/libfftw3f.3.dylib (compatibility version 6.0.0, current version 6.4.0) > /sw/lib/libftgl.0.dylib (compatibility version 1.0.0, current version 1.0.0) > /sw/lib/freetype219/lib/libfreetype.6.dylib (compatibility version 10.0.0, current version 10.19.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 38.0.0) > /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) > /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current version 9.0.0) > /sw/lib/libreadline.5.dylib (compatibility version 5.0.0, current version 5.0.0) > /sw/lib/ncurses/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0) > /sw/lib/libhdf5.0.dylib (compatibility version 1.0.0, current version 1.0.0) > /sw/lib/gcc4.4/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.13.0) > /sw/lib/gcc4.4/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) The added libs are ... > /sw/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0) > /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0) > /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0) > /sw/lib/libsz.2.dylib (compatibility version 3.0.0, current version 3.0.0) > /usr/X11/lib/libfontconfig.1.dylib (compatibility version 5.0.0, current version 5.0.0) I don't see anything obvious here. I've cc'd Martin over at Fink in case he might spot something. Ben From marco_atzeri at yahoo.it Sun Nov 22 03:36:12 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Sun, 22 Nov 2009 09:36:12 +0000 (GMT) Subject: OCTAVE_PROG_GHOSTSCRIPT for windows In-Reply-To: <20091122022523.37277.qmail@web3806.mail.bbt.yahoo.co.jp> Message-ID: <463708.76422.qm@web25503.mail.ukl.yahoo.com> --- Dom 22/11/09, Tatsuro MATSUOKA ha scritto: > Da: Tatsuro MATSUOKA > Oggetto: Re: OCTAVE_PROG_GHOSTSCRIPT for windows > A: "Ben Abbott" , "Marco Atzeri" > Cc: maintainers at octave.org > Data: Domenica 22 novembre 2009, 03:25 > Hello > > --- Ben Abbott > wrote: > > > > > On Nov 21, 2009, at 5:42 PM, Tatsuro MATSUOKA wrote: > > > > > Hello > > > > > > > > > In 'acinclude.m4' in the development source, I > found > > > > > > dnl OCTAVE_PROG_GHOSTSCRIPT > > > AC_DEFUN([OCTAVE_PROG_GHOSTSCRIPT], [ > > >? case "$canonical_host_type" in > > >? ? *-*-cygwin* | *-*-mingw32* | > *-*-msdosmsvc) > > >? ? ? gs_names="gs gswin32" > > >? ? ;; > > >? ? *) > > >? ? ? gs_names=gs > > >? ? ;; > > >? esac > > > ********** > > > In Cygwin, is gs_names="gs gswin32" required? On > cygwin, I am using 'gs.exe' on cygwin. > > > > > > > > >? ? ? gs_names="gs gswin32" > > > > > > Is it better to be > > >? ? ? gs_names="gs gswin32c" > > > > > > This has been discussed in quite recently for pdf > printing on windows. > > > > > > http://old.nabble.com/Print-to-PDF-under-Windows-to26433734.html > > > > > > Regards > > > > For the print() function, should we look for "gs.exe" > if the "gswin32c.exe" is not found? > > ? if (isunix ()) > ? ? persistent ghostscript_binary = "gs"; > ? elseif (ispc ()) > > If isunix() is false on cygwin, print() function shoud look > for "gs.exe" because "gs.exe" is default > ghostscript command on cygwin. > > > BTW, what I thought about why cygwin is included in the > 'case esac' after the first post. I suspect > that the 'case' here cares cygwin users who use native > windows version ghostscript but do not use > cygwin version of ghostscript. > > > However is this kind of care really necessary?? > > If it is necessary, the 'case esac' is to be > ****??? > ? case "$canonical_host_type" in > ? ? *-*-cygwin* | *-*-mingw32* | *-*-msdosmsvc) > ? ? ? gs_names="gs gswin32c" > ? ? ;; > ? ? *) > ? ? ? gs_names=gs > ? ? ;; > ? esac > ******* > otherwise, > ****??? > ? case "$canonical_host_type" in > ? ? *-*-mingw32* | *-*-msdosmsvc) > ? ? ? gs_names="gswin32c" > ? ? ;; > ? ? *) > ? ? ? gs_names=gs > ? ? ;; > ? esac > ******* > > It would be better to hear Marco's comments.? Marco is > the maintainer of the cygwin version of the > octave. > the 2nd way is the right way. Cygwin aims to work as a standard unix/linux platform. > Regards > > Tatsuro Marco From tmacchant at yahoo.co.jp Sun Nov 22 04:17:29 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sun, 22 Nov 2009 19:17:29 +0900 (JST) Subject: OCTAVE_PROG_GHOSTSCRIPT for windows In-Reply-To: <463708.76422.qm@web25503.mail.ukl.yahoo.com> Message-ID: <20091122101730.9421.qmail@web3803.mail.bbt.yahoo.co.jp> Hello Ben > > > For the print() function, should we look for "gs.exe" > > if the "gswin32c.exe" is not found? > > > >  if (isunix ()) > >   persistent ghostscript_binary = "gs"; > >  elseif (ispc ()) > > > > If isunix() is false on cygwin, print() function shoud look > > for "gs.exe" because "gs.exe" is default > > ghostscript command on cygwin. I have tested small script testunix.m under octave on cygwin (under /usr/share/octave/3.2.3/m/plot directory). if (isunix()) disp('unix') else disp('not unix') end if (ispc()) disp('pc') else disp('not pc') end *** result is octave:2> testunix unix not pc **** The above tells that isunix() is true on cygwin so that further patch is not needed for print() function. ++++++++++++++++++++++++++++++++++++ Hello Macro > > If it is necessary, the 'case esac' is to be > > **** > >  case "$canonical_host_type" in > >   *-*-cygwin* | *-*-mingw32* | *-*-msdosmsvc) > >    gs_names="gs gswin32c" > >   ;; > >   *) > >    gs_names=gs > >   ;; > >  esac > > ******* > > otherwise, > > **** > >  case "$canonical_host_type" in > >   *-*-mingw32* | *-*-msdosmsvc) > >    gs_names="gswin32c" > >   ;; > >   *) > >    gs_names=gs > >   ;; > >  esac > > ******* > > > > It would be better to hear Marco's comments. Marco is > > the maintainer of the cygwin version of the > > octave. > > > > the 2nd way is the right way. > Cygwin aims to work as a standard unix/linux platform. > Thank you for your comments. I will consider the changeset after dinner :-). Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From lindnerben at gmx.net Sun Nov 22 04:49:50 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sun, 22 Nov 2009 11:49:50 +0100 Subject: libtool build of development source on mingw : libstdc++.dll.a: No such file or directory In-Reply-To: <20091121220337.17002.qmail@web3810.mail.bbt.yahoo.co.jp> References: <20091121220337.17002.qmail@web3810.mail.bbt.yahoo.co.jp> Message-ID: <4B09174E.7020004@gmx.net> Tatsuro MATSUOKA wrote: > Hello > > This is first time try to build octave on mingw using libtool. > > I have encounter the error at linking libcruft. > > ***************** > libtool: link: g++ -shared-libgcc -D_DLL -DPIC -shared -nostdlib .......... > ....../mingw/lib/gcc/mingw32/4.4.0/libstdc++.dll.a -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex > -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex > -lmsvcrt c:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0/crtend.o -mieee-fp -o > .libs/libcruft-3-3-50+.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker > .libs/libcruft.dll.a > g++.exe: c:/Programs/MinGW/lib/gcc/mingw32/4.4.0/libstdc++.dll.a: No such file or directory > make[2]: *** [libcruft.la] Error 1 > make[2]: Leaving directory `/home/octaves/OctBuild/octave-develop/libcruft' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/octaves/OctBuild/octave-develop' > make: *** [all] Error 2 > ******************** > > There is no c:/Programs/MinGW/lib/gcc/mingw32/4.4.0/libstdc++.dll.a. > The library file'libstdc++_s.a' is the correct library file for shared building for MinGW gcc > complier. That's a bug in mingw's gcc. See http://thread.gmane.org/gmane.comp.gnu.mingw.user/30206/focus=30243 http://sourceforge.net/mailarchive/forum.php?thread_name=4A97B057.2040803%40gmail.com&forum_name=mingw-users benjamin From lindnerben at gmx.net Sun Nov 22 04:54:58 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sun, 22 Nov 2009 11:54:58 +0100 Subject: libtool build of development source on mingw : libstdc++.dll.a: No such file or directory In-Reply-To: <20091122035724.25860.qmail@web3802.mail.bbt.yahoo.co.jp> References: <20091122035724.25860.qmail@web3802.mail.bbt.yahoo.co.jp> Message-ID: <4B091882.1060204@gmx.net> Tatsuro MATSUOKA wrote: > Hello > > --- Tatsuro MATSUOKA wrote: > >> OK. I will look into msys libtool (libtool-2.2.7a-1-msys-1.0.11-bin) downloaded from >> http://sourceforge.net/projects/mingw/files/ >> > > Perhaps I should use libtool-mingw. But I'm now in confusion. I will try both and try to find which > one is to be used for octave building. > There's a release note for both the -msys and -mingw version of libtool which describe under which cirbumstances to use which version. I'd recommend to use the -mingw version, as the -msys version is to be used to develop msys applications, not native windows applications. You have to take care where you install it, if you don't install it into /mingw, then you have to patch it to search for libtool's files in the correct paths. If you are interested, you can take a look at the mingw and msys mini-installation scripts in the octave-forge svn repos. benjamin From lindnerben at gmx.net Sun Nov 22 05:01:46 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sun, 22 Nov 2009 12:01:46 +0100 Subject: libiberty problem : mingw build on latest development source In-Reply-To: <20091122064621.40866.qmail@web3812.mail.bbt.yahoo.co.jp> References: <20091122064621.40866.qmail@web3812.mail.bbt.yahoo.co.jp> Message-ID: <4B091A1A.2060606@gmx.net> Tatsuro MATSUOKA wrote: > Hello > > I have been trying to build current development trees. > > ********************* > description GNU Octave (development branch) > owner John W. Eaton > last change Sat, 21 Nov 2009 21:44:51 -0500 > project home http://savannah.gnu.org/projects/octave > ***** > > In linking libcruft, I have get the following. > > *** Warning: This system can not link to static lib archive > c:/programs/mingw/bin/../lib/gcc/mingw32/4.4.0/libgfortranbe > gin.la. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > > *** Warning: linker path does not have real file for library -liberty. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have > *** because I did check the linker path looking for a file starting > *** with libiberty and none of the candidates passed a file format test > *** using a file magic. Last file checked: /mingw/lib/libiberty.a > *** The inter-library dependencies that have been dropped here will be > *** automatically added whenever a program is linked with this library > *** or is declared to -dlopen it. > > *** Since this library must not contain undefined symbols, > *** because either the platform does not support them or > *** it was explicitly requested with -no-undefined, > *** libtool will only create a static version of it. > > /mingw/lib/libiberty.a seemed to be a problem. > > I have googled and find one of the MinGW ML threads. :) the next one to fall into the trap libtool lays. I don't know why this fails the way it fails. There is a quite lengthy thread on the maintainer's list titled "gnulib and automake". Take a look. For me, it boiled down to http://lists.cairographics.org/archives/cairo/2009-July/017683.html (Besides, libiberty is part of gcc) Maybe (that's speculation on my part) it would also solve the problem if one created a libiberty.la file for libiberty.a (is this a gcc packaging bug?). But again, for libstdc++.a there is a .la file, and it *breaks* building in this case. I didn't dig much deeper here. benjamin From lindnerben at gmx.net Sun Nov 22 05:12:52 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sun, 22 Nov 2009 12:12:52 +0100 Subject: OCTAVE_PROG_GHOSTSCRIPT for windows In-Reply-To: <20091121224242.3866.qmail@web3804.mail.bbt.yahoo.co.jp> References: <20091121224242.3866.qmail@web3804.mail.bbt.yahoo.co.jp> Message-ID: <4B091CB4.90804@gmx.net> Tatsuro MATSUOKA wrote: > Hello > > > In 'acinclude.m4' in the development source, I found > > dnl OCTAVE_PROG_GHOSTSCRIPT > AC_DEFUN([OCTAVE_PROG_GHOSTSCRIPT], [ > case "$canonical_host_type" in > *-*-cygwin* | *-*-mingw32* | *-*-msdosmsvc) > gs_names="gs gswin32" > ;; > *) > gs_names=gs > ;; > esac > ********** > In Cygwin, is gs_names="gs gswin32" required? On cygwin, I am using 'gs.exe' on cygwin. > > > gs_names="gs gswin32" > > Is it better to be > gs_names="gs gswin32c" Both works, what's better is up to definition. I'd use "gswin32c" since it is the console version. But I see another issue, the host triplet for mingw should be *-*-mingw* (omit the explicit "32"). benjamin From tmacchant at yahoo.co.jp Sun Nov 22 05:19:39 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sun, 22 Nov 2009 20:19:39 +0900 (JST) Subject: libiberty problem : mingw build on latest development source In-Reply-To: <4B091A1A.2060606@gmx.net> Message-ID: <20091122111943.20963.qmail@web3809.mail.bbt.yahoo.co.jp> > There is a quite lengthy thread on the maintainer's list > titled "gnulib and automake". Take a look. > > For me, it boiled down to > http://lists.cairographics.org/archives/cairo/2009-July/017683.html > > (Besides, libiberty is part of gcc) Thank you for your information. > > Maybe (that's speculation on my part) it would also solve the > problem if one created a libiberty.la file for libiberty.a > (is this a gcc packaging bug?). I have gotten successful to create libiberty.la like other library files in lib directory of binutils of mingw. I have met another error in creating shared libcruft libraries. Perhaps I should refer the your thread to overcome the problem. > > But again, for libstdc++.a there is a .la file, and it *breaks* > building in this case. Indeed! That was really annoying :-(. For libtoorize, I will accept your advises. I really appreciate your efforts and advises. Regards Tatsuro Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From tmacchant at yahoo.co.jp Sun Nov 22 05:30:26 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Sun, 22 Nov 2009 20:30:26 +0900 (JST) Subject: OCTAVE_PROG_GHOSTSCRIPT for windows [Changeset] In-Reply-To: <4B091CB4.90804@gmx.net> Message-ID: <20091122113030.68268.qmail@web3811.mail.bbt.yahoo.co.jp> Hello --- Benjamin Lindner wrote: > > Both works, what's better is up to definition. > I'd use "gswin32c" since it is the console version. > > But I see another issue, the host triplet for mingw > should be *-*-mingw* (omit the explicit "32"). Thank you for your suggestion I am uploading the changeset considering your and Marco's comment. Benjamin and Macro Thanks a lot! Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OCTAVE_PROG_GHOSTSCRIPT.changeset Type: application/x-unknown Size: 666 bytes Desc: 70559328-OCTAVE_PROG_GHOSTSCRIPT.changeset Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091122/6ebcd338/attachment-0001.bin From lindnerben at gmx.net Sun Nov 22 07:01:42 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sun, 22 Nov 2009 14:01:42 +0100 Subject: HOWTO for building octave using mingw/msys Message-ID: <4B093636.7030008@gmx.net> Hello, I started writing a small HOWTO on building octave for windows using mingw/msys and the toolchain available on the octave-forge svn repos. https://octave.svn.sourceforge.net/svnroot/octave/trunk/octave-forge/admin/Windows/mingw32/HOWTO.txt It's work in progress, and doesn't include all details on automake and gnulib yet. But it's a start. I'd like to improve it further, so feedback, comments, criticism, all is welcome. benjamin From bpabbott at mac.com Sun Nov 22 09:11:26 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sun, 22 Nov 2009 10:11:26 -0500 Subject: isunix on mingw? (was OCTAVE_PROG_GHOSTSCRIPT for windows) In-Reply-To: <20091122101730.9421.qmail@web3803.mail.bbt.yahoo.co.jp> References: <20091122101730.9421.qmail@web3803.mail.bbt.yahoo.co.jp> Message-ID: <4917E207-F20A-4E9A-A34C-821AF0D61F54@mac.com> On Nov 22, 2009, at 5:17 AM, Tatsuro MATSUOKA wrote: > The above tells that isunix() is true on cygwin so that further patch is not needed for print() > function. Will isunix() be true for mingw as well? Ben From lindnerben at gmx.net Sun Nov 22 09:33:51 2009 From: lindnerben at gmx.net (Benjamin Lindner) Date: Sun, 22 Nov 2009 16:33:51 +0100 Subject: isunix on mingw? (was OCTAVE_PROG_GHOSTSCRIPT for windows) In-Reply-To: <4917E207-F20A-4E9A-A34C-821AF0D61F54@mac.com> References: <20091122101730.9421.qmail@web3803.mail.bbt.yahoo.co.jp> <4917E207-F20A-4E9A-A34C-821AF0D61F54@mac.com> Message-ID: <4B0959DF.6040304@gmx.net> Ben Abbott wrote: > > Will isunix() be true for mingw as well? > It should not be, and it is not in octave 3.2.3 (just checked). benjamin From bpabbott at mac.com Sun Nov 22 12:34:25 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sun, 22 Nov 2009 13:34:25 -0500 Subject: isunix on mingw? (was OCTAVE_PROG_GHOSTSCRIPT for windows) In-Reply-To: <4B0959DF.6040304@gmx.net> References: <20091122101730.9421.qmail@web3803.mail.bbt.yahoo.co.jp> <4917E207-F20A-4E9A-A34C-821AF0D61F54@mac.com> <4B0959DF.6040304@gmx.net> Message-ID: On Nov 22, 2009, at 10:33 AM, Benjamin Lindner wrote: > Ben Abbott wrote: >> Will isunix() be true for mingw as well? > > It should not be, and it is not in octave 3.2.3 (just checked). > > benjamin ok. So when isunix == true, the ghostscript binary can be "gs", "gs.exe", or "gswin32c.exe". And when ispc == true, the ghostscript binary can be "gs.exe", or "gswin32c.exe". Ben From bpabbott at mac.com Sun Nov 22 13:07:58 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sun, 22 Nov 2009 14:07:58 -0500 Subject: Print to PDF under Windows [changeset-3] In-Reply-To: References: <128f38bd0911191239r443321dao240b01ab66bb9e35@mail.gmail.com> <137439832808707203260296105367491456037-Webmail@me.com> <128f38bd0911200307q4fb1d13eu27e9d99ef2a98bae@mail.gmail.com> <589FBB87-7246-40CA-BD35-B90A38F799C6@mac.com> <4B07F5EB.9090202@gmx.net> Message-ID: On Nov 21, 2009, at 10:05 AM, Ben Abbott wrote: > On Nov 21, 2009, at 9:15 AM, Benjamin Lindner wrote: > >>> Michael or other Window users, >>> Can you confirm the attached works? >>> Ben >> >> The console version of ghostscript on win32 is called "gswin32c.exe". >> There is also a GUI version, which is called "gswin32.exe". >> I don't see the reason for using the gui version. What if you want to >> pipe commands to ghostscript? >> >> If one insists on using the GUI version, well then you can specify >> it in GSC anyway, but in my opinion the correct version to use >> by default is the console version. Hence "gswin32c.exe" >> >> benjamin > > Ok, my understanding is that EXEC_PATH is equivalent to the PATH environment variable that was in place when Octave was run. Which is likely to include the default shell's PATH as well as additions needed to run Octave. In the event ghostscript is bundled with Octave, then EXEC_PATH is preferred over PATH. > > The attached changeset looks for the console version of ghostscript, "gswin32c.exe", and still searches EXEC_PATH for gswin32c.exe. > > Ben > > If I understand correctly ... isunix() == true for cygwin and unix systems. ispc() == true for Win32 and mingw For Win32, mingw, and cygwin, I assume that "gswin32c.exe", and "gs.exe" may each represent the ghostscript binary? For cygwin and unix, the binary may be "gs". Thus, I don't see the utility of using isunix() or ispc() ... hence another proposed changeset. Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: changeset.patch Type: application/octet-stream Size: 2703 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091122/ad69f322/attachment.obj -------------- next part -------------- From tmacchant at yahoo.co.jp Sun Nov 22 14:25:48 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Mon, 23 Nov 2009 05:25:48 +0900 (JST) Subject: HOWTO for building octave using mingw/msys In-Reply-To: <4B093636.7030008@gmx.net> Message-ID: <20091122202548.28799.qmail@web3814.mail.bbt.yahoo.co.jp> Hello Benjamin --- Benjamin Lindner wrote: > Hello, > > I started writing a small HOWTO on building octave for windows using > mingw/msys and the toolchain available on the octave-forge svn repos. > > https://octave.svn.sourceforge.net/svnroot/octave/trunk/octave-forge/admin/Windows/mingw32/HOWTO.txt > > It's work in progress, and doesn't include all details on automake and > gnulib yet. But it's a start. > > I'd like to improve it further, so feedback, comments, criticism, > all is welcome. I have just to see the above. It is comprehensive and useful!! I myself have some building environment but your document will be very helpful for me. I appreciate for your efforts. BTW, can I introduce your instruction on OctaveForWindows Wiki ? Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From tmacchant at yahoo.co.jp Sun Nov 22 15:07:37 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Mon, 23 Nov 2009 06:07:37 +0900 (JST) Subject: Print to PDF under Windows [changeset-3] In-Reply-To: Message-ID: <20091122210742.14899.qmail@web3801.mail.bbt.yahoo.co.jp> Hello Ben Thanks for your efforts. I have installed two ghostscript. One is for native windows (gswin32.exe ) and the other is for cygwin (gs.exe). This patch seems to search ghostscript in the order of 'gswin32c.exe', gs.exe and gs? If it is so, is 'gswin32c.exe' selected even for cygwin ? If it is the case, it will be bad for cygwin. I think that it is OK to search 'gs.exe' or 'gs' when isunix() is true. For the people who do not like to use non standard ghostscript binary (e.g. who would like to use gswin32c.exe but not gs.exe from cygwin) , they should set 'GSC' environmental variable. Marco, who is a maintainer of cygwin version maintainer, perhaps have similar opinion on this matter. Please see his reply for 'OCTAVE_PROG_GHOSTSCRIPT for windows'. http://old.nabble.com/Re:-OCTAVE_PROG_GHOSTSCRIPT-for-windows-p26463802.html At this post, it is also better to hear Macro's opinion. Regards Tatsuro --- Ben Abbott wrote: > > On Nov 21, 2009, at 10:05 AM, Ben Abbott wrote: > > > On Nov 21, 2009, at 9:15 AM, Benjamin Lindner wrote: > > > >>> Michael or other Window users, > >>> Can you confirm the attached works? > >>> Ben > >> > >> The console version of ghostscript on win32 is called "gswin32c.exe". > >> There is also a GUI version, which is called "gswin32.exe". > >> I don't see the reason for using the gui version. What if you want to > >> pipe commands to ghostscript? > >> > >> If one insists on using the GUI version, well then you can specify > >> it in GSC anyway, but in my opinion the correct version to use > >> by default is the console version. Hence "gswin32c.exe" > >> > >> benjamin > > > > Ok, my understanding is that EXEC_PATH is equivalent to the PATH environment variable that was > in place when Octave was run. Which is likely to include the default shell's PATH as well as > additions needed to run Octave. In the event ghostscript is bundled with Octave, then EXEC_PATH > is preferred over PATH. > > > > The attached changeset looks for the console version of ghostscript, "gswin32c.exe", and still > searches EXEC_PATH for gswin32c.exe. > > > > Ben > > > > > > If I understand correctly ... > > isunix() == true for cygwin and unix systems. > ispc() == true for Win32 and mingw > > For Win32, mingw, and cygwin, I assume that "gswin32c.exe", and "gs.exe" may each represent the > ghostscript binary? > > For cygwin and unix, the binary may be "gs". > > Thus, I don't see the utility of using isunix() or ispc() ... hence another proposed changeset. > > Ben > > > > > > > > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From marco_atzeri at yahoo.it Sun Nov 22 15:15:35 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Sun, 22 Nov 2009 21:15:35 +0000 (GMT) Subject: Print to PDF under Windows [changeset-3] In-Reply-To: Message-ID: <541973.79759.qm@web25508.mail.ukl.yahoo.com> --- Dom 22/11/09, Ben Abbott ha scritto: > Da: Ben Abbott > Oggetto: Re: Print to PDF under Windows [changeset-3] > A: "Ben Abbott" > Cc: "octave maintainers mailing list" > Data: Domenica 22 novembre 2009, 20:07 > > On Nov 21, 2009, at 10:05 AM, Ben Abbott wrote: > > > On Nov 21, 2009, at 9:15 AM, Benjamin Lindner wrote: > > > >>> Michael or other Window users, > >>> Can you confirm the attached works? > >>> Ben > >> > >> The console version of ghostscript on win32 is > called "gswin32c.exe". > >> There is also a GUI version, which is called > "gswin32.exe". > >> I don't see the reason for using the gui version. > What if you want to > >> pipe commands to ghostscript? > >> > >> If one insists on using the GUI version, well then > you can specify > >> it in GSC anyway, but in my opinion the correct > version to use > >> by default is the console version. Hence > "gswin32c.exe" > >> > >> benjamin > > > > Ok, my understanding is that EXEC_PATH is equivalent > to the PATH environment variable that was in place when > Octave was run. Which is likely to include the default > shell's PATH as well as additions needed to run Octave. In > the event? ghostscript is bundled with Octave, then > EXEC_PATH is preferred over PATH. > > > > The attached changeset looks for the console version > of ghostscript, "gswin32c.exe", and still searches EXEC_PATH > for gswin32c.exe. > > > > Ben > > > > > > If I understand correctly ... > > isunix() == true for cygwin and unix systems. > ispc() == true for Win32 and mingw > > For Win32, mingw, and cygwin, I assume that "gswin32c.exe", > and "gs.exe" may each represent the ghostscript binary? on cygwin the binary is only "gs.exe" ( "gs" is also accepted) > > For cygwin and unix, the binary may be "gs". > > Thus, I don't see the utility of using isunix() or ispc() > ... hence another proposed changeset. > > Ben > Marco From bpabbott at mac.com Sun Nov 22 15:52:35 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sun, 22 Nov 2009 16:52:35 -0500 Subject: Print to PDF under Windows [changeset-4] In-Reply-To: <20091122210742.14899.qmail@web3801.mail.bbt.yahoo.co.jp> References: <20091122210742.14899.qmail@web3801.mail.bbt.yahoo.co.jp> Message-ID: On Nov 22, 2009, at 4:07 PM, Tatsuro MATSUOKA wrote: > Hello Ben > > Thanks for your efforts. > > I have installed two ghostscript. One is for native windows (gswin32.exe ) and the other is for cygwin > (gs.exe). > > This patch seems to search ghostscript in the order of 'gswin32c.exe', gs.exe and gs? > If it is so, is 'gswin32c.exe' selected even for cygwin ? > If it is the case, it will be bad for cygwin. > > I think that it is OK to search 'gs.exe' or 'gs' when isunix() is true. > > For the people who do not like to use non standard ghostscript binary (e.g. who would like to use > gswin32c.exe but not gs.exe from cygwin) , they should set 'GSC' environmental variable. > > > Marco, who is a maintainer of cygwin version maintainer, perhaps have similar opinion on this matter. > Please see his reply for 'OCTAVE_PROG_GHOSTSCRIPT for windows'. > > http://old.nabble.com/Re:-OCTAVE_PROG_GHOSTSCRIPT-for-windows-p26463802.html > > At this post, it is also better to hear Macro's opinion. > > Regards > > Tatsuro > > > > --- Ben Abbott wrote: > >> >> On Nov 21, 2009, at 10:05 AM, Ben Abbott wrote: >> >>> On Nov 21, 2009, at 9:15 AM, Benjamin Lindner wrote: >>> >>>>> Michael or other Window users, >>>>> Can you confirm the attached works? >>>>> Ben >>>> >>>> The console version of ghostscript on win32 is called "gswin32c.exe". >>>> There is also a GUI version, which is called "gswin32.exe". >>>> I don't see the reason for using the gui version. What if you want to >>>> pipe commands to ghostscript? >>>> >>>> If one insists on using the GUI version, well then you can specify >>>> it in GSC anyway, but in my opinion the correct version to use >>>> by default is the console version. Hence "gswin32c.exe" >>>> >>>> benjamin >>> >>> Ok, my understanding is that EXEC_PATH is equivalent to the PATH environment variable that was >> in place when Octave was run. Which is likely to include the default shell's PATH as well as >> additions needed to run Octave. In the event ghostscript is bundled with Octave, then EXEC_PATH >> is preferred over PATH. >>> >>> The attached changeset looks for the console version of ghostscript, "gswin32c.exe", and still >> searches EXEC_PATH for gswin32c.exe. >>> >>> Ben >>> >>> >> >> If I understand correctly ... >> >> isunix() == true for cygwin and unix systems. >> ispc() == true for Win32 and mingw >> >> For Win32, mingw, and cygwin, I assume that "gswin32c.exe", and "gs.exe" may each represent the >> ghostscript binary? >> >> For cygwin and unix, the binary may be "gs". >> >> Thus, I don't see the utility of using isunix() or ispc() ... hence another proposed changeset. >> >> Ben >> Ok ... a fourth attempt. Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: changeset.patch Type: application/octet-stream Size: 2837 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091122/9d5c074b/attachment-0001.obj -------------- next part -------------- From tmacchant at yahoo.co.jp Sun Nov 22 17:58:46 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Mon, 23 Nov 2009 08:58:46 +0900 (JST) Subject: Print to PDF under Windows [changeset-4] In-Reply-To: Message-ID: <20091122235846.75436.qmail@web3814.mail.bbt.yahoo.co.jp> Hello I have confirmed your patch octave-3.2.x (hg) /mingw and octave-3.2.3 on cygwin. On octave-3.2.x (hg) /mingw, gswin32c works, while, on octave-3.2.3 on cygwin, gs.exe works. Thank you for your efforts. I think that it is OK. Regards Tatsuro --- Ben Abbott wrote: > > On Nov 22, 2009, at 4:07 PM, Tatsuro MATSUOKA wrote: > > > Hello Ben > > > > Thanks for your efforts. > > > > I have installed two ghostscript. One is for native windows (gswin32.exe ) and the other is > for cygwin > > (gs.exe). > > > > This patch seems to search ghostscript in the order of 'gswin32c.exe', gs.exe and gs? > > If it is so, is 'gswin32c.exe' selected even for cygwin ? > > If it is the case, it will be bad for cygwin. > > > > I think that it is OK to search 'gs.exe' or 'gs' when isunix() is true. > > > > For the people who do not like to use non standard ghostscript binary (e.g. who would like to > use > > gswin32c.exe but not gs.exe from cygwin) , they should set 'GSC' environmental variable. > > > > > > Marco, who is a maintainer of cygwin version maintainer, perhaps have similar opinion on this > matter. > > Please see his reply for 'OCTAVE_PROG_GHOSTSCRIPT for windows'. > > > > http://old.nabble.com/Re:-OCTAVE_PROG_GHOSTSCRIPT-for-windows-p26463802.html > > > > At this post, it is also better to hear Macro's opinion. > > > > Regards > > > > Tatsuro > > > > > > > > --- Ben Abbott wrote: > > > >> > >> On Nov 21, 2009, at 10:05 AM, Ben Abbott wrote: > >> > >>> On Nov 21, 2009, at 9:15 AM, Benjamin Lindner wrote: > >>> > >>>>> Michael or other Window users, > >>>>> Can you confirm the attached works? > >>>>> Ben > >>>> > >>>> The console version of ghostscript on win32 is called "gswin32c.exe". > >>>> There is also a GUI version, which is called "gswin32.exe". > >>>> I don't see the reason for using the gui version. What if you want to > >>>> pipe commands to ghostscript? > >>>> > >>>> If one insists on using the GUI version, well then you can specify > >>>> it in GSC anyway, but in my opinion the correct version to use > >>>> by default is the console version. Hence "gswin32c.exe" > >>>> > >>>> benjamin > >>> > >>> Ok, my understanding is that EXEC_PATH is equivalent to the PATH environment variable that > was > >> in place when Octave was run. Which is likely to include the default shell's PATH as well as > >> additions needed to run Octave. In the event ghostscript is bundled with Octave, then > EXEC_PATH > >> is preferred over PATH. > >>> > >>> The attached changeset looks for the console version of ghostscript, "gswin32c.exe", and > still > >> searches EXEC_PATH for gswin32c.exe. > >>> > >>> Ben > >>> > >>> > >> > >> If I understand correctly ... > >> > >> isunix() == true for cygwin and unix systems. > >> ispc() == true for Win32 and mingw > >> > >> For Win32, mingw, and cygwin, I assume that "gswin32c.exe", and "gs.exe" may each represent > the > >> ghostscript binary? > >> > >> For cygwin and unix, the binary may be "gs". > >> > >> Thus, I don't see the utility of using isunix() or ispc() ... hence another proposed > changeset. > >> > >> Ben > >> > > > Ok ... a fourth attempt. > > Ben > > > > > > > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From bpabbott at mac.com Sun Nov 22 18:18:50 2009 From: bpabbott at mac.com (Ben Abbott) Date: Sun, 22 Nov 2009 19:18:50 -0500 Subject: Print to PDF under Windows [changeset-4] In-Reply-To: <20091122235846.75436.qmail@web3814.mail.bbt.yahoo.co.jp> References: <20091122235846.75436.qmail@web3814.mail.bbt.yahoo.co.jp> Message-ID: ok, I've pushed the changeset. http://hg.savannah.gnu.org/hgweb/octave/rev/131d8c70920a On Nov 22, 2009, at 6:58 PM, Tatsuro MATSUOKA wrote: > Hello > > I have confirmed your patch octave-3.2.x (hg) /mingw and octave-3.2.3 on cygwin. > On octave-3.2.x (hg) /mingw, gswin32c works, while, on octave-3.2.3 on cygwin, gs.exe works. > > Thank you for your efforts. > > I think that it is OK. > > Regards > > Tatsuro > > --- Ben Abbott wrote: > >> >> On Nov 22, 2009, at 4:07 PM, Tatsuro MATSUOKA wrote: >> >>> Hello Ben >>> >>> Thanks for your efforts. >>> >>> I have installed two ghostscript. One is for native windows (gswin32.exe ) and the other is >> for cygwin >>> (gs.exe). >>> >>> This patch seems to search ghostscript in the order of 'gswin32c.exe', gs.exe and gs? >>> If it is so, is 'gswin32c.exe' selected even for cygwin ? >>> If it is the case, it will be bad for cygwin. >>> >>> I think that it is OK to search 'gs.exe' or 'gs' when isunix() is true. >>> >>> For the people who do not like to use non standard ghostscript binary (e.g. who would like to >> use >>> gswin32c.exe but not gs.exe from cygwin) , they should set 'GSC' environmental variable. >>> >>> >>> Marco, who is a maintainer of cygwin version maintainer, perhaps have similar opinion on this >> matter. >>> Please see his reply for 'OCTAVE_PROG_GHOSTSCRIPT for windows'. >>> >>> http://old.nabble.com/Re:-OCTAVE_PROG_GHOSTSCRIPT-for-windows-p26463802.html >>> >>> At this post, it is also better to hear Macro's opinion. >>> >>> Regards >>> >>> Tatsuro >>> >>> >>> >>> --- Ben Abbott wrote: >>> >>>> >>>> On Nov 21, 2009, at 10:05 AM, Ben Abbott wrote: >>>> >>>>> On Nov 21, 2009, at 9:15 AM, Benjamin Lindner wrote: >>>>> >>>>>>> Michael or other Window users, >>>>>>> Can you confirm the attached works? >>>>>>> Ben >>>>>> >>>>>> The console version of ghostscript on win32 is called "gswin32c.exe". >>>>>> There is also a GUI version, which is called "gswin32.exe". >>>>>> I don't see the reason for using the gui version. What if you want to >>>>>> pipe commands to ghostscript? >>>>>> >>>>>> If one insists on using the GUI version, well then you can specify >>>>>> it in GSC anyway, but in my opinion the correct version to use >>>>>> by default is the console version. Hence "gswin32c.exe" >>>>>> >>>>>> benjamin >>>>> >>>>> Ok, my understanding is that EXEC_PATH is equivalent to the PATH environment variable that >> was >>>> in place when Octave was run. Which is likely to include the default shell's PATH as well as >>>> additions needed to run Octave. In the event ghostscript is bundled with Octave, then >> EXEC_PATH >>>> is preferred over PATH. >>>>> >>>>> The attached changeset looks for the console version of ghostscript, "gswin32c.exe", and >> still >>>> searches EXEC_PATH for gswin32c.exe. >>>>> >>>>> Ben >>>>> >>>>> >>>> >>>> If I understand correctly ... >>>> >>>> isunix() == true for cygwin and unix systems. >>>> ispc() == true for Win32 and mingw >>>> >>>> For Win32, mingw, and cygwin, I assume that "gswin32c.exe", and "gs.exe" may each represent >> the >>>> ghostscript binary? >>>> >>>> For cygwin and unix, the binary may be "gs". >>>> >>>> Thus, I don't see the utility of using isunix() or ispc() ... hence another proposed >> changeset. >>>> >>>> Ben >>>> >> >> >> Ok ... a fourth attempt. >> >> Ben >> >> >>> >> >> >> > > > -------------------------------------- > GyaO! - Anime, Dramas, Movies, and Music videos [FREE] > http://pr.mail.yahoo.co.jp/gyao/ From tmacchant at yahoo.co.jp Sun Nov 22 20:16:10 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Mon, 23 Nov 2009 11:16:10 +0900 (JST) Subject: Print to PDF under Windows [changeset-4] In-Reply-To: Message-ID: <20091123021614.71101.qmail@web3805.mail.bbt.yahoo.co.jp> Hello Jaroslav Hajek Please also apply this Ben's changeset to the 3.2.x source trees. Two lines shift occurred but patch itself was successful for print.m in 3.2.x branch. Regards Tatsuro --- Ben Abbott wrote: > ok, I've pushed the changeset. > > http://hg.savannah.gnu.org/hgweb/octave/rev/131d8c70920a > > On Nov 22, 2009, at 6:58 PM, Tatsuro MATSUOKA wrote: > > > Hello > > > > I have confirmed your patch octave-3.2.x (hg) /mingw and octave-3.2.3 on cygwin. > > On octave-3.2.x (hg) /mingw, gswin32c works, while, on octave-3.2.3 on cygwin, gs.exe works. > > > > Thank you for your efforts. > > > > I think that it is OK. > > > > Regards > > > > Tatsuro > > > > --- Ben Abbott wrote: > > > >> > >> On Nov 22, 2009, at 4:07 PM, Tatsuro MATSUOKA wrote: > >> > >>> Hello Ben > >>> > >>> Thanks for your efforts. > >>> > >>> I have installed two ghostscript. One is for native windows (gswin32.exe ) and the other is > >> for cygwin > >>> (gs.exe). > >>> > >>> This patch seems to search ghostscript in the order of 'gswin32c.exe', gs.exe and gs? > >>> If it is so, is 'gswin32c.exe' selected even for cygwin ? > >>> If it is the case, it will be bad for cygwin. > >>> > >>> I think that it is OK to search 'gs.exe' or 'gs' when isunix() is true. > >>> > >>> For the people who do not like to use non standard ghostscript binary (e.g. who would like > to > >> use > >>> gswin32c.exe but not gs.exe from cygwin) , they should set 'GSC' environmental variable. > >>> > >>> > >>> Marco, who is a maintainer of cygwin version maintainer, perhaps have similar opinion on > this > >> matter. > >>> Please see his reply for 'OCTAVE_PROG_GHOSTSCRIPT for windows'. > >>> > >>> http://old.nabble.com/Re:-OCTAVE_PROG_GHOSTSCRIPT-for-windows-p26463802.html > >>> > >>> At this post, it is also better to hear Macro's opinion. > >>> > >>> Regards > >>> > >>> Tatsuro > >>> > >>> > >>> > >>> --- Ben Abbott wrote: > >>> > >>>> > >>>> On Nov 21, 2009, at 10:05 AM, Ben Abbott wrote: > >>>> > >>>>> On Nov 21, 2009, at 9:15 AM, Benjamin Lindner wrote: > >>>>> > >>>>>>> Michael or other Window users, > >>>>>>> Can you confirm the attached works? > >>>>>>> Ben > >>>>>> > >>>>>> The console version of ghostscript on win32 is called "gswin32c.exe". > >>>>>> There is also a GUI version, which is called "gswin32.exe". > >>>>>> I don't see the reason for using the gui version. What if you want to > >>>>>> pipe commands to ghostscript? > >>>>>> > >>>>>> If one insists on using the GUI version, well then you can specify > >>>>>> it in GSC anyway, but in my opinion the correct version to use > >>>>>> by default is the console version. Hence "gswin32c.exe" > >>>>>> > >>>>>> benjamin > >>>>> > >>>>> Ok, my understanding is that EXEC_PATH is equivalent to the PATH environment variable that > >> was > >>>> in place when Octave was run. Which is likely to include the default shell's PATH as well > as > >>>> additions needed to run Octave. In the event ghostscript is bundled with Octave, then > >> EXEC_PATH > >>>> is preferred over PATH. > >>>>> > >>>>> The attached changeset looks for the console version of ghostscript, "gswin32c.exe", and > >> still > >>>> searches EXEC_PATH for gswin32c.exe. > >>>>> > >>>>> Ben > >>>>> > >>>>> > >>>> > >>>> If I understand correctly ... > >>>> > >>>> isunix() == true for cygwin and unix systems. > >>>> ispc() == true for Win32 and mingw > >>>> > >>>> For Win32, mingw, and cygwin, I assume that "gswin32c.exe", and "gs.exe" may each represent > >> the > >>>> ghostscript binary? > >>>> > >>>> For cygwin and unix, the binary may be "gs". > >>>> > >>>> Thus, I don't see the utility of using isunix() or ispc() ... hence another proposed > >> changeset. > >>>> > >>>> Ben > >>>> > >> > >> > >> Ok ... a fourth attempt. > >> > >> Ben > >> > >> > >>> > >> > >> > >> > > > > > > -------------------------------------- > > GyaO! - Anime, Dramas, Movies, and Music videos [FREE] > > http://pr.mail.yahoo.co.jp/gyao/ > > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From tmacchant at yahoo.co.jp Sun Nov 22 20:34:47 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Mon, 23 Nov 2009 11:34:47 +0900 (JST) Subject: [changeset] changet to acinclude.m4 for windows build Message-ID: <20091123023451.75705.qmail@web3801.mail.bbt.yahoo.co.jp> Hello I have merged two changeset to acinclude.m4 in the development branch for building octave on windows. http://old.nabble.com/Chageset-for-delting-the-check-for-pgnuplot-for-developmet-branch-source-trees-td26454981.html http://old.nabble.com/OCTAVE_PROG_GHOSTSCRIPT-for-windows-td26461151.html One is for deleting obsolete and harmful pgnuplot check and the other is to select proper ghostscript binary for making graph for documents in buid process. Regards Tatsuro -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From tmacchant at yahoo.co.jp Sun Nov 22 20:37:44 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Mon, 23 Nov 2009 11:37:44 +0900 (JST) Subject: [changeset] changet to acinclude.m4 for windows build Message-ID: <20091123023744.81286.qmail@web3806.mail.bbt.yahoo.co.jp> Sorry I have forget to attach a file. --- Tatsuro MATSUOKA wrote: > Hello > > I have merged two changeset to acinclude.m4 in the development branch for building octave on > windows. > > http://old.nabble.com/Chageset-for-delting-the-check-for-pgnuplot-for-developmet-branch-source-trees-td26454981.html > http://old.nabble.com/OCTAVE_PROG_GHOSTSCRIPT-for-windows-td26461151.html > > One is for deleting obsolete and harmful pgnuplot check and the other is to select proper > ghostscript > binary for making graph for documents in buid process. > > Regards > > Tatsuro > > -------------------------------------- > GyaO! - Anime, Dramas, Movies, and Music videos [FREE] > http://pr.mail.yahoo.co.jp/gyao/ > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ -------------- next part -------------- A non-text attachment was scrubbed... Name: changeset.acinclude.m4.patch Type: application/x-unknown Size: 1127 bytes Desc: 1323989608-changeset.acinclude.m4.patch Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091123/a4ab041c/attachment.bin From tmacchant at yahoo.co.jp Sun Nov 22 20:58:50 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Mon, 23 Nov 2009 11:58:50 +0900 (JST) Subject: HOWTO for building octave using mingw/msys In-Reply-To: <4B093636.7030008@gmx.net> Message-ID: <20091123025854.65595.qmail@web3803.mail.bbt.yahoo.co.jp> Hello Thanks your note. I have found one of the URLs is changed. http://www.freecommander.org is now http://www.freecommander.com Regards Tatsuro --- Benjamin Lindnerwrote: > Hello, > > I started writing a small HOWTO on building octave for windows using > mingw/msys and the toolchain available on the octave-forge svn repos. > > https://octave.svn.sourceforge.net/svnroot/octave/trunk/octave-forge/admin/Windows/mingw32/HOWTO.txt > > It's work in progress, and doesn't include all details on automake and > gnulib yet. But it's a start. > > I'd like to improve it further, so feedback, comments, criticism, > all is welcome. > > benjamin > -------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ From marco_atzeri at yahoo.it Mon Nov 23 06:24:31 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Mon, 23 Nov 2009 12:24:31 +0000 (GMT) Subject: extra F on function names Message-ID: <533755.89830.qm@web25504.mail.ukl.yahoo.com> Hi, on latest tip I hit a strange linking problem on liboctinterp as a lot of functions (all?) have an extra F at the begin of the name. No issues on libcruft and liboctave. libtool: link: g++-4 -shared -nostdlib /bin/../lib/gcc/i686-pc-cygwin/4.3.4/crtbegin.o .libs/liboctinterp.la.lnkscript -L/pub/hg/octave_build_automake/libcruft/.libs ../liboctave/.libs/liboctave.dll.a -L/bin/../lib/gcc/i686-pc-cygwin/4.3.4/../../.. -L/usr/lib -L/usr/lib/gcc/i686-pc-cygwin/4.3.2 -L/bin/../lib/gcc/i686-pc-cygwin/4.3.4 /pub/hg/octave_build_automake/libcruft/.libs/libcruft.dll.a -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse /usr/lib/libarpack.dll.a /usr/lib/libqrupdate.dll.a /usr/lib/libpcre.dll.a ../libcruft/.libs/libcruft.dll.a /usr/lib/libfftw3.dll.a /usr/lib/libfftw3f.dll.a /usr/lib/libhdf5.dll.a -lpthread /usr/lib/libfontconfig.dll.a /usr/lib/libexpat.dll.a /usr/lib/libfreetype.dll.a -lz /usr/lib/libiconv.dll.a -L/usr/X11R6/lib -lGL -lGLU /usr/lib/libX11.dll.a /usr/lib/libxcb.dll.a /usr/lib/libXau.dll.a /usr/lib/libXdmcp.dll.a -lreadline /usr/lib/libncurses.dll.a /usr/lib/liblapack.dll.a /usr/lib/libblas.dll.a -L/bin/../lib/gcc -L/usr/lib/gcc/i686-pc-cygwin/4.3.4 /usr/lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.a /usr/lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.dll.a -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lwsock32 /usr/lib/gcc/i686-pc-cygwin/4.3.4/libstdc++.dll.a -lgcc_s -lgcc_s -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc_s -lgcc_s /bin/../lib/gcc/i686-pc-cygwin/4.3.4/crtend.o -mieee-fp -o .libs/cygoctinterp-3-3-50+.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/liboctinterp.dll.a Creating library file: .libs/liboctinterp.dll.a.libs/liboctinterp_la-builtins.o: In function `install___contourc___fcns': /pub/hg/octave_build_automake/src/builtins.cc:942: undefined reference to `F__contourc__(octave_value_list const&, int)' .libs/liboctinterp_la-builtins.o: In function `install___convn___fcns': /pub/hg/octave_build_automake/src/builtins.cc:950: undefined reference to `F__convn__(octave_value_list const&, int)' .libs/liboctinterp_la-builtins.o: In function `install___delaunayn___fcns': /pub/hg/octave_build_automake/src/builtins.cc:958: undefined reference to `F__delaunayn__(octave_value_list const&, int)' .libs/liboctinterp_la-builtins.o: In function `install___dsearchn___fcns': /pub/hg/octave_build_automake/src/builtins.cc:966: undefined reference to `F__dsearchn__(octave_value_list const&, int)' .libs/liboctinterp_la-builtins.o: In function `install___glpk___fcns': /pub/hg/octave_build_automake/src/builtins.cc:974: undefined reference to `F__glpk__(octave_value_list const&, int)' .libs/liboctinterp_la-builtins.o: In function `install___lin_interpn___fcns': /pub/hg/octave_build_automake/src/builtins.cc:982: undefined reference to `F__lin_interpn__(octave_value_list const&, int)' anyone else saw it ? Just a check before cleaning all and restart from scratch. on cygwin-1.7 configured with : ../octave/configure --libexecdir=/usr/lib --without-framework-opengl F77=gfortran-4 CXX=g++-4 CPP=cpp-4 CC=gcc-4 LDFLAGS=-no-undefined lt_cv_deplibs_check_method='pass_all' Regards Marco From highegg at gmail.com Mon Nov 23 06:29:11 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Mon, 23 Nov 2009 13:29:11 +0100 Subject: extra F on function names In-Reply-To: <533755.89830.qm@web25504.mail.ukl.yahoo.com> References: <533755.89830.qm@web25504.mail.ukl.yahoo.com> Message-ID: <69d8d540911230429q6c7d8621sab4acb1e69552bdc@mail.gmail.com> On Mon, Nov 23, 2009 at 1:24 PM, Marco Atzeri wrote: > Hi, > on latest tip I hit a strange linking problem on > liboctinterp as a lot of functions (all?) have an extra F > at the begin of the name. > No issues on libcruft and liboctave. > > The F prefix is normal; it is prepended by the DEFUN macros to built-in and compiled function names. > Regards > Marco > > -- 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/20091123/c1d1711b/attachment.html From bpabbott at mac.com Mon Nov 23 06:59:59 2009 From: bpabbott at mac.com (Ben Abbott) Date: Mon, 23 Nov 2009 07:59:59 -0500 Subject: 3.2.4 call for patches In-Reply-To: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> References: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> Message-ID: On Nov 20, 2009, at 5:01 AM, Jaroslav Hajek wrote: > hi there, > > I've spent essentially no time on 3.2.x maintenance last couple of months, and it seems that the sources have again significantly diverged, but I feel like producing one more 3.2.x release before closing the branch and focusing on 3.4.0. > If you have any patches that you'd like to have applied to 3.2.x, please let me know. However, I'm not willing to invest nontrivial amounts of time into the individual transplants, so unless a patch is smoothly applicable and conforms to the binary compatibility policy, someone needs to convert it or the bug will stay unfixed in 3.2.x. > > regards There are two changesets (maybe more?) for the gnuplot backend that should be imported from the developers sources. http://hg.savannah.gnu.org/hgweb/octave/rev/4634a0e9ea1b http://hg.savannah.gnu.org/hgweb/octave/rev/ccad98db781b Ben From marco_atzeri at yahoo.it Mon Nov 23 08:10:30 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Mon, 23 Nov 2009 14:10:30 +0000 (GMT) Subject: extra F on function names In-Reply-To: <69d8d540911230429q6c7d8621sab4acb1e69552bdc@mail.gmail.com> Message-ID: <104538.22655.qm@web25502.mail.ukl.yahoo.com> --- Lun 23/11/09, Jaroslav Hajek ha scritto: > On Mon, Nov 23, 2009 at 1:24 PM, > Marco Atzeri > wrote: > > Hi, > > on latest tip I hit a strange linking problem on > > liboctinterp as a lot of functions (all?) ?have an extra > F > > at the begin of the name. > > No issues on libcruft and liboctave. > > > > The F prefix is normal; it is prepended by the DEFUN macros > to built-in and compiled function names. so it looks that DLD-FUNCTIONS/* like __contourc__.oct are incorrectly called during the linking ? The __contourc__.df and similar should not be used for such scope ? > -- > RNDr. Jaroslav Hajek Marco From jwe at octave.org Mon Nov 23 08:20:39 2009 From: jwe at octave.org (John W. Eaton) Date: Mon, 23 Nov 2009 09:20:39 -0500 Subject: extra F on function names In-Reply-To: <104538.22655.qm@web25502.mail.ukl.yahoo.com> References: <69d8d540911230429q6c7d8621sab4acb1e69552bdc@mail.gmail.com> <104538.22655.qm@web25502.mail.ukl.yahoo.com> Message-ID: <19210.39479.669252.551364@hugo.lan> On 23-Nov-2009, Marco Atzeri wrote: | so it looks that DLD-FUNCTIONS/* like __contourc__.oct | are incorrectly called during the linking ? | The __contourc__.df and similar should not be used | for such scope ? I think the problem is that those functions should not be listed in builtins.cc at all if they will be loaded as .oct files and not linked directly with the octave executable. So you need to find out why the call to mkbuiltins includes them. Maybe it is some variant of the problem I described here: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-November/013840.html ? jwe From individ at acc.umu.se Mon Nov 23 06:27:03 2009 From: individ at acc.umu.se (David Grundberg) Date: Mon, 23 Nov 2009 13:27:03 +0100 Subject: extra F on function names In-Reply-To: <533755.89830.qm@web25504.mail.ukl.yahoo.com> References: <533755.89830.qm@web25504.mail.ukl.yahoo.com> Message-ID: <4B0A7F97.2030308@acc.umu.se> Marco Atzeri wrote: > Hi, > on latest tip I hit a strange linking problem on > liboctinterp as a lot of functions (all?) have an extra F > at the begin of the name. > No issues on libcruft and liboctave. > The extra F is added by the DEFUN macro. David From marco_atzeri at yahoo.it Mon Nov 23 08:35:48 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Mon, 23 Nov 2009 14:35:48 +0000 (GMT) Subject: extra F on function names In-Reply-To: <19210.39479.669252.551364@hugo.lan> Message-ID: <179296.49112.qm@web25505.mail.ukl.yahoo.com> --- Lun 23/11/09, John W. Eaton ha scritto: > On 23-Nov-2009, Marco Atzeri wrote: > > | so it looks that DLD-FUNCTIONS/* like __contourc__.oct > | are incorrectly called during the linking ? > | The __contourc__.df and similar should not be used > | for such scope ? > > I think the problem is that those functions should not be > listed in > builtins.cc at all if they will be loaded as .oct files and > not linked > directly with the octave executable.? So you need to > find out why the > call to mkbuiltins includes them.? Maybe it is some > variant of the > problem I described here: > > ? https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-November/013840.html > > ? > > jwe > John, it seems exactly the same problem. I will test your additional patch and let you know thanks Marco From bpabbott at mac.com Mon Nov 23 20:15:28 2009 From: bpabbott at mac.com (Ben Abbott) Date: Mon, 23 Nov 2009 21:15:28 -0500 Subject: build trouble on MacOS 10.6 In-Reply-To: <55FF98C5-C5F7-416D-9129-31C25F5FA8CA@mac.com> References: <19208.40171.911211.78147@segfault.lan> <55FF98C5-C5F7-416D-9129-31C25F5FA8CA@mac.com> Message-ID: On 21-Nov-2009, Ben Abbott wrote: > The build looks good until Octave is run. > > Making all in interpreter > ../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'txt');" > make[3]: *** [voronoi.txt] Bus error > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 Martin (from Fink) recommended I look into the crash log (it is attached). After looking over the crash log, he noticed that there are two different libstdc++.6.dylib's being linked to (nice catch Martin, I hadn't noticed that). > I don't really know what's going on; I can only speculate. > > What looks suspicious to me is the following: > There are two copies of libstdc++ loaded > > 0x2bf7000 - 0x2c88fe7 +libstdc++.6.dylib /sw/lib/gcc4.4/lib/libstdc++.6.dylib > > 0x98a75000 - 0x98adffe7 libstdc++.6.dylib /usr/lib/libstdc++.6.dylib > > The crash happens inside Apple's libstdc++, and this seems to be pulled in from liboctinterp-3.3.50+.dylib. > > Did you compile parts of that dylib with Fink's c++-4.4 and parts with Apple's c++-4.2? Maybe this leads to the crash. > > -- > Martin Using otool (Mac OSX equivalent to ldd), I checked to see what liboctinterp was linked to. > $ otool -L ./src/.libs/liboctinterp.dylib > ./src/.libs/liboctinterp.dylib: > /sw/lib/octave-3.3.50+/liboctinterp-3.3.50+.dylib (compatibility version 0.0.0, current version 0.0.0) > /sw/lib/octave-3.3.50+/liboctave-3.3.50+.dylib (compatibility version 0.0.0, current version 0.0.0) > /sw/lib/octave-3.3.50+/libcruft-3.3.50+.dylib (compatibility version 0.0.0, current version 0.0.0) > /sw/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0) > /sw/lib/gcc4.4/lib/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0) > /sw/lib/libGraphicsMagick.3.dylib (compatibility version 6.0.0, current version 6.0.0) > /sw/lib/fltk-aqua/lib/libfltk_gl.1.1.dylib (compatibility version 1.1.0, current version 1.1.4) > /sw/lib/fltk-aqua/lib/libfltk.1.1.dylib (compatibility version 1.1.0, current version 1.1.4) > /sw/lib/libfftw3.3.dylib (compatibility version 6.0.0, current version 6.4.0) > /sw/lib/libfftw3f.3.dylib (compatibility version 6.0.0, current version 6.4.0) > /sw/lib/libhdf5.0.dylib (compatibility version 1.0.0, current version 1.0.0) > /sw/lib/libsz.2.dylib (compatibility version 3.0.0, current version 3.0.0) > /usr/X11/lib/libfontconfig.1.dylib (compatibility version 5.0.0, current version 5.0.0) > /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current version 9.0.0) > /sw/lib/libreadline.5.dylib (compatibility version 5.0.0, current version 5.0.0) > /sw/lib/ncurses/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0) > /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0) > /sw/lib/freetype219/lib/libfreetype.6.dylib (compatibility version 10.0.0, current version 10.19.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) > /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 38.0.0) > /sw/lib/gcc4.4/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.13.0) > /sw/lib/gcc4.4/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) The 2nd to the last line indicates a link to /sw/lib/gcc4.4/lib/libstdc++.6.dylib, but there is no indication of Apple's version in /usr/lib/gcc4.4/lib/libstdc++.6.dylib. To see how liboctinterp is built, I deleted the lib and ran make again. > $ rm liboctave*.dylib > $ make > rm -f liboctave.dylib > g++-4 -dynamiclib -single_module -L/sw/lib/fltk-aqua/lib -L/sw/lib/flex/lib -L/sw/lib/gcc4.4/lib/ -L/sw/lib -larpack -lgfortran -lGraphicsMagick -lfltk_gl -lfltk -lpthread -install_name /sw/lib/octave-3.2.3/liboctave.dylib -o liboctave.dylib \ > [... $OBJS ...] > -L../libcruft -L. -lcruft -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -lqrupdate -framework Accelerate -lfftw3 -lfftw3f -lreadline -L/sw/lib -lpcre -lreadline -lncurses -lhdf5 -lz -lm /sw/lib/gcc4.4/lib/libgfortran.dylib > rm -f liboctave.3.2.3.dylib > ln -s liboctave.dylib liboctave.3.2.3.dylib It doesn't appear to me that Octave is aware of /usr/lib/libstdc++.6.dylib when building. Is it possible that /usr/lib/libstdc++.6.dylib being loaded at run time? If so, can someone educate me on the process by which libraries are searched/located? Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: octave_2009-11-22-141641_ben-abbotts-macbook-pro.crash Type: application/octet-stream Size: 24214 bytes Desc: not available Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091123/e78e97dd/attachment-0001.obj From carlo.defalco at gmail.com Mon Nov 23 20:59:45 2009 From: carlo.defalco at gmail.com (Carlo de Falco) Date: Tue, 24 Nov 2009 03:59:45 +0100 Subject: build trouble on MacOS 10.6 In-Reply-To: References: Message-ID: <074D15AD-7BDD-4F93-95E3-49464FBD4058@gmail.com> On 24 Nov 2009, at 03:15, octave-maintainers-request at octave.org wrote: > It doesn't appear to me that Octave is aware of /usr/lib/libstdc++. > 6.dylib when building. Is it possible that /usr/lib/libstdc++. > 6.dylib being loaded at run time? > > If so, can someone educate me on the process by which libraries are > searched/located? > > Ben try: man dyld HTH, c. From highegg at gmail.com Tue Nov 24 00:59:17 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 24 Nov 2009 07:59:17 +0100 Subject: 3.2.4 call for patches In-Reply-To: <19206.39943.125754.303866@segfault.lan> References: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> <19206.39943.125754.303866@segfault.lan> Message-ID: <69d8d540911232259i5c1c586bua616de88e161037d@mail.gmail.com> On Fri, Nov 20, 2009 at 2:39 PM, John W. Eaton wrote: > On 20-Nov-2009, Jaroslav Hajek wrote: > > | I've spent essentially no time on 3.2.x maintenance last couple of > months, > | and it seems that the sources have again significantly diverged, but I > feel > | like producing one more 3.2.x release before closing the branch and > focusing > | on 3.4.0. > | If you have any patches that you'd like to have applied to 3.2.x, please > let > | me know. However, I'm not willing to invest nontrivial amounts of time > into > | the individual transplants, so unless a patch is smoothly applicable and > | conforms to the binary compatibility policy, someone needs to convert it > or > | the bug will stay unfixed in 3.2.x. > > The following patch to allow error to be called with no argument or an > empty argument should also be OK. It doesn't seem to have caused any > problems. > > http://hg.savannah.gnu.org/hgweb/octave/rev/ef45d191d833 > > jwe > transplanted, thanks -- 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/20091124/8f86c332/attachment.html From highegg at gmail.com Tue Nov 24 01:00:58 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 24 Nov 2009 08:00:58 +0100 Subject: 3.2.4 call for patches In-Reply-To: <4B06FD8B.4040703@dbateman.org> References: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> <4B06FD8B.4040703@dbateman.org> Message-ID: <69d8d540911232300iaf7fd6ave110ed356a852443@mail.gmail.com> On Fri, Nov 20, 2009 at 9:35 PM, David Bateman wrote: > Jaroslav Hajek wrote: > >> hi there, >> >> I've spent essentially no time on 3.2.x maintenance last couple of months, >> and it seems that the sources have again significantly diverged, but I >> feel >> like producing one more 3.2.x release before closing the branch and >> focusing >> on 3.4.0. >> If you have any patches that you'd like to have applied to 3.2.x, please >> let >> me know. However, I'm not willing to invest nontrivial amounts of time >> into >> the individual transplants, so unless a patch is smoothly applicable and >> conforms to the binary compatibility policy, someone needs to convert it >> or >> the bug will stay unfixed in 3.2.x. >> >> regards >> >> >> > The changeset > > http://hg.savannah.gnu.org/hgweb/octave/rev/97de6c916498 > > should probably also go into 3.2.4 > > D. > Done, thanks. -- 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/20091124/8b62940e/attachment.html From highegg at gmail.com Tue Nov 24 01:02:26 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 24 Nov 2009 08:02:26 +0100 Subject: 3.2.4 call for patches In-Reply-To: References: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> Message-ID: <69d8d540911232302k379e994y20843acdecceb85d@mail.gmail.com> On Mon, Nov 23, 2009 at 1:59 PM, Ben Abbott wrote: > On Nov 20, 2009, at 5:01 AM, Jaroslav Hajek wrote: > > > hi there, > > > > I've spent essentially no time on 3.2.x maintenance last couple of > months, and it seems that the sources have again significantly diverged, but > I feel like producing one more 3.2.x release before closing the branch and > focusing on 3.4.0. > > If you have any patches that you'd like to have applied to 3.2.x, please > let me know. However, I'm not willing to invest nontrivial amounts of time > into the individual transplants, so unless a patch is smoothly applicable > and conforms to the binary compatibility policy, someone needs to convert it > or the bug will stay unfixed in 3.2.x. > > > > regards > > There are two changesets (maybe more?) for the gnuplot backend that should > be imported from the developers sources. > > http://hg.savannah.gnu.org/hgweb/octave/rev/4634a0e9ea1b > > http://hg.savannah.gnu.org/hgweb/octave/rev/ccad98db781b > > Ben > > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091124/2612500d/attachment.html From highegg at gmail.com Tue Nov 24 01:05:06 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 24 Nov 2009 08:05:06 +0100 Subject: Print to PDF under Windows [changeset-4] In-Reply-To: <20091123021614.71101.qmail@web3805.mail.bbt.yahoo.co.jp> References: <20091123021614.71101.qmail@web3805.mail.bbt.yahoo.co.jp> Message-ID: <69d8d540911232305p5517c4c4pdbc838a1aa9bee16@mail.gmail.com> 2009/11/23 Tatsuro MATSUOKA > Hello Jaroslav Hajek > > Please also apply this Ben's changeset to the 3.2.x source trees. > Two lines shift occurred but patch itself was successful for print.m in > 3.2.x branch. > > Regards > > Tatsuro > > Applied. -- 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/20091124/b7fec9b7/attachment.html From marco_atzeri at yahoo.it Tue Nov 24 01:42:05 2009 From: marco_atzeri at yahoo.it (Marco Atzeri) Date: Tue, 24 Nov 2009 07:42:05 +0000 (GMT) Subject: extra F on function names In-Reply-To: <179296.49112.qm@web25505.mail.ukl.yahoo.com> Message-ID: <694581.66167.qm@web25503.mail.ukl.yahoo.com> --- Lun 23/11/09, Marco Atzeri ha scritto: > --- Lun 23/11/09, John W. Eaton > > ha scritto: > > > On 23-Nov-2009, Marco Atzeri wrote: > > > > | so it looks that DLD-FUNCTIONS/* like > __contourc__.oct > > | are incorrectly called during the linking ? > > | The __contourc__.df and similar should not be used > > | for such scope ? > > > > I think the problem is that those functions should not > be > > listed in > > builtins.cc at all if they will be loaded as .oct > files and > > not linked > > directly with the octave executable.? So you need to > > find out why the > > call to mkbuiltins includes them.? Maybe it is some > > variant of the > > problem I described here: > > > > ? https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-November/013840.html > > > > ? > > > > jwe > > > > John, > it seems exactly the same problem. > I will test your additional patch and let you know > > thanks > Marco > unfortunately the patch is not enough /pub/hg/octave_build/src/builtins.cc:942: undefined reference to `F__contourc__(octave_value_list const&, int)' .libs/liboctinterp_la-builtins.o: In function `install___convn___fcns': /pub/hg/octave_build/src/builtins.cc:950: undefined reference to `F__convn__(octave_value_list const&, int)' .libs/liboctinterp_la-builtins.o: In function `install___delaunayn___fcns': /pub/hg/octave_build/src/builtins.cc:958: undefined reference to `F__delaunayn__(octave_value_list const&, int)' .libs/liboctinterp_la-builtins.o: In function `install___dsearchn___fcns': /pub/hg/octave_build/src/builtins.cc:966: undefined reference to `F__dsearchn__(octave_value_list const&, int)' .libs/liboctinterp_la-builtins.o: In function `install___glpk___fcns': /pub/hg/octave_build/src/builtins.cc:974: undefined reference to `F__glpk__(octave_value_list const&, int)' .libs/liboctinterp_la-builtins.o: In function `install___lin_interpn___fcns': /pub/hg/octave_build/src/builtins.cc:982: undefined reference to `F__lin_interpn__(octave_value_list const&, int)' .libs/liboctinterp_la-builtins.o: In function `install___magick_read___fcns': /pub/hg/octave_build/src/builtins.cc:990: undefined reference to `F__magick_read__(octave_value_list const&, int)' Marco From tmacchant at yahoo.co.jp Tue Nov 24 04:19:29 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Tue, 24 Nov 2009 19:19:29 +0900 (JST) Subject: Fwd: Re: 3.2.4 call for patches Message-ID: <20091124101930.13045.qmail@web3814.mail.bbt.yahoo.co.jp> Hello It will be grateful for me if you apply the patch attached to 3.2.x branch source. Regards Tatsuro --- Tatsuro MATSUOKAwrote: > Hello > > This is not a bug fix. > > However I would like to propose to remove 'pgnuplot' check in aclocal.m4. > > Now on windows there exist 'gnuplot.exe' in cvs trees, which can be used from octave. > The combination of pgnuplot+wgnuplot cannot be worked from octave 3.2. > Checking 'pgnuplot' existence is no loner be useful but is rather harmful. > > Regards > > Tatsuro > --- Jaroslav Hajek wrote: > > > hi there, > > > > I've spent essentially no time on 3.2.x maintenance last couple of months, > > and it seems that the sources have again significantly diverged, but I feel > > like producing one more 3.2.x release before closing the branch and focusing > > on 3.4.0. > > If you have any patches that you'd like to have applied to 3.2.x, please let > > me know. However, I'm not willing to invest nontrivial amounts of time into > > the individual transplants, so unless a patch is smoothly applicable and > > conforms to the binary compatibility policy, someone needs to convert it or > > the bug will stay unfixed in 3.2.x. > > > regards > > > > -- > > RNDr. Jaroslav Hajek > > computing expert & GNU Octave developer > > Aeronautical Research and Test Institute (VZLU) > > Prague, Czech Republic > > url: www.highegg.matfyz.cz > > > > -------------------------------------- > GyaO! - Anime, Dramas, Movies, and Music videos [FREE] > http://pr.mail.yahoo.co.jp/gyao/ -------------------------------------- What is your No.1 Entertainment of 2009? -Yahoo! JAPAN Net BANZUKE 2009 http://pr.mail.yahoo.co.jp/banzuke/ -------------- next part -------------- A non-text attachment was scrubbed... Name: remove_pgnuplot_check.changeset Type: application/x-unknown Size: 812 bytes Desc: pat795928148 Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091124/02649868/attachment-0001.bin From highegg at gmail.com Tue Nov 24 04:42:04 2009 From: highegg at gmail.com (Jaroslav Hajek) Date: Tue, 24 Nov 2009 11:42:04 +0100 Subject: 3.2.4 call for patches In-Reply-To: <20091124101930.13045.qmail@web3814.mail.bbt.yahoo.co.jp> References: <20091124101930.13045.qmail@web3814.mail.bbt.yahoo.co.jp> Message-ID: <69d8d540911240242wb9cbacdl967d8e2e78027a08@mail.gmail.com> 2009/11/24 Tatsuro MATSUOKA > Hello > > It will be grateful for me if you apply the patch attached to 3.2.x branch > source. > > Regards > > Tatsuro > Is this to be applied to the development tree as well? If yes, I'll wait for that then transplant. -- 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/20091124/eac68d94/attachment.html From individ at acc.umu.se Tue Nov 24 05:16:51 2009 From: individ at acc.umu.se (David Grundberg) Date: Tue, 24 Nov 2009 12:16:51 +0100 Subject: 3.2.4 call for patches In-Reply-To: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> References: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> Message-ID: <4B0BC0A3.4070806@acc.umu.se> Jaroslav Hajek wrote: > hi there, > > I've spent essentially no time on 3.2.x maintenance last couple of > months, and it seems that the sources have again significantly > diverged, but I feel like producing one more 3.2.x release before > closing the branch and focusing on 3.4.0. > If you have any patches that you'd like to have applied to 3.2.x, > please let me know. However, I'm not willing to invest nontrivial > amounts of time into the individual transplants, so unless a patch is > smoothly applicable and conforms to the binary compatibility policy, > someone needs to convert it or the bug will stay unfixed in 3.2.x. > > regards > Hi Jaroslav, I think these bug fixing changesets are suitable for transplanting to 3.2.4: http://hg.savannah.gnu.org/hgweb/octave/rev/737624cb7560 list_in_columns: Don't SIGFPE when given empty first argument http://hg.savannah.gnu.org/hgweb/octave/rev/384616240a8f fix internal numel on classes http://hg.savannah.gnu.org/hgweb/octave/rev/3ccd3a03944c Fix fourth argument from sscanf http://hg.savannah.gnu.org/hgweb/octave/rev/9d9f858849c7 Allow and ignore extra outargs from user-defined size methods http://hg.savannah.gnu.org/hgweb/octave/rev/fbf15a0f30f0 Call user-defined subsref/subsasgn with 1xN structs instead of Nx1 Furthermore, these enhancements are minor and could be added without breaking other things: http://hg.savannah.gnu.org/hgweb/octave/rev/6e6d8ea324bc Add property FormatSpacing to root http://hg.savannah.gnu.org/hgweb/octave/rev/2364eebcd644 new root figure properties Best regards, David From tmacchant at yahoo.co.jp Tue Nov 24 08:27:48 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Tue, 24 Nov 2009 23:27:48 +0900 (JST) Subject: Fwd: Re: [changeset] changet to acinclude.m4 for windows build Message-ID: <20091124142753.675.qmail@web3809.mail.bbt.yahoo.co.jp> Hello The previous patch is for 3.2.x. and the patch attached to this mail is for the development branch. Thank you for your kindness. Regards Tatsuro ************************* Hello It will be grateful for me if you apply the patch attached to 3.2.x branch source. Is this to be applied to the development tree as well? If yes, I'll wait for that then transplant. --- Tatsuro MATSUOKA wrote: > Sorry I have forget to attach a file. > > > --- Tatsuro MATSUOKA wrote: > > > Hello > > > > I have merged two changeset to acinclude.m4 in the development branch for building octave on > > windows. > > > > > http://old.nabble.com/Chageset-for-delting-the-check-for-pgnuplot-for-developmet-branch-source-trees-td26454981.html > > http://old.nabble.com/OCTAVE_PROG_GHOSTSCRIPT-for-windows-td26461151.html > > > > One is for deleting obsolete and harmful pgnuplot check and the other is to select proper > > ghostscript > > binary for making graph for documents in buid process. > > > > Regards > > > > Tatsuro -------------------------------------- What is your No.1 Entertainment of 2009? -Yahoo! JAPAN Net BANZUKE 2009 http://pr.mail.yahoo.co.jp/banzuke/ -------------- next part -------------- A non-text attachment was scrubbed... Name: changeset.acinclude.m4.patch Type: application/x-unknown Size: 1127 bytes Desc: pat1160912277 Url : https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20091124/15c88bd9/attachment.bin From jwe at octave.org Tue Nov 24 10:16:06 2009 From: jwe at octave.org (John W. Eaton) Date: Tue, 24 Nov 2009 11:16:06 -0500 Subject: 3.2.4 call for patches In-Reply-To: <4B0BC0A3.4070806@acc.umu.se> References: <69d8d540911200201w725d97b3xe65dba1ccd001075@mail.gmail.com> <4B0BC0A3.4070806@acc.umu.se> Message-ID: <19212.1734.137332.313857@segfault.lan> On 24-Nov-2009, David Grundberg wrote: | Furthermore, these enhancements are minor and could be added without | breaking other things: | | http://hg.savannah.gnu.org/hgweb/octave/rev/6e6d8ea324bc Add property | FormatSpacing to root | http://hg.savannah.gnu.org/hgweb/octave/rev/2364eebcd644 new root figure | properties Does adding data members to a class result in binary incompatibility with previous versions? If so, then we should skip these. jwe From wsf at fultondesigns.co.uk Tue Nov 24 15:49:59 2009 From: wsf at fultondesigns.co.uk (William S Fulton) Date: Tue, 24 Nov 2009 21:49:59 +0000 Subject: distinguishing octave versions with ifdef In-Reply-To: <67abaf50908151451r411017a3tade54fb73baca18f@mail.gmail.com> References: <67abaf50907051725h56c9798fl204808a1f7d6a828@mail.gmail.com> <67abaf50908151451r411017a3tade54fb73baca18f@mail.gmail.com> Message-ID: <4B0C5507.5030601@fultondesigns.co.uk> As Xavier mentioned, this patch is critical for dealing with API changes in a backwards compatible manner. Should we post the patch somewhere else for consideration? William Xavier Delacour wrote: > 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 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 >> From tmacchant at yahoo.co.jp Tue Nov 24 17:12:31 2009 From: tmacchant at yahoo.co.jp (Tatsuro MATSUOKA) Date: Wed, 25 Nov 2009 08:12:31 +0900 (JST) Subject: 3.2.4 call for patches In-Reply-To: <69d8d540911240242wb9cbacdl967d8e2e78027a08@mail.gmail.com> Message-ID: <20091124231235.23937.qmail@web3815.mail.bbt.yahoo.co.jp> Sorry if my reply is duplicate. For changeset for development branch, please see http://old.nabble.com/Fwd:-Re:--changeset--changet-to-acinclude.m4-for-windows-build-p26496879.html This bundles a changeset One is for deleting obsolete and harmful pgnuplot check and the other is to select proper ghostscript binary for making graph for documents in buid process. Perhaps 3.4.0 will be released in the future so that the patch for development is to have higher priority. Thanks! --- Jaroslav Hajek wrote: > 2009/11/24 Tatsuro MATSUOKA > > > Hello > > > > It will be grateful for me if you apply the patch attached to 3.2.x branch > > source. > > > > Regards > > > > Tatsuro > > > > Is this to be applied to the development tree as well? If yes, I'll wait for > that then transplant. > > -- > RNDr. Jaroslav Hajek > computing expert & GNU Octave developer > Aeronautical Research and Test Institute (VZLU) > Prague, Czech Republic > url: www.highegg.matfyz.cz > -------------------------------------- What is your No.1 Entertainment of 2009? -Yahoo! JAPAN Net BANZUKE 2009 http://pr.mail.yahoo.co.jp/banzuke/