gnuplot-beta — Developers and beta testers of new gnuplot code

Re: gpic terminal

[Ethan A M. <sf...@us...>]

On Wednesday, 19 March, 2014 13:48:41 James Cloos wrote:
> >>>>> "EAM" == Ethan A Merritt <sf...@us...> writes:
> 
> JC>> Why was the gpic term disabled?
> 
> EAM> It seems reasonable to reduce the number of default terminal types
> EAM> by omiting ones that are only of historical interest, or used only by 
> EAM> legacy systems.
> 
> gpic matches neither of those.
> 
> EAM> In any case the gpic terminal is still there - "disabled by
> EAM> default" is not the same thing as "deleted".  You can configure it
> EAM> in if you like.
> 
> With that magic ./configure invocation?

./configure --with-gpic
(as of just now)


> It is commented, not #ifdef'ed.  An --enable-gpic/--disable-gpic is
> easier to deal with when using automated build systems.
> 
> JC>> Troff continues to have users, 
> 
> EAM> Does it?  Who?  Do they use the development version of gnuplot?
> 
> Of course.  The groff lists have an active community.  It is in all of
> the major distributions.  And development continues, such as the pdf
> output device which was added several months ago.
> 
> And being part of current distributions means that anyone who tracks
> gnuplot cvs (for any reason, such as tracking other teminals or wanting
> libcerf) and uses roff will hit that intersection.
> 
> I really don't see how anyone could think groff were not in active use.
> 
> EAM> Perhaps, but only if someone can attest this is indeed the case.
> 
> My post did.
> 
> EAM> The documentation was written about 15 years ago, at the same time
> EAM> as the driver itself.
> 
> So?
> 
> EAM> It would be valuable to know if the gpic terminal actually works
> EAM> with the current gnuplot.
> 
> Yes it does, as anyone can test.

I am a bit dubious.  Running "plot x" through the gpic terminal in 4.6.5
shows that the lines are drawn dashed when they should be solid.
I suspect it broke years ago and no one has noticed.
Anyhow, I don't mind adding the configuration option.

If you have an actual piece of documentation that uses gnuplot+gpic+groff
I'd be interested to add it to the test suite so that at least breakage is
noticed.

	Ethan

Re: gpic terminal

[James C. <clo...@jh...>]

>>>>> "EAM" == Ethan A Merritt <sf...@us...> writes:

JC>> Why was the gpic term disabled?

EAM> It seems reasonable to reduce the number of default terminal types
EAM> by omiting ones that are only of historical interest, or used only by 
EAM> legacy systems.

gpic matches neither of those.

EAM> In any case the gpic terminal is still there - "disabled by
EAM> default" is not the same thing as "deleted".  You can configure it
EAM> in if you like.

With that magic ./configure invocation?

It is commented, not #ifdef'ed.  An --enable-gpic/--disable-gpic is
easier to deal with when using automated build systems.

JC>> Troff continues to have users, 

EAM> Does it?  Who?  Do they use the development version of gnuplot?

Of course.  The groff lists have an active community.  It is in all of
the major distributions.  And development continues, such as the pdf
output device which was added several months ago.

And being part of current distributions means that anyone who tracks
gnuplot cvs (for any reason, such as tracking other teminals or wanting
libcerf) and uses roff will hit that intersection.

I really don't see how anyone could think groff were not in active use.

EAM> Perhaps, but only if someone can attest this is indeed the case.

My post did.

EAM> The documentation was written about 15 years ago, at the same time
EAM> as the driver itself.

So?

EAM> It would be valuable to know if the gpic terminal actually works
EAM> with the current gnuplot.

Yes it does, as anyone can test.

-JimC
--
James Cloos <cl...@jh...>         OpenPGP: 1024D/ED7DAEA6

sprintf on current cvs for mingw build

[Tatsuro M. <tma...@ya...>]

Hello

I have build current cvs (2014-03-18) and carried out the test of all.
Tha all.dem stop at:
********************** file stringvar.dem *********************
Hit return to continue

foo = sprintf("%40d %40d %40d %40d %40d %40d",1,2,3,4,5,6)
      ^
"stringvar.dem", line 62: undefined value

I have built the same source on cygwin
and "make check" has been successful.

I have checked from gnuplot command line

gnuplot> foo = sprintf("%40d %40d %40d %40d %40d %40d",1,2,3,4,5,6)
               ^
         undefined value

Hmm

What is wrong?

Regards

Tatsuro
  

Re: Clarification on terminal size for Qt terminal and generally

[Mojca M. <moj...@gm...>]

On Mon, Mar 17, 2014 at 9:27 PM, Ethan A Merritt wrote:
> On Monday, 17 March, 2014 21:21:05 Mojca Miklavec wrote:
>>
>> I'm very grateful for the change that keeps me in terminal as opposed
>> to jumping to the plotting area and having to alt-tab back to terminal
>> after every command.
>
> Huh???
> The only terminal I've ever seen do that is the Windows terminal.
> That doesn't sound like something that was ever requested by gnuplot
> core or qt terminal code.

But it behaves that way on Mac with qt terminal since the beginning, I believe.

> Could it be that you have changed the focus policy in your  window manager?

I don't have any clue how to "change the focus policy" on Mac (I don't
know that for Linux either, but it's not like Mac OS X is very
configurable in that respect). But I didn't touch any settings anyway
other than switching back and forth between Qt 4 and 5.

But I checked again. I'm unable to compile Daniel's patch with Qt4
without modifications. The code from "trunk" still puts the plot to
front with Qt 4. But it keeps the plot in background with Qt 5. So it
probably wasn't Daniel's patch. It might be that Qt 5 is simply
behaving different than Qt 4.

(There are sooooo many different combinations of Qt and gnuplot
versions that I mixed that up a bit. I don't remember seeing the
window kept it background, but maybe I simply forgot.)

Mojca

Re: Clarification on terminal size for Qt terminal and generally

[Ethan A M. <sf...@us...>]

On Monday, 17 March, 2014 21:21:05 Mojca Miklavec wrote:
> 
> I'm very grateful for the change that keeps me in terminal as opposed
> to jumping to the plotting area and having to alt-tab back to terminal
> after every command.

Huh???
The only terminal I've ever seen do that is the Windows terminal.
That doesn't sound like something that was ever requested by gnuplot
core or qt terminal code.
Could it be that you have changed the focus policy in your  window manager?

	Ethan

Re: Clarification on terminal size for Qt terminal and generally

[Mojca M. <moj...@gm...>]

On Sat, Mar 15, 2014 at 4:20 AM, Daniel J Sebald wrote:
> On 03/10/2014 01:36 AM, Daniel J Sebald wrote:
>>
>> On 03/09/2014 04:47 PM, Daniel J Sebald wrote:
>>
>>> I'm in the
>>> middle of programming this right now, so it would be good to know how it
>>> should behave.
>>
>>
>> I've placed an initial version Qt window size retention on the patch
>> tracker:
>>
>> http://sourceforge.net/p/gnuplot/patches/663/
>
>
> Mojca,
>
> If you have some time this weekend, please try out the Qt window size
> retention patch.

I'm very grateful for the change that keeps me in terminal as opposed
to jumping to the plotting area and having to alt-tab back to terminal
after every command.

I'm not sure how to reproduce the following (and maybe I should check
with master), but as a rule of thumb it happened when I had all the
cores 100% occupied with other tasks:

Terminal type set to 'qt'
gnuplot> plot sin(x)
qt_graphics: "QLocalSocket: Socket operation timed out"
qt_graphics: Not receiving requested widget size
Error: short read from gnuplot_qt socket while expecting font metrics
         warning: Too many axis ticks requested (>1e+01)
         warning: Terminal canvas area too small to hold plot.
        Check plot boundary and font sizes.
         warning: Too many axis ticks requested (>1e+01)
         warning: Too many axis ticks requested (>4)

Other than that it sometimes happens that I don't get any text labels
at all (one of the things that Ethan fixed), but don't hold my word
for it because I'm not sure if that was a side effect of forgetting
"make install" or if that was a real issue.

The second plot shrinks – it uses a different plotting area. (The
first plot doesn't fully fit into the window – x axes labels are too
low. The second plot now fixes that by using smaller plotting area.)

I'm not sure about the pattern (how exactly to reproduce it), but very
often sizes of the plots are completely off (either too small or too
big). The ratio seems right, but scaling is not. See the attachment.
Please note that I have "Replot on resize" switched off (because it's
not bearable to have it turned on as it resizes every few pixels.) But
usually the plot should adjust after calling "plot ...". Here it
sometimes does and sometimes doesn't.

>From time to time I also get

gnuplot> qt_graphics: "QLocalSocket: Socket operation timed out"
qt_graphics: Not receiving requested widget size
qt_graphics: "QLocalSocket: Socket operation timed out"
qt_graphics: Not receiving requested widget size

(with "Replot on resize" turned on).

I didn't try to understand the changes in the source code, I was only
testing the functionality.

(I'm not saying that everything reported above is specific to the
patch. Some problems might be present in trunk already. I would need
to check more carefully, but some "errors/problems" are somewhat
random.)

Mojca

Re: noenhanced

[Mojca M. <moj...@gm...>]

On Mon, Mar 17, 2014 at 7:33 PM, Mojca Miklavec wrote:
> On Sun, Mar 16, 2014 at 11:07 PM, Juhász Péter wrote:
>> On Sun, 2014-03-16 at 14:22 -0700, sfeam wrote:
>>
>>> Perhaps the change you see is actually due to defaulting to enhanced
>>> text mode.  Do you see the same thing if you do "set term wxt noenhanced"?
>>
>> Bingo!
>
> "Bingo!" to all my problems with too small font on the Qt terminal on
> Mac as well.

I'm sorry. I was too excited too soon. My observation must have been a
side effect of a mixture of:
- forgetting to run "make install"
- some of my previous attempts to fix the issue
- the fact that "enhanced" made by attempts nonfunctional, while
"noenhanced" made them work (and I didn't know that when I tested)

So I'm in fact still getting the small, almost unreadable font in Qt
by default. Sorry for the noise.

Mojca

noenhanced

[Mojca M. <moj...@gm...>]

(was: wxt terminal breakage)

On Sun, Mar 16, 2014 at 11:07 PM, Juhász Péter wrote:
> On Sun, 2014-03-16 at 14:22 -0700, sfeam wrote:
>
>> Perhaps the change you see is actually due to defaulting to enhanced
>> text mode.  Do you see the same thing if you do "set term wxt noenhanced"?
>
> Bingo!

"Bingo!" to all my problems with too small font on the Qt terminal on
Mac as well.

If I use "set term qt noenhanced" I finally get a decent readable font
(I'm referring to sufficient font size, not to antialiasing or
anything else).

I don't know if this ever worked "properly" though, so it's hard if
not impossible to do a bisection to find the problematic commit.

I've been complaining about too small font size in Qt terminal for a
long time already.

(I don't see any font change in wxt terminal though if I switch to
noenhanced, just it Qt.)

Mojca

Re: wxt terminal breakage

[Juhász P. <pet...@gm...>]

On Sun, 2014-03-16 at 16:08 -0700, sfeam wrote:
> On Sunday, 16 March 2014 11:07:46 PM Juhász Péter wrote:
> > On Sun, 2014-03-16 at 14:22 -0700, sfeam wrote:
> > 
> > > 
> > > Perhaps the change you see is actually due to defaulting to enhanced
> > > text mode.  Do you see the same thing if you do "set term wxt noenhanced"?                                                 
> > > 
> > 
> > Bingo!
> > 
> > I see no font change in noenhanced mode.
> > 
> > I checked with an executable I compiled on 4 March, with that, I don't
> > see any font change even in enhanced mode.
> 
> 
> There are only a few lines in gp_cairo.c that changed.
> Could you bisect or otherwise debug this?
> I'm not seeing this happen, so I don't think I can pursue it here.
> 

If I comment line 1169 in gp_cairo.c

pango_attr_list_insert (AttrList, p_attr_weight);

the problem disappears, that is, the terminal regains its former look.

Peter

Re: unknown type name 'ulong' in compling axis.c

[Tatsuro M. <tma...@ya...>]

--- On Mon, 2014/3/17, sfeam wrote:
> On Monday, 17 March 2014 12:54:39 PM Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > I have tried to build the recent cvs tree (2014-03-16) 
> > using gcc-4.8.2 (MinGW-w64 32bit) 
> > I have met the following error:
> > #********************************************************************
> > /c/MinGW/bin/gcc -c -I/c/Programs/gplibs/include -fno-keep-inline-dllexport -O2 -pipe -I. -I../../src -I../../term/ -D_Windows -DHAVE_CONFIG_H -DPIPES -DWGP_CONSOLE -DCONSOLE_SWITCH_CP -DGNUPLOT_SHARE_DIR=\"share\" -DDEVELOPMENT_VERSION -DUSE_MOUSE=1 -DWIN_IPC -I/c/PROGRA~2/HELPWO~1/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_ICONV  -MMD -MT 'axis.$(O)' -MF axis.d -o axis.co ../../src/axis.c
> > In file included from ../../src/gadgets.h:42:0,
> >                  from ../../src/axis.h:42,
> >                  from ../../src/axis.c:37:
> > ../../src/term_api.h:120:5: error: unknown type name 'ulong'
> >      ulong   p_char;  /* char used if p_type = PT_CHARACTER */
> > #********************************************************************
> > This error comes from the code newly imported:
> > 
> > ulong   p_char;  /* char used if p_type = PT_CHARACTER */
> > 
> > in src/term_api.h.  The gcc-4.8.2 (MinGW-w64 32bit) system seems not to have ulong.
> > 
> > What can I do to compile the new code?
> 
> It is probably OK to replace "ulong" with "unsigned long".
> 
>     Ethan

It was OK. Thanks!

Tatsuro

Re: unknown type name 'ulong' in compling axis.c

[sfeam <sf...@us...>]

On Monday, 17 March 2014 12:54:39 PM Tatsuro MATSUOKA wrote:
> Hello
> 
> I have tried to build the recent cvs tree (2014-03-16) 
> using gcc-4.8.2 (MinGW-w64 32bit) 
> I have met the following error:
> #********************************************************************
> /c/MinGW/bin/gcc -c -I/c/Programs/gplibs/include -fno-keep-inline-dllexport -O2 -pipe -I. -I../../src -I../../term/ -D_Windows -DHAVE_CONFIG_H -DPIPES -DWGP_CONSOLE -DCONSOLE_SWITCH_CP -DGNUPLOT_SHARE_DIR=\"share\" -DDEVELOPMENT_VERSION -DUSE_MOUSE=1 -DWIN_IPC -I/c/PROGRA~2/HELPWO~1/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_ICONV  -MMD -MT 'axis.$(O)' -MF axis.d -o axis.co ../../src/axis.c
> In file included from ../../src/gadgets.h:42:0,
>                  from ../../src/axis.h:42,
>                  from ../../src/axis.c:37:
> ../../src/term_api.h:120:5: error: unknown type name 'ulong'
>      ulong   p_char;  /* char used if p_type = PT_CHARACTER */
> #********************************************************************
> This error comes from the code newly imported:
> 
> ulong   p_char;  /* char used if p_type = PT_CHARACTER */
> 
> in src/term_api.h.  The gcc-4.8.2 (MinGW-w64 32bit) system seems not to have ulong.
> 
> What can I do to compile the new code?

It is probably OK to replace "ulong" with "unsigned long".

	Ethan


> Regards
> 
> Tatsuro
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

unknown type name 'ulong' in compling axis.c

[Tatsuro M. <tma...@ya...>]

Hello

I have tried to build the recent cvs tree (2014-03-16) 
using gcc-4.8.2 (MinGW-w64 32bit) 
I have met the following error:
#********************************************************************
/c/MinGW/bin/gcc -c -I/c/Programs/gplibs/include -fno-keep-inline-dllexport -O2 -pipe -I. -I../../src -I../../term/ -D_Windows -DHAVE_CONFIG_H -DPIPES -DWGP_CONSOLE -DCONSOLE_SWITCH_CP -DGNUPLOT_SHARE_DIR=\"share\" -DDEVELOPMENT_VERSION -DUSE_MOUSE=1 -DWIN_IPC -I/c/PROGRA~2/HELPWO~1/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_ICONV  -MMD -MT 'axis.$(O)' -MF axis.d -o axis.co ../../src/axis.c
In file included from ../../src/gadgets.h:42:0,
                 from ../../src/axis.h:42,
                 from ../../src/axis.c:37:
../../src/term_api.h:120:5: error: unknown type name 'ulong'
     ulong   p_char;  /* char used if p_type = PT_CHARACTER */
#********************************************************************
This error comes from the code newly imported:

ulong   p_char;  /* char used if p_type = PT_CHARACTER */

in src/term_api.h.  The gcc-4.8.2 (MinGW-w64 32bit) system seems not to have ulong.

What can I do to compile the new code?

Regards

Tatsuro

Re: wxt terminal breakage

[sfeam <sf...@us...>]

On Sunday, 16 March 2014 11:07:46 PM Juhász Péter wrote:
> On Sun, 2014-03-16 at 14:22 -0700, sfeam wrote:
> 
> > 
> > Perhaps the change you see is actually due to defaulting to enhanced
> > text mode.  Do you see the same thing if you do "set term wxt noenhanced"?                                                 
> > 
> 
> Bingo!
> 
> I see no font change in noenhanced mode.
> 
> I checked with an executable I compiled on 4 March, with that, I don't
> see any font change even in enhanced mode.


There are only a few lines in gp_cairo.c that changed.
Could you bisect or otherwise debug this?
I'm not seeing this happen, so I don't think I can pursue it here.

	Ethan


> 
> > 	Ethan
> 
> Peter
> 
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: wxt terminal breakage

[Juhász P. <pet...@gm...>]

On Sun, 2014-03-16 at 14:22 -0700, sfeam wrote:

> 
> Perhaps the change you see is actually due to defaulting to enhanced
> text mode.  Do you see the same thing if you do "set term wxt noenhanced"?                                                 
> 

Bingo!

I see no font change in noenhanced mode.

I checked with an executable I compiled on 4 March, with that, I don't
see any font change even in enhanced mode.

> 	Ethan

Peter

Re: wxt terminal breakage

[sfeam <sf...@us...>]

On Sunday, 16 March 2014 02:03:01 AM Juhász Péter wrote:
> Recently I get the following messages when I first plot something with
> the wxt terminal:
> 
> (gnuplot:19451): Gdk-CRITICAL **: IA__gdk_window_get_visual: assertion
> `GDK_IS_WINDOW (window)' failed 
> 
> They appear harmless, but they are annoying.

A bit of googling suggests that for the last year or so a lot of
people have seen that message triggered by a variety of programs.
I get the impression from browsing the bug reports that they may be
coming from the Gnome window manager, but I am not sure of that.
I do know that I am using KDE and have never seen any such messages.

> Also, much more recently, I suspect since the since the addition of
> italic and bold font attributes, the appearance of the wxt terminal
> changed. It uses a different, much thinner and somewhat bigger font for
> the labels and titles, but not for the key.
> Peter Juhasz

There has been no change to the wxt terminal code since December.
The bold/italic markup included a small change to the shared cairo code,
also used by wxt, but I don't know why it would have resulted in changing
your default font.

Perhaps the change you see is actually due to defaulting to enhanced
text mode.  Do you see the same thing if you do "set term wxt noenhanced"?                                                 

	Ethan

Re: dash types

[sfeam <sf...@us...>]

Note: I am putting this out for general discussion on the mailing list.

Peter Juhasz has added an initial framework for setting and tracking
dash patterns as a separate property analogous to point type
or line color. No it doesn't really do much yet, it's just a framework.

Nevertheless there are some basic choices to make and I'm not sure
what people will expect or prefer.

1) Should the default linetype sequence include dash patterns?

This is more or less what it does now in the special case of
"set term ... dash".  But I am in favor of making all lines default
to solid unless you specifically set a dash pattern either by
modifying the linetype or by including it in the plot command.

2) Can we just get rid of the extra terminal option [dash|solid]?

I'd say yes.  Right now in order to include even a single dashed
line in a plot you have to reset the terminal property to "dash",
which then makes _all_ lines dashed unless you go back and change
all the plot and style commands to make them explicitly solid.
That seems backwards.  I would prefer to just leave the terminal
in dash-capable state, but have all lines default to solid unless
a new terminal entry term->dashtype(struct dashtype *dt) has 
been called as a result of some explicit user command.

3) Should the structure describing a dash pattern also contain
a dashlength multiplier?  Should there be a global "set dashlength"?

Currently most terminals that have a "set term ... dash" mode also
allow "set term ... dashlength <val>".  We could get rid of that
along with the {dash|solid} terminal setting, or we could keep it
even if the dash length can also be modified elsewhere.
For example many terminals allow you to set a linewidth multiplier
as part of "set term", but this doesn't stop you from specifying
line width in individual line styles or plot commands.

Or the model could be "set pointsize" which is a multiplier 
applied everywhere on top of the current terminal setting
or line type properties.

	Ethan

wxt terminal breakage

[Juhász P. <pet...@gm...>]

Recently I get the following messages when I first plot something with
the wxt terminal:

(gnuplot:19451): Gdk-CRITICAL **: IA__gdk_window_get_visual: assertion
`GDK_IS_WINDOW (window)' failed

(gnuplot:19451): Gdk-CRITICAL **: IA__gdk_window_get_visual: assertion
`GDK_IS_WINDOW (window)' failed

(gnuplot:19451): Gdk-CRITICAL **: IA__gdk_window_get_visual: assertion
`GDK_IS_WINDOW (window)' failed

(gnuplot:19451): Gdk-CRITICAL **: IA__gdk_window_get_visual: assertion
`GDK_IS_WINDOW (window)' failed


They appear harmless, but they are annoying.


Also, much more recently, I suspect since the since the addition of
italic and bold font attributes, the appearance of the wxt terminal
changed. It uses a different, much thinner and somewhat bigger font for
the labels and titles, but not for the key.

It might be an OS-specific quirk of the font subsystem, but it also
might be a sign of a deeper problem.

Peter Juhasz

Re: Clarification on terminal size for Qt terminal and generally

[Daniel J S. <dan...@ie...>]

On 03/10/2014 01:36 AM, Daniel J Sebald wrote:
> On 03/09/2014 04:47 PM, Daniel J Sebald wrote:
>
>> I'm in the
>> middle of programming this right now, so it would be good to know how it
>> should behave.
>
> I've placed an initial version Qt window size retention on the patch
> tracker:
>
> http://sourceforge.net/p/gnuplot/patches/663/

Mojca,

If you have some time this weekend, please try out the Qt window size 
retention patch.

Dan

Re: gpic terminal

[Ethan A M. <sf...@us...>]

On Wednesday, 12 March, 2014 17:54:48 James Cloos wrote:
> Why was the gpic term disabled?

It seems reasonable to reduce the number of default terminal types
by omiting ones that are only of historical interest, or used only by 
legacy systems.   In part this is because egacy systems are probably
better served by running a contemporaneous version of gnuplot.
They can't make use of the new features anyhow, so why would
they want the latest version?  And if you were to configure a stripped
down version of the current source that is customized to a legacy
system, you'd want to tailor the set of selected terminals anyhow.

In any case the gpic terminal is still there -  "disabled by default" is not
the same thing as "deleted".  You can configure it in if you like.  

> Troff continues to have users, 

Does it?  Who?  Do they use the development version of gnuplot?

> and pic remains the preferred language for graphics in roff.
> 
> It is simple, but that is not unreasonable for many uses.
> 
> Incidently, I presume it would work with heirloom and plan9 troffs.
> Perhaps the docs shouldn't say it were only for groff?

Perhaps, but only if someone can attest this is indeed the case.
The documentation was written about 15 years ago, at the same
time as the driver itself.

It would be valuable to know if the gpic terminal actually works
with the current gnuplot.  The terminal code has not been modified 
since 1999 other than trivial changes to remove compiler warnings.
Do you know for certain that it does still work?

	Ethan

> 
> -JimC
> --
> James Cloos <cl...@jh...>         OpenPGP: 1024D/ED7DAEA6

gpic terminal

[James C. <clo...@jh...>]

Why was the gpic term disabled?

Troff continues to have users, and pic remains the preferred
language for graphics in roff.

It is simple, but that is not unreasonable for many uses.

Incidently, I presume it would work with heirloom and plan9 troffs.
Perhaps the docs shouldn't say it were only for groff?

-JimC
--
James Cloos <cl...@jh...>         OpenPGP: 1024D/ED7DAEA6

Re: Version 4.6.5 released

[Bastian M. <bma...@we...>]

Am 23.02.2014 20:07, schrieb sfeam:
> The source tarball, release notes, and user manual for gnuplot version 4.6.5
> are now available on SourceForge.
>
>      <https://sourceforge.net/projects/gnuplot/>
>
> There is testing binary for windows available in the folder
> in the files --> gnuplot --> "Testing (pre-release) binaries"
>

The second Windows binary release candidate has been on SF for two weeks 
now. According to SF statistics, it has been downloaded about 400 times 
so far. Is it OK to declare these now "offical" and to move the packages 
to the release folder?

Ethan, is there a way for you to move or rename files? I fail to find 
the corresponding buttons ...

   Bastian

Re: RFC: dashtype, aka separate control of line property descibing the dot-dash pattern

[sfeam <sf...@us...>]

On Tuesday, 11 March 2014 08:27:29 AM Tait wrote:
> sfeam said (on 2014/03/10):
> > On Sunday, 09 March 2014 11:49:09 PM Juhász Péter wrote:
> > > ...
> > > So there would be a new line property "dashtype" or "dt", allowed
> > > everywhere a line specification is accepted.
> > > ...
> > > So e.g. "plot for [i=0:10] i*x" would do exactly the same as before.
> > > But "plot for [i=0:10] i*x" dashtype 1 would keep the line pattern the
> > > same for all plotted lines while still cycling the color ...
> > > 
> > Sort of.  I think I would typically define all the linetypes to default
> > to solid, which I suppose is dt 0.
> > 
> > > Here we hit a snag: what do the numeric dashtypes exactly mean?
> > > ...
> > > One final question: what about user-specified patterns? Are they needed
> > > at all? If yes, what would be the preferred syntax?
> > > Should there be a separate "set dashtype" command where the user could
> > > set explicit dash and space lengths? This would offer the most
> > > flexibility, but it would be hard to implement it across all terminals.
> > 
> > See above.  I think we are in agreement.
> > 
> > > Or should there be separate keywords, like "solid", "dashed", "dot-dash"
> > > etc?
> > 
> > I don't like that in the general case, but I suppose it might be
> > useful to accept "solid" as a synonym for "dt 1"  ...
> 
> Do you mean synonym for "dt 0"?

Whichever.  Currently "linetype 0" is the dotted one.
It would be kind of weird if the first and possibly only line in a plot
is anything other than solid, but the sequence starts at lt=1.

 
> I assume that each character space in the dashtype string maps to a
> minimal-length chunk of line? So '-' is a bit of solid line, and ' ' is
> presumably nothing drawn, and '=' would be a double-line. I'm not sure
> what '.' is expected to produce? A dot, but raised to centerline, like
> '·'?
> 
> I thought about inserting other glyphs, e.g. '»'. Or normal letters,
> e.g.
>   set dashtype 2 "----- A --"
>   set dashtype 3 "--- B ----"

This is already possible in version 4.6 using a combination of 
"pointinterval" and "with labels".  This doesn't involve dashtype
that I can see, although one could imagine providing a shortcut 
that accomplishes the same result with a single command rather than
two separate commands. 

> But then one has to deal with fonts, sizes, weights, rotation, offset,
> etc. Maybe it is better to accomplish that sort of idea with just "set
> dashtype 2 "-----   --" and then follow with a second line "with labels"
> to fill in the glyphs. But now the user has to try and synchronize the
> "set samples" and/or "every" so that the letters all fall into the gaps
> in the dashes.

That is what the existing "pointinterval" property is for.


> What do linewidth and pointsize mean to a dotted/dashed line? Does a
> line with dashtype '···········' ignore pointsize and increasing
> linewidth just adds to the vertical height of each dot (thus in the
> extreme making it look more like '|||||||||||')? Or will linewidth
> implicitly also increase the horizontal spacing so '·' -> '•' -> '●' ...
> etc. continues to retain its aspect ratio as it grows larger?

Currently there is a "dashlength" property that is independent of both
"linewidth" and "pointsize".  However right now this is a terminal 
setting rather than a property of the current line or plot.  We might
want to rethink that.

	Ethan

Re: RFC: dashtype, aka separate control of line property descibing the dot-dash pattern

[Tait <gnu...@t4...>]

sfeam said (on 2014/03/10):
> On Sunday, 09 March 2014 11:49:09 PM Juhász Péter wrote:
> > ...
> > So there would be a new line property "dashtype" or "dt", allowed
> > everywhere a line specification is accepted.
> > ...
> > So e.g. "plot for [i=0:10] i*x" would do exactly the same as before.
> > But "plot for [i=0:10] i*x" dashtype 1 would keep the line pattern the
> > same for all plotted lines while still cycling the color ...
> > 
> Sort of.  I think I would typically define all the linetypes to default
> to solid, which I suppose is dt 0.
> 
> > Here we hit a snag: what do the numeric dashtypes exactly mean?
> > ...
> > One final question: what about user-specified patterns? Are they needed
> > at all? If yes, what would be the preferred syntax?
> > Should there be a separate "set dashtype" command where the user could
> > set explicit dash and space lengths? This would offer the most
> > flexibility, but it would be hard to implement it across all terminals.
> 
> See above.  I think we are in agreement.
> 
> > Or should there be separate keywords, like "solid", "dashed", "dot-dash"
> > etc?
> 
> I don't like that in the general case, but I suppose it might be
> useful to accept "solid" as a synonym for "dt 1"  ...

Do you mean synonym for "dt 0"?

Keywords like "dashed" and "dot-dash" seem too limiting if we want to
support user-defined dash types. But predefined dash types are much
easier to implement.

For the user-specified "set dashtype", the user-given pattern is
implicitly assumed to loop around itself?
  set dashtype 1 "--- "
would end up drawing "--- --- --- --- " etc.?

I assume that each character space in the dashtype string maps to a
minimal-length chunk of line? So '-' is a bit of solid line, and ' ' is
presumably nothing drawn, and '=' would be a double-line. I'm not sure
what '.' is expected to produce? A dot, but raised to centerline, like
'·'?

I thought about inserting other glyphs, e.g. '»'. Or normal letters,
e.g.
  set dashtype 2 "----- A --"
  set dashtype 3 "--- B ----"
But then one has to deal with fonts, sizes, weights, rotation, offset,
etc. Maybe it is better to accomplish that sort of idea with just "set
dashtype 2 "-----   --" and then follow with a second line "with labels"
to fill in the glyphs. But now the user has to try and synchronize the
"set samples" and/or "every" so that the letters all fall into the gaps
in the dashes.

What do linewidth and pointsize mean to a dotted/dashed line? Does a
line with dashtype '···········' ignore pointsize and increasing
linewidth just adds to the vertical height of each dot (thus in the
extreme making it look more like '|||||||||||')? Or will linewidth
implicitly also increase the horizontal spacing so '·' -> '•' -> '●' ...
etc. continues to retain its aspect ratio as it grows larger?

Re: How do I test dll for import feature on MinGW?

[Tatsuro M. <tma...@ya...>]

--- On Tue, 2014/3/11, Tatsuro MATSUOKA wrote:
> --- On Tue, 2014/3/11, Bastian Märkisch  wrote:
> 
> > Am 11.03.2014 06:16, schrieb Tatsuro MATSUOKA:
> > > Hello
> > >
> > > I have build the recent cvs source (ChangeLog date 2014-03-10) on MinGW platform.
> > > I would like to test import dll feature.
> > >
> > > Different from cygwin build, Makefile was not made in demo/pluglin directory.
> > >
> > 
> > For the MinGW build we typically use config/mingw/Makefile, not the 
> > autotools (configure). The Makefile has support for building 
> > demo_plugin.dll. Note that you need MSYS to build.
> > 
> 
> >>Note that you need MSYS to build.
> 
> I remove -rdynamic -fPIC flags from Makefile.am and execute ./prepare  and ./configure script. After that I enter demo/plugin and execute 'make'.
> 
> The file "demo_plugin.so.exe" was produced and was renamed as "demo_plugin.dll".
> 
> test of plugin.dem worked correctly!!
> 
> I have gotten gcc command lines. From next time I can use these commands.
>  
> Thanks! 
> 
> Tatsuro
> 

After some consideration, the below command is enough to build dll.

gcc -shared -o demo_plugin.dll demo_plugin.c -DHAVE_CONFIG_H -I. -I../../src -I../../config/mingw

Re: How do I test dll for import feature on MinGW?

[Tatsuro M. <tma...@ya...>]

--- On Tue, 2014/3/11, Bastian Märkisch  wrote:

> Am 11.03.2014 06:16, schrieb Tatsuro MATSUOKA:
> > Hello
> >
> > I have build the recent cvs source (ChangeLog date 2014-03-10) on MinGW platform.
> > I would like to test import dll feature.
> >
> > Different from cygwin build, Makefile was not made in demo/pluglin directory.
> >
> 
> For the MinGW build we typically use config/mingw/Makefile, not the 
> autotools (configure). The Makefile has support for building 
> demo_plugin.dll. Note that you need MSYS to build.
> 

>>Note that you need MSYS to build.

I remove -rdynamic -fPIC flags from Makefile.am and execute ./prepare  and ./configure script. After that I enter demo/plugin and execute 'make'.

The file "demo_plugin.so.exe" was produced and was renamed as "demo_plugin.dll".

test of plugin.dem worked correctly!!

I have gotten gcc command lines. From next time I can use these commands.
 
Thanks! 

Tatsuro