5.2 rc2 tarball now available

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: 5.2 rc2 tarball now available

Daniel J Sebald
On 07/04/2017 08:07 PM, Daniel J Sebald wrote:

> On 07/04/2017 06:23 PM, sfeam via gnuplot-beta wrote:
>> On Wednesday, 05 July 2017 01:08:35 Petr Mikulik wrote:
>>>>> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some
>>>>> Ubuntu) -
>>>>> linking fails.
>>>>>
>>>>> It is this problem:
>>>>>      https://sourceforge.net/p/gnuplot/support-requests/196/
>>>>>
>>>>> The workaround
>>>>>      configure --with-X11
>>>>> described above does not help, while
>>>>>      TERMLIBS="-lX11" ./configure
>>>>> let me gnuplot compile.
>>>>>
>>>>> Can this be fixed?
>>>>
>>>>   No.  It is a bug in the configuration files distributed for libwxgtk.
>>>
>>> Unfortunately it seems to be a wide-spread bug. It is quite
>>> embarassing that a
>>> compile needs googling to fix it locally.
>>>
>>> Cannot "./configure" take care of this? I.e. add the "-lX11" flag if
>>> "something"?
>>
>> That "something" is exactly the problem.   Only some versions of
>> wxWidgets need this, and only for some configurations.   The
>> wx-config tool is supposed to tell us what libraries are needed so
>> we can link them.  But it doesn't mention X11.    So how are we to know?
>
> Actually, I think this is gnuplot's responsibility.  If I do
>
> sebald@ ~ $ wx-config --libs
> -L/usr/lib/x86_64-linux-gnu -pthread   -lwx_gtk2u_xrc-3.0
> -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 -lwx_gtk2u_adv-3.0
> -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0
>
> in that list is "pthread" which I believe is to inform the gcc/c++
> compiler that posix threads are to be used in compiling and linking.  (I
> think pthread is standard across compilers, but I'm not sure.)  In other
> words, it's supposed to be the responsibility of the compiler to deal
> with all the threads issues so long as wxWidgets follows posix.
>
> In the fix for this bug
>
> http://gnuplot.10905.n7.nabble.com/crash-when-using-wxt-in-Ubuntu-12-04-td17318.html
>
>
> the following line was added:
>
> /* Define a new application type, each gui should derive a class from
> wxApp */
> class wxtApp : public wxApp
> {
> public:
> #if defined(WXT_MULTITHREADED) && defined(WX_NEEDS_XINITTHREADS) &&
> defined(X11)
>     /* Magic fix needed by wxgtk3.0 */
>         wxtApp() : wxApp() { XInitThreads(); }
> #endif

I'm not having any problems building/running if I just comment out this
line.  Then again, from my wx-config test, I might be using GTK2 rather
than GTK3, which might be the issue if "wxgtk3.0" is in the comment.

This looks to have been a thread from 2013.  Maybe we should open a bug
report and move the discussion there in hopes of finding someone for
which that crash can be replicated when there is no XInitThreads().

Dan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 5.2 rc2 tarball now available

Daniel J Sebald
On 07/04/2017 08:17 PM, Daniel J Sebald wrote:

>> /* Define a new application type, each gui should derive a class from
>> wxApp */
>> class wxtApp : public wxApp
>> {
>> public:
>> #if defined(WXT_MULTITHREADED) && defined(WX_NEEDS_XINITTHREADS) &&
>> defined(X11)
>>     /* Magic fix needed by wxgtk3.0 */
>>         wxtApp() : wxApp() { XInitThreads(); }
>> #endif
>
> I'm not having any problems building/running if I just comment out this
> line.  Then again, from my wx-config test, I might be using GTK2 rather
> than GTK3, which might be the issue if "wxgtk3.0" is in the comment.
>
> This looks to have been a thread from 2013.  Maybe we should open a bug
> report and move the discussion there in hopes of finding someone for
> which that crash can be replicated when there is no XInitThreads().

Actually, I can replicate the problem, and I found the bug report.
FWIW, I posted some comments and links here:

https://sourceforge.net/p/gnuplot/bugs/1401/?limit=25&page=1#aab6

I suspect a fix not involving manual XInitThreads() might be work beyond
the current release.  (Is it that graphics/GUI action is taking place in
the secondary thread when it isn't supposed to?)

Anyway, I think gnuplot configure is obligated to add -lX11, given the
situation.

Dan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 5.2 rc2 tarball now available

Daniel J Sebald
In reply to this post by Daniel J Sebald
On 07/04/2017 07:53 PM, Daniel J Sebald wrote:

> On 07/04/2017 06:45 PM, sfeam wrote:
>> On Tuesday, 04 July 2017 17:47:56 Daniel J Sebald wrote:
> [snip]
>>> But even in the case of labels with the "boxed" qualifier, I don't see
>>> any mechanism for either feeding the string width from the terminal back
>>> to gnuplot so that it can draw a box,
>>
>> Correct.  The core code gets no feedback from the terminals.
>> For many terminals it is impossible even in theory (e.g. PostScript).
>>
>>> or specifying to the terminal that
>>> it should put a box around the text it is requesting.
>>
>> Not correct.  The boxed text option works exactly by telling the terminal
>> it should put a box around the next block of text that is sent.
>> The terminal does this by itself with no additional help from any core
>> routines.
>
> OK, if that is the case, I'll look at this a little bit and see if I can
> find anything.

I've posted an initial patch for Qt terminal alignment with this bug report:

https://sourceforge.net/p/gnuplot/bugs/1940/

There is a test plot screen capture there for you to look at.  I think
it is going in the right direction, but needs some adjustment after
discussion.

Dan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 5.2 rc2 tarball now available

tmacchant
In reply to this post by Daniel J Sebald
default terminal size

windows: depends on resolution on the current setting ?


Am I right?

Tatsuro



----- Original Message -----

> From: Daniel J Sebald <[hidden email]>
> To: [hidden email]
> Cc:
> Date: 2017/7/5, Wed 04:31
> Subject: Re: 5.2 rc2 tarball now available
>
> Also, I'm wondering about the default terminal sizes:
>
> wxt: 640x384
> qt: 640x480
> x11: 640x450
>
> not that it matters much; it's just that the WXT terminal test output
> looks vertically scrunched compared to Qt.  Other terminals such as PNG
> use 640x480 default.
>
> Dan
>
>
> On 07/04/2017 02:17 PM, Daniel J Sebald wrote:
>>  On 07/04/2017 01:33 PM, Dmitri A. Sergatskov wrote:
>>>  On Tue, Jul 4, 2017 at 1:12 PM, sfeam <[hidden email]
>>>  <mailto:[hidden email]>> wrote:
>>  [snip]
>>>  Here is with dejavu sans mono 9 (this is actually the best fit I could
>>>  get --
>>>  it gets worse for either smaller or bigger sizes).
>>>  ​(This is still on Gnome desktop).​
>>
>>  I notice in the example test plot that people have sent that there is an
>>  extra space between the terminal name and the "terminal test". 
> How
>>  about the change in the attached diff file to make the terminal name
>>  italic-bold and 1.5 times larger to illustrate multiple font features?
>>  That looks pretty good and highlights the terminal in question, plus it
>>  tests whether the user has a bold/italic font.
>>
>>  Dan
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> [hidden email]
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 5.2 rc2 tarball now available

Petr Mikulik
In reply to this post by Daniel J Sebald
>>>>> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some Ubuntu)
>>>>> linking fails.
>>>>>
>>>>> It is this problem:
>>>>>      https://sourceforge.net/p/gnuplot/support-requests/196/
>>>>>
>>>>> The workaround
>>>>>      configure --with-X11
>>>>> described above does not help, while
>>>>>      TERMLIBS="-lX11" ./configure
>>>>> let me gnuplot compile.
>>>>>
>>>>> Can this be fixed?
>>>>
>>>>   No.  It is a bug in the configuration files distributed for libwxgtk.
>>>
>>> Unfortunately it seems to be a wide-spread bug. It is quite embarassing
>>> that a
>>> compile needs googling to fix it locally.
>>>
>>> Cannot "./configure" take care of this? I.e. add the "-lX11" flag if
>>> "something"?
>>
>> That "something" is exactly the problem.   Only some versions of
>> wxWidgets need this, and only for some configurations.   The
>> wx-config tool is supposed to tell us what libraries are needed so
>> we can link them.  But it doesn't mention X11.    So how are we to know?
>
> Actually, I think this is gnuplot's responsibility.  If I do

>Anyway, I think gnuplot configure is obligated to add -lX11, given the
>situation.

I think that ./configure is the place for tests of compile conditions.
There can be some simple case testing whether "-lX11" is needed or not. Is
such a workaround possible?

---
Petr

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 5.2 rc2 tarball now available

Daniel J Sebald
On 07/05/2017 05:08 PM, Petr Mikulik wrote:

>>>>>> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some
>>>>>> Ubuntu) linking fails.
>>>>>>
>>>>>> It is this problem:
>>>>>>      https://sourceforge.net/p/gnuplot/support-requests/196/
>>>>>>
>>>>>> The workaround
>>>>>>      configure --with-X11
>>>>>> described above does not help, while
>>>>>>      TERMLIBS="-lX11" ./configure
>>>>>> let me gnuplot compile.
>>>>>>
>>>>>> Can this be fixed?
>>>>>
>>>>>   No.  It is a bug in the configuration files distributed for
>>>>> libwxgtk.
>>>>
>>>> Unfortunately it seems to be a wide-spread bug. It is quite
>>>> embarassing that a
>>>> compile needs googling to fix it locally.
>>>>
>>>> Cannot "./configure" take care of this? I.e. add the "-lX11" flag if
>>>> "something"?
>>>
>>> That "something" is exactly the problem.   Only some versions of
>>> wxWidgets need this, and only for some configurations.   The
>>> wx-config tool is supposed to tell us what libraries are needed so
>>> we can link them.  But it doesn't mention X11.    So how are we to know?
>>
>> Actually, I think this is gnuplot's responsibility.  If I do
>
>> Anyway, I think gnuplot configure is obligated to add -lX11, given the
>> situation.
>
> I think that ./configure is the place for tests of compile conditions.
> There can be some simple case testing whether "-lX11" is needed or not.
> Is such a workaround possible?

The necessary tests are already present.  The hunks of code that matter
have pre-processor conditionals:

#if defined(WX_NEEDS_XINITTHREADS) && defined(X11)
#include <X11/Xlib.h> /* Magic fix for linking against wxgtk3.0 */
#endif

and WX_NEEDS_XINITTHREADS and X11 are defined from tests within the
configure process.

We only want to include library -lX11 for the building of wx_gui.cpp,
and there is a convenient definition for that:

Makefile:LIBRARIES_FOR_X =  -lX11

The included libraries for wx_gui.cpp are gotten from the wx-config
command as discussed earlier, and it shows up as

Makefile:WX_LIBS = -L/usr/lib/x86_64-linux-gnu -pthread
-lwx_gtk2u_xrc-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0
-lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0
-lwx_baseu_net-3.0 -lwx_baseu-3.0  -lpangocairo-1.0 -lpango-1.0 -lcairo
-lgobject-2.0 -lglib-2.0

So, all we really need do is append LIBRARIES_FOR_X to WX_LIBS if
XInitThreads() is used in the wx_gui code.  If X11 is not present,
LIBRARIES_FOR_X should be empty.

I've attached a six-line patch to the original bug report associated
with the inclusion of XInitThreads() here:

https://sourceforge.net/p/gnuplot/bugs/_discuss/thread/94192961/d1c5/attachment/gnuplot-wxlibs_xinitthreads_configure-djs2017jul06.patch

Dan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 5.2 rc2 tarball now available

Gnuplot - Dev mailing list
On Thursday, 06 July 2017 12:38:13 Daniel J Sebald wrote:

> On 07/05/2017 05:08 PM, Petr Mikulik wrote:
> >>>>>> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some
> >>>>>> Ubuntu) linking fails.
> >>>>>>
> >>>>>> It is this problem:
> >>>>>>      https://sourceforge.net/p/gnuplot/support-requests/196/
> >>>>>>
> >>>>>> The workaround
> >>>>>>      configure --with-X11
> >>>>>> described above does not help, while
> >>>>>>      TERMLIBS="-lX11" ./configure
> >>>>>> let me gnuplot compile.
> >>>>>>
> >>>>>> Can this be fixed?
> >>>>>
> >>>>>   No.  It is a bug in the configuration files distributed for
> >>>>> libwxgtk.
> >>>>
> >>>> Unfortunately it seems to be a wide-spread bug. It is quite
> >>>> embarassing that a
> >>>> compile needs googling to fix it locally.
> >>>>
> >>>> Cannot "./configure" take care of this? I.e. add the "-lX11" flag if
> >>>> "something"?
> >>>
> >>> That "something" is exactly the problem.   Only some versions of
> >>> wxWidgets need this, and only for some configurations.   The
> >>> wx-config tool is supposed to tell us what libraries are needed so
> >>> we can link them.  But it doesn't mention X11.    So how are we to know?
> >>
> >> Actually, I think this is gnuplot's responsibility.  If I do
> >
> >> Anyway, I think gnuplot configure is obligated to add -lX11, given the
> >> situation.
> >
> > I think that ./configure is the place for tests of compile conditions.
> > There can be some simple case testing whether "-lX11" is needed or not.
> > Is such a workaround possible?
>
> The necessary tests are already present.  The hunks of code that matter
> have pre-processor conditionals:
>
> #if defined(WX_NEEDS_XINITTHREADS) && defined(X11)
> #include <X11/Xlib.h> /* Magic fix for linking against wxgtk3.0 */
> #endif
>
> and WX_NEEDS_XINITTHREADS and X11 are defined from tests within the
> configure process.
>
> We only want to include library -lX11 for the building of wx_gui.cpp,
> and there is a convenient definition for that:
>
> Makefile:LIBRARIES_FOR_X =  -lX11
>
> The included libraries for wx_gui.cpp are gotten from the wx-config
> command as discussed earlier, and it shows up as
>
> Makefile:WX_LIBS = -L/usr/lib/x86_64-linux-gnu -pthread
> -lwx_gtk2u_xrc-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0
> -lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0
> -lwx_baseu_net-3.0 -lwx_baseu-3.0  -lpangocairo-1.0 -lpango-1.0 -lcairo
> -lgobject-2.0 -lglib-2.0
>
> So, all we really need do is append LIBRARIES_FOR_X to WX_LIBS if
> XInitThreads() is used in the wx_gui code.  If X11 is not present,
> LIBRARIES_FOR_X should be empty.
>
> I've attached a six-line patch to the original bug report associated
> with the inclusion of XInitThreads() here:
>
> https://sourceforge.net/p/gnuplot/bugs/_discuss/thread/94192961/d1c5/attachment/gnuplot-wxlibs_xinitthreads_configure-djs2017jul06.patch

Unfortunately that doesn't work.

As it shows in the original bug report, wxgtk stupidly insists on the
XInitThreads business  *even if the program doesn't use X11*.

So making gnuplot's configuration rely on LIBRARIES_FOR_X doesn't
resolve the original problem.  It just moves the failure from compile-time
to run-time.  You can test this by configuring like this:

 ./configure --without-x --without-gd --with-wx

Your patch allows it to compile without complaint, but then you get
a run-time failure instead because wxgtk aborts when it finds that
XInitThreads was not called.

This is actually worse than the compile-time failure because at that
point it's too late to fix the problem.  
Hence the warning in the Release Notes.

        Ethan


NB: --without-gd is there because the gd configure tool actually gets this right
and pulls in -lX11 if libgd wants it. If the wxgtk configure tool did the same
we wouldn't have this problem.
 




>
> Dan
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> [hidden email]
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 5.2 rc2 tarball now available

Gnuplot - Dev mailing list
In reply to this post by Petr Mikulik
On Tuesday, 04 July, 2017 17:26:11 Petr Mikulik wrote:

>   Hello,
>
> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some Ubuntu) -
> linking fails.
>
> It is this problem:
>      https://sourceforge.net/p/gnuplot/support-requests/196/
>
> The workaround
>      configure --with-X11
> described above does not help, while
>      TERMLIBS="-lX11" ./configure
> let me gnuplot compile.
>
> Can this be fixed?
>
> ***
>
> Further, I can see that
>   set term qt; test
> does not pass the test of character width (testing rectangle is too narrow),
> while x11 and wxt pass well.
>
> ***
>
> Those two dummy terminals show 90123456789 instead of 0123...90123...9 in the
> character width test:
>   set term dumb; test
>   set term caca; test
>
> ***
>
> Is caca still experimental?
> It's just fun, but it's nice, mouseable and it seems to work, so I propose to
> have it not experimental.
>
> ***
>
> Greetings,
>    Petr

Updates:

1) Auto-detection of a wxt on linux requirement for
        TERMLIBS="-lX11" ./configure

No solution.  The weak point is the wxgtk3 library.
It has several runtime glitches in addition to this configuration issue.  
I do not expect a fix for 5.2  This is a real problem but I don't see
anything we can do about it other than to recommend against using wxgtk
versions higher than 2.8

2) Qt text boxes

I have modified the "test" command to show both the true bounding box
as used by the current terminal (shaded rectangle) and the generic
estimated bounding box used by the core program to reserve space for
text in a plot layout.  It seems some Qt versions report an inaccurate
bounding box width for some fonts (e.g. Qt 5.6.2 + DejaVu Sans).
Nevertheless the terminal's internal bounding box is always more accurate
than the generic estimated box.

Dan Sebald has pointed out that the Qt terminal and the cairo terminals
differ in whether they increase the lower bound of the bounding box to
allow for font descenders.   This is probably fixable but I consider it a
minor issue.  

3) caca terminal still EXPERIMENTAL?

I have libcaca 0.99 beta18.  The gnuplot caca terminal reports:
set term caca driver list
    x11 gl slang ncurses raw null

For me the x11 and gl options are usable although the x11 font handling
has artifacts.  slang and ncurses spew garbage.  raw and null cause
segfaults.  Most of the time changing a caca option causes gnuplot to exit.
So yes, I think we need to warn that the caca terminal is still EXPERIMENTAL.

4) autoconfigure/compile on SunOS

Minor issues only.  The demo for building and linking plugins does
not autoconfigure correction but can be built manually following instructions
in the plugin demo Makefile.
See also various notes attached to Bug #1821

5) Unwanted inclusion of Type 3 fonts in cairo pdf output

The is Bug #1868.  No fix known.   Not a release-blocker.
It would be great if someone would pursue this with the cairographics
project maintainers.

6) Any other known issues?

        Ethan








------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 5.2 rc2 tarball now available

tmacchant
> 6) Any other known issues?
>
>     Ethan
>
This is not an issue but documentation problem for source distribution.
In source distribution, there is a file named "INSTALL".
It is well written but some parts are obsoleted or inadequate.

e.g.

1.
Unix, configure
---------------
   
TERMLIBS="-lX11" ./configure
is required for wxwidgets but is not described

2.
MS-Windows
----------

There's no installer for gnuplot, so if you want a desktop link,
program manager group or an association of *.plt or *.gpl files to
wgnuplot, you'll have to do all that yourself.

The gnuplot for windows has installer now.


*********************
There are much points which are not up-to-date.
Is it better open a bug ticket for "INSTALL" being up-to-date?

Tatsuro

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 5.2 rc2 tarball now available

Gnuplot - Dev mailing list
On Friday, 14 July, 2017 07:36:26 Tatsuro MATSUOKA wrote:

> > 6) Any other known issues?
> >
> >     Ethan
> >
> This is not an issue but documentation problem for source distribution.
> In source distribution, there is a file named "INSTALL".
> It is well written but some parts are obsoleted or inadequate.
>
> e.g.
>
> 1.
> Unix, configure
> ---------------
>    
> TERMLIBS="-lX11" ./configure
> is required for wxwidgets but is not described
>
> 2.
> MS-Windows
> ----------
>
> There's no installer for gnuplot, so if you want a desktop link,
> program manager group or an association of *.plt or *.gpl files to
> wgnuplot, you'll have to do all that yourself.
>
> The gnuplot for windows has installer now.
>
>
> *********************
> There are much points which are not up-to-date.

Good point.
The FAQ, the man page, and the LaTeX tutorial are even more out of date.
Contributions are welcome for all of these.

The same is true for the web site.
The front page is not bad, but the linked pages are getting stale.


> Is it better open a bug ticket for "INSTALL" being up-to-date?

A bug ticket is less useful than a patch containing new text.
Or contribute new text by posting it here on the mailing list.

        Ethan



> Tatsuro


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: 5.2 rc2: new text for INSTALL

Jim Mehl
INSTALL currently contains

Ubuntu:
         ./configure fails to find lua support because Ubuntu packages it as
         "lua5.1" rather than "lua".  You can fix this by adding a symlink
         prior to running ./configure
             ln -s /usr/lib/pkgconfig/lua5.1.pc /usr/lib/pkgconfig/lua.pc

Installation on linux mint mate 18.2 (based on Ubuntu 16.04) did not
require this link.

For older 64 bit systems this should be changed to (update "5.1" to
current version):
ln -s /usr/lib/x86_64-linux-gnu/pkgconfig/lua5.1.pc
/usr/lib/x86_64-linux-gnu/pkgconfig/lua.pc





On 07/13/2017 04:48 PM, Ethan A Merritt via gnuplot-beta wrote:

> On Friday, 14 July, 2017 07:36:26 Tatsuro MATSUOKA wrote:
>>> 6) Any other known issues?
>>>
>>>      Ethan
>>>
>> This is not an issue but documentation problem for source distribution.
>> In source distribution, there is a file named "INSTALL".
>> It is well written but some parts are obsoleted or inadequate.
>>
>> e.g.
>>
>> 1.
>> Unix, configure
>> ---------------
>>      
>> TERMLIBS="-lX11" ./configure
>> is required for wxwidgets but is not described
>>
>> 2.
>> MS-Windows
>> ----------
>>
>> There's no installer for gnuplot, so if you want a desktop link,
>> program manager group or an association of *.plt or *.gpl files to
>> wgnuplot, you'll have to do all that yourself.
>>
>> The gnuplot for windows has installer now.
>>
>>
>> *********************
>> There are much points which are not up-to-date.
> Good point.
> The FAQ, the man page, and the LaTeX tutorial are even more out of date.
> Contributions are welcome for all of these.
>
> The same is true for the web site.
> The front page is not bad, but the linked pages are getting stale.
>
>
>> Is it better open a bug ticket for "INSTALL" being up-to-date?
> A bug ticket is less useful than a patch containing new text.
> Or contribute new text by posting it here on the mailing list.
>
> Ethan
>
>
>
>> Tatsuro
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> [hidden email]
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Aw: Re: 5.2 rc2 tarball now available

Bastian Märkisch
In reply to this post by Gnuplot - Dev mailing list
> 2) Qt text boxes
>
> I have modified the "test" command to show both the true bounding box
> as used by the current terminal (shaded rectangle) and the generic
> estimated bounding box used by the core program to reserve space for
> text in a plot layout.  It seems some Qt versions report an inaccurate
> bounding box width for some fonts (e.g. Qt 5.6.2 + DejaVu Sans).
> Nevertheless the terminal's internal bounding box is always more accurate
> than the generic estimated box.
>
> Dan Sebald has pointed out that the Qt terminal and the cairo terminals
> differ in whether they increase the lower bound of the bounding box to
> allow for font descenders.   This is probably fixable but I consider it a
> minor issue.  

For the Windows terminal the new grey box in the "test" output is much
larger than the "estimated" bounding box. That should be fixed.

>
> 3) caca terminal still EXPERIMENTAL?
>
> I have libcaca 0.99 beta18.  The gnuplot caca terminal reports:
> set term caca driver list
>     x11 gl slang ncurses raw null
>
> For me the x11 and gl options are usable although the x11 font handling
> has artifacts.  slang and ncurses spew garbage.  raw and null cause
> segfaults.  Most of the time changing a caca option causes gnuplot to exit.
> So yes, I think we need to warn that the caca terminal is still EXPERIMENTAL.

Moreover caca does currently not accept keyboard or mouse input in wgnuplot.
(But works using console mode gnuplot on Windows).
Btw. if ncurses or slang drivers work strongly depends on the terminal used.

>
> 4) autoconfigure/compile on SunOS
>
> Minor issues only.  The demo for building and linking plugins does
> not autoconfigure correction but can be built manually following instructions
> in the plugin demo Makefile.
> See also various notes attached to Bug #1821
>
> 5) Unwanted inclusion of Type 3 fonts in cairo pdf output
>
> The is Bug #1868.  No fix known.   Not a release-blocker.
> It would be great if someone would pursue this with the cairographics
> project maintainers.
>
> 6) Any other known issues?
>

The qt terminal on Windows has several known issues without known solution:

1. Slow start-up of first plot command:  On my system the first plot in a
session is only shown with as much as 8 seconds delay. As indicated by Dan
 Sebald, this might (again) be related to fontconfig, see also Octave bug
https://savannah.gnu.org/bugs/?45458 . We had that problem before with
cairo/pango based terminals and first solved it by adding additional
configuration files to the binary distribution (and later by not using
fontconfig any more).
2. After space-raise-console, the first character which is input on the
 command line is lost.
3. replot-on-resize does not work as intended, see bug #1081.  We should
mention this in the release notes and recommend to turn that feature off
for now.

  Bastian

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Aw: Re: 5.2 rc2 tarball now available

Bastian Märkisch
In reply to this post by Gnuplot - Dev mailing list
> Gesendet: Freitag, 14. Juli 2017 um 01:48 Uhr
> Von: "Ethan A Merritt via gnuplot-beta" <[hidden email]>
> An: [hidden email], "Tatsuro MATSUOKA" <[hidden email]>
> Betreff: Re: 5.2 rc2 tarball now available
>
> On Friday, 14 July, 2017 07:36:26 Tatsuro MATSUOKA wrote:
> > > 6) Any other known issues?
> > >
> > >     Ethan
> > >
> > This is not an issue but documentation problem for source distribution.
> > In source distribution, there is a file named "INSTALL".
> > It is well written but some parts are obsoleted or inadequate.
> >
> > e.g.
> >
> > 1.
> > Unix, configure
> > ---------------
> >    
> > TERMLIBS="-lX11" ./configure
> > is required for wxwidgets but is not described
> >
> > 2.
> > MS-Windows
> > ----------
> >
> > There's no installer for gnuplot, so if you want a desktop link,
> > program manager group or an association of *.plt or *.gpl files to
> > wgnuplot, you'll have to do all that yourself.
> >
> > The gnuplot for windows has installer now.
> >
> >
> > *********************
> > There are much points which are not up-to-date.
>
> Good point.
> The FAQ, the man page, and the LaTeX tutorial are even more out of date.
> Contributions are welcome for all of these.
>
> The same is true for the web site.
> The front page is not bad, but the linked pages are getting stale.
>
>
> > Is it better open a bug ticket for "INSTALL" being up-to-date?
>
> A bug ticket is less useful than a patch containing new text.
> Or contribute new text by posting it here on the mailing list.
>
> Ethan
>
>
>
> > Tatsuro
>

There's now a revision of the MS-Windows INSTALL section in CVS for 5.2.

  Bastian

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Aw: Re: 5.2 rc2 tarball now available

Gnuplot - Dev mailing list
In reply to this post by Bastian Märkisch
On Friday, 14 July 2017 06:34:19 Bastian Märkisch wrote:

> > 2) Qt text boxes
> >
> > I have modified the "test" command to show both the true bounding box
> > as used by the current terminal (shaded rectangle) and the generic
> > estimated bounding box used by the core program to reserve space for
> > text in a plot layout.  It seems some Qt versions report an inaccurate
> > bounding box width for some fonts (e.g. Qt 5.6.2 + DejaVu Sans).
> > Nevertheless the terminal's internal bounding box is always more accurate
> > than the generic estimated box.
> >
> > Dan Sebald has pointed out that the Qt terminal and the cairo terminals
> > differ in whether they increase the lower bound of the bounding box to
> > allow for font descenders.   This is probably fixable but I consider it a
> > minor issue.  
>
> For the Windows terminal the new grey box in the "test" output is much
> larger than the "estimated" bounding box. That should be fixed.

Hmm.  The idea is that the "test" output is a diagnostic.  If you see problems
there then maybe something needs to be fixed in the terminal code.
The grey box is draw using essentially "set label boxed noborder fc 'gray'".
So if it is too large then it is a diagnostic that the textbox code draws
too-large boxes.  The estimated bounding box uses essentially
the same code as in boundary.c where the size of plot elements, titles,
key entries, etc are estimated.  If the the "test" output shows a poor fit
then it is a diagnostic that term->h_char and term->v_char are non-optimal.
 

> >
> > 3) caca terminal still EXPERIMENTAL?
> >
> > I have libcaca 0.99 beta18.  The gnuplot caca terminal reports:
> > set term caca driver list
> >     x11 gl slang ncurses raw null
> >
> > For me the x11 and gl options are usable although the x11 font handling
> > has artifacts.  slang and ncurses spew garbage.  raw and null cause
> > segfaults.  Most of the time changing a caca option causes gnuplot to exit.
> > So yes, I think we need to warn that the caca terminal is still EXPERIMENTAL.
>
> Moreover caca does currently not accept keyboard or mouse input in wgnuplot.
> (But works using console mode gnuplot on Windows).
> Btw. if ncurses or slang drivers work strongly depends on the terminal used.

I know that's the theory but so far as I can tell it makes no difference at
all what the TERM environmental variable is set to.  That seems to indicate
that ncurses is not working the way it is supposed to.  I'm not sure whether
the problem is in ncurses or libcaca or caca.trm.   Or the terminal itself,
come to think of it.  I have tried only xterm and konsole.

> >
> > 4) autoconfigure/compile on SunOS
> >
> > Minor issues only.  The demo for building and linking plugins does
> > not autoconfigure correction but can be built manually following instructions
> > in the plugin demo Makefile.
> > See also various notes attached to Bug #1821
> >
> > 5) Unwanted inclusion of Type 3 fonts in cairo pdf output
> >
> > The is Bug #1868.  No fix known.   Not a release-blocker.
> > It would be great if someone would pursue this with the cairographics
> > project maintainers.
> >
> > 6) Any other known issues?
> >
>
> The qt terminal on Windows has several known issues without known solution:
>
> 1. Slow start-up of first plot command:  On my system the first plot in a
> session is only shown with as much as 8 seconds delay. As indicated by Dan
>  Sebald, this might (again) be related to fontconfig, see also Octave bug
> https://savannah.gnu.org/bugs/?45458 . We had that problem before with
> cairo/pango based terminals and first solved it by adding additional
> configuration files to the binary distribution (and later by not using
> fontconfig any more).
> 2. After space-raise-console, the first character which is input on the
>  command line is lost.

That sounds fixable.  Probably the same fix applied for "pause mouse".

I know I sound like a broken record, but I really hate space-raises-console.
Surely there are better fixes that prevent focus-stealing proactively
rather than requiring you to grab it back by hitting an extra space key.

> 3. replot-on-resize does not work as intended, see bug #1081.  We should
> mention this in the release notes and recommend to turn that feature off
> for now.
>
>   Bastian

OK. All of these should be mentioned in "Known Issues" in the
release notes.  Unless they are fixed of course.

        Ethan  



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: Aw: Re: 5.2 rc2 tarball now available

tmacchant
In reply to this post by Bastian Märkisch
----- Original Message -----

>>  > 2.
>>  > MS-Windows
>>  > ----------
>>  >
>>  > There's no installer for gnuplot, so if you want a desktop link,
>>  > program manager group or an association of *.plt or *.gpl files to
>>  > wgnuplot, you'll have to do all that yourself.
>>  >
>>  > The gnuplot for windows has installer now.
>>  >
>>  >
>>  > *********************
>>  > There are much points which are not up-to-date.
>>
>>
>
> There's now a revision of the MS-Windows INSTALL section in CVS for 5.2.
>
>   Bastian
>

Thanks for change.
INSTALL tells that now mingw toolkits are MinGW64/MSYS2 but not MINGW/MSYS.
I think that description of config/mingw/Makefile it to be changed in corresponding way.

Tatsuro


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
12