Menu
▾
▴
gnuplot-beta
|
From: Paavo H. <pa...@os...> - 2010-06-21 14:26:43
|
We are using wgnuplot with a command file, and the problem is that any error messages are lost, all we get is the non-zero wgnuplot exit code. Some googling revealed other people have stumped on this ( http://old.nabble.com/wgnuplot-log-errors-to-a-file-td17511945.html ) - so are there any advances with this issue? I downloaded current version of wgnuplot, but it seems it does not have -l or -log option. TIA Paavo -- View this message in context: http://old.nabble.com/missing-wgnuplot-error-messages-tp28949210p28949210.html Sent from the Gnuplot - Dev mailing list archive at Nabble.com. |
|
From: Paavo H. <pa...@os...> - 2010-06-22 11:00:11
|
Paavo Helde wrote: > > > We are using wgnuplot with a command file, and the problem is that any > error messages are lost, all we get is the non-zero wgnuplot exit code. > Some googling revealed other people have stumped on this ( > http://old.nabble.com/wgnuplot-log-errors-to-a-file-td17511945.html ) - so > are there any advances with this issue? I downloaded current version of > wgnuplot, but it seems it does not have -l or -log option. > > TIA > Paavo > > I now have found that the gnuplot 4.4.0 distribution on Windows also includes the regular gnuplot.exe executable, which nicely outputs errors to stderr. The only problematic point is that it is not a single executable (like wgnuplot.exe in 4.2) any more, but comes with 26 extra DLL-s of 13MB, which are bound to cause conflicts and installation troubles. There also seem to be some unneeded things like lua51.dll, but as they are not delay-linked they cannot be left out. The executable size is a bit smaller than earlier, so I suspect some of the bloat is just caused by using dynamic libraries instead of earlier static. If so, what would be the rationale? Should I try to download the sources and build a statically linked version of it? Regards Paavo -- View this message in context: http://old.nabble.com/missing-wgnuplot-error-messages-tp28949210p28958726.html Sent from the Gnuplot - Dev mailing list archive at Nabble.com. |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2010-06-23 13:56:43
|
Am 22.06.2010 13:00, schrieb Paavo Helde: > There also > seem to be some unneeded things like lua51.dll, but as they are not > delay-linked they cannot be left out. So obviously they _are_ necessary. For the given binary anyway. > The executable size is a bit smaller > than earlier, so I suspect some of the bloat is just caused by using dynamic > libraries instead of earlier static. Neither is it bloat, nor is it caused by dynamic linking. It's caused by the new gnuplot using a whole lot more external libraries than earlier releases, to implement features those never had. And given that we have 3 *.exe files that need the same libraries, it would be really quite wasteful to include them all in each of them by static linking. |
|
From: Tatsuro M. <tma...@ya...> - 2010-06-24 00:47:59
|
Hello --- Paavo Helde wrote: > > > > Paavo Helde wrote: > > > > > > We are using wgnuplot with a command file, and the problem is that any > > error messages are lost, all we get is the non-zero wgnuplot exit code. > > Some googling revealed other people have stumped on this ( > > http://old.nabble.com/wgnuplot-log-errors-to-a-file-td17511945.html ) - so > > are there any advances with this issue? I downloaded current version of > > wgnuplot, but it seems it does not have -l or -log option. > > > > TIA > > Paavo > > > > > > I now have found that the gnuplot 4.4.0 distribution on Windows also > includes the regular gnuplot.exe executable, which nicely outputs errors to > stderr. The only problematic point is that it is not a single executable > (like wgnuplot.exe in 4.2) any more, but comes with 26 extra DLL-s of 13MB, > which are bound to cause conflicts and installation troubles. There also > seem to be some unneeded things like lua51.dll, but as they are not > delay-linked they cannot be left out. The executable size is a bit smaller > than earlier, so I suspect some of the bloat is just caused by using dynamic > libraries instead of earlier static. If so, what would be the rationale? > Should I try to download the sources and build a statically linked version > of it? The lua51.dll is needed to use the lua/tikz terminal so that you cannot delete it. If you want use static linked version of gnuplot for windows, you can use the cvs version binaries provided by Prof. Kakuto from the following, http://www.ring.gr.jp/pub/text/TeX/ptex-win32/w32/ gnuplot-45pl0w32.zip However the binaries does not support the cairo based terminals (wxt, cairopng, and cairopdf) Regards Tatsuro -------------------------------------- 2010 FIFA World Cup News [Yahoo!Sports/sportsnavi] http://pr.mail.yahoo.co.jp/southafrica2010/ |
|
From: Paavo H. <pa...@os...> - 2010-06-24 16:18:46
|
Tatsuro MATSUOKA-5 wrote: > > If you want use static linked version of gnuplot for windows, you can use > the cvs version binaries > provided by Prof. Kakuto from the following, > > http://www.ring.gr.jp/pub/text/TeX/ptex-win32/w32/ > > gnuplot-45pl0w32.zip > > However the binaries does not support the cairo based terminals (wxt, > cairopng, and cairopdf) > Excellent, thanks, this is exactly what we missed. Best regards Paavo -- View this message in context: http://old.nabble.com/missing-wgnuplot-error-messages-tp28949210p28984216.html Sent from the Gnuplot - Dev mailing list archive at Nabble.com. |
|
From: Paavo H. <pa...@os...> - 2010-06-24 16:34:05
|
Hans-Bernhard Bröker-2 wrote: > > Am 22.06.2010 13:00, schrieb Paavo Helde: > >> There also >> seem to be some unneeded things like lua51.dll, but as they are not >> delay-linked they cannot be left out. > > So obviously they _are_ necessary. For the given binary anyway. > >> The executable size is a bit smaller >> than earlier, so I suspect some of the bloat is just caused by using >> dynamic >> libraries instead of earlier static. > > Neither is it bloat, nor is it caused by dynamic linking. It's caused > by the new gnuplot using a whole lot more external libraries than > earlier releases, to implement features those never had. > I understand that new features are needed and important to many people. However, we are using gnuplot only programmatically from another library, in quite limited contexts to produce nice plots (it is superior in that!) and we want to keep it as simple as possible (our own library is already hairy enough). Hans-Bernhard Bröker-2 wrote: > > And given that > we have 3 *.exe files that need the same libraries, it would be really > quite wasteful to include them all in each of them by static linking. > The statically linked gnuplot.exe (http://www.ring.gr.jp/pub/text/TeX/ptex-win32/w32/) appears to be 2.8 MB. Multiply it by three and you still get less than the current 13 MB of DLL-s, so where is the waste? We only use one executable only anyway. Best regards Paavo -- View this message in context: http://old.nabble.com/missing-wgnuplot-error-messages-tp28949210p28984341.html Sent from the Gnuplot - Dev mailing list archive at Nabble.com. |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2010-06-24 19:55:14
|
Am 24.06.2010 18:33, schrieb Paavo Helde: > I understand that new features are needed and important to many people. > However, we are using gnuplot only programmatically from another library, in > quite limited contexts to produce nice plots (it is superior in that!) and > we want to keep it as simple as possible (our own library is already hair > enough). It's always been the case that people with special needs can profit from compiling open-source programs themselves, with just the right (sub-)set of options they need. But the official binaries are primarily for people who can't (or don't want to) compile their own gnuplot, and those people are best served with the maximum set of features. > The statically linked gnuplot.exe > (http://www.ring.gr.jp/pub/text/TeX/ptex-win32/w32/) appears to be 2.8 MB. That's not "the" statically linked gnuplot.exe. It's one of a lot of possible compiled binaries, with a certain set of features. Unless you can demonstrate that that's _the_same_ set of features as that of the release binaries, you're comparing apples to oranges. > We only use one executable only anyway. You are not everybody. |
