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

Re: problems with readline (compilation on mac fails)

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

On Mon, Feb 14, 2011 at 19:01, Ethan A Merritt wrote:
>
>> On the other hand, I am puzzled by the specific line you show from
>> config.log, because I don't see any check for "readline/tilde.h usability"
>> in the configure script generated from current CVS source for either
>> 4.4 or 4.5.  Where did your configure script come from?
>
> And indeed, I now see that the test you quote was present in version 4.2
> but was replaced by different, more extensive configuration tests in later
> versions.  So I suspect that your configure script is out of date and needs
> to be regenerated from current source.

I'm sorry for the noise. I tried with the latest version (running
./prepare again) and it works fine. It seems that ./configure script
was old indeed (I don't remember any problems recently, but it is true
that I usually compile with macports in PATH where the file is
present).

Out of curiosity: is there any reason why "configure" script is not
included in CVS? (That might mean running "prepare" on regular
basis/when things change of course, but would be easier for the end
users.)

On the other hand, there are two files,
    config/djconfig.sh
    missing
which are constantly displayed as being present in repository, but
they keep changing when I run ./prepare (maybe also on other
occasions, for example when running configure or make, I'm not sure).

However I checked again and it seems that only executable bit is changed.

In short: I would like to suggest to add "configure" script to
repository and/or at least add executable bit to the two files
mentioned above.

Thank you very much,
    Mojca

Re: funny filenames on Windows?

[Benjamin L. <bj...@gm...>]

> I'm wondering, is it likely that gnuplot would have a problem on
> MS Windows if the name of a plot file given as a command line
> argument contained an apostrophe?
>
> I ask because of a problem report from a user of my program,
> gretl, which calls gnuplot: in this case the command line (passed
> to the Windows API function CreateProcess) would look something
> like:
>
> "c:\path\to\wgnuplot.exe" "c:\users\silly's\subdir\plot.gp"
>
> The command is not working; I'm not certain the apostrophe is the
> problem but it seems a likely candidate. (I'm pretty sure the plot
> file itself is well-formed.)

How exactly is it "not working"?
I tested your example using a simple tes't.gp file containing
   set term windows
   plot sin(x)

and called c:\path\to\wgnuplot "c:\path\to\tes't.gp"
and it works as expected.

To make sure it's not your plot file that's causing an error, why
don't you try it from within wgnuplot by
load "c:\path\to\whatever.gp"
and see if there are errors?

benjamin

funny filenames on Windows?

[Allin C. <cot...@wf...>]

I'm wondering, is it likely that gnuplot would have a problem on
MS Windows if the name of a plot file given as a command line
argument contained an apostrophe?

I ask because of a problem report from a user of my program,
gretl, which calls gnuplot: in this case the command line (passed
to the Windows API function CreateProcess) would look something
like:

"c:\path\to\wgnuplot.exe" "c:\users\silly's\subdir\plot.gp"

The command is not working; I'm not certain the apostrophe is the
problem but it seems a likely candidate. (I'm pretty sure the plot
file itself is well-formed.)

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: null terminal?

[Peter J. <pet...@gm...>]

On Tue, Feb 15, 2011 at 7:59 AM, Tait <gnu...@t4...> wrote:
>> > Should we perhaps create a null terminal (that silently discards
>> > everything, like /dev/null) to facilitate iterating over files like
>> > above?
>>

The "unknown" terminal can be used for that purpose.

>> That was part of what the "stats" patchset was intended for.
>> https://sourceforge.net/tracker/?func=detail&aid=2894333&group_id=2055&atid=302055
>> I don't know what's happened to the people who were preparing that
>> for inclusion in CVS; it's gone silent.
>

Zoltán Vörös had said that he is not interested in the patch anymore.
Philipp K. Janert had expressed interest in the patch, but that was
the last communication I had from him.

> I remember that. It seemed like a good idea to include as a program in
> contrib. If the original author doesn't mind, maybe it can be revived
> and modified a bit.
>

It seems that he does mind.
The "stats" patch currently exists in two versions: one is on the
Sourceforge tracker, and the other is a version Zoltán Vörös has
created to answer some of the criticism raised on this list. When he
announced that he does not wish to work on it anymore, he sent me his
last version. I was going to make it into a proper patchset with
updated documentation, ready to go into the CVS, but then Philipp told
me not to, because he said he didn't agree with some of the
modifications Zoltán made. I haven't heard from him since.

Péter Juhász

Re: null terminal?

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

> > Should we perhaps create a null terminal (that silently discards
> > everything, like /dev/null) to facilitate iterating over files like
> > above?
>
> That was part of what the "stats" patchset was intended for.
> https://sourceforge.net/tracker/?func=detail&aid=2894333&group_id=2055&atid=302055
> I don't know what's happened to the people who were preparing that
> for inclusion in CVS; it's gone silent.

I remember that. It seemed like a good idea to include as a program in
contrib. If the original author doesn't mind, maybe it can be revived
and modified a bit.

Re: null terminal?

[Ethan M. <eam...@gm...>]

On Monday, February 14, 2011, Tait wrote:
> 
> As gnuplot allows more and more to be done within the program itself,
> constructs like this are increasingly frequent:
> 
> > set term dumb
> > min=10**10
> > plot 'disy.100' u ($3<min?min=$3:min=min,$1):3
> >
> > set term x11
> > plot 'disy.100' u 1:($3/min)
> 
> Should we perhaps create a null terminal (that silently discards
> everything, like /dev/null) to facilitate iterating over files like
> above? 

That was part of what the "stats" patchset was intended for.
https://sourceforge.net/tracker/?func=detail&aid=2894333&group_id=2055&atid=302055
I don't know what's happened to the people who were preparing that
for inclusion in CVS; it's gone silent.

null terminal?

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

As gnuplot allows more and more to be done within the program itself,
constructs like this are increasingly frequent:

> set term dumb
> min=10**10
> plot 'disy.100' u ($3<min?min=$3:min=min,$1):3
>
> set term x11
> plot 'disy.100' u 1:($3/min)

Should we perhaps create a null terminal (that silently discards
everything, like /dev/null) to facilitate iterating over files like
above? The additional output of using "set term dumb" can be inconvenient,
and there's no guarantee that any other particular terminal is present
on a given gnuplot installation.

Re: problems with readline (compilation on mac fails)

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

On Monday, February 14, 2011 09:13:31 am Ethan A Merritt wrote:
> On Monday, February 14, 2011 08:23:21 am Mojca Miklavec wrote:
> > On Mon, Feb 14, 2011 at 17:15, Ethan Merritt <merritt@u.washington.edu> wrote:
> > > On Monday, February 14, 2011, Mojca Miklavec wrote:
> > >> Dear list,
> > >>
> > >> if I remove MacPorts from PATH (I had to do it since I have serious
> > >> problems with AquaTerm), building fails with:
> > >>
> > >> plot.c:110:30: error: readline/tilde.h: No such file or directory
> > >> make[3]: *** [plot.o] Error 1
> > >> make[2]: *** [all-recursive] Error 1
> > >> make[1]: *** [all-recursive] Error 1
> > >> make: *** [all] Error 2
> > >>
> > >> I indeed have no tilde.h except in /opt/local/include/readline/tilde.h
> > >> (and in some TeX-related sources).
> > >
> > > The configure script explicitly tests for the presence of support for
> > > tilde expansion in the local readline.  Did you re-run ./configure
> > > after changing your PATH?
> > 
> > Yes, I did. I tried that again. I did "make clean; ./configure
> > --disable-wxwidgets; make".
> > 
> > From config.log:
> > 
> > configure:8168: checking readline/tilde.h usability
> > configure:8168: gcc -c -g -O2 -ObjC   conftest.c >&5
> > conftest.c:133:28: error: readline/tilde.h: No such file or directory
> > configure:8168: $? = 1
> 
> OK, so then config.h should contain a line
> #define MISSING_RL_TILDE_EXPANSION 1
> 
> If it does not, then I conclude that your system is missing the
> equivalent of the -*devel*- package for readline.  I.e., you still have
> the library in your path but you do not have the matching header files
> in your path.
> 
> On the other hand, I am puzzled by the specific line you show from
> config.log, because I don't see any check for "readline/tilde.h usability"
> in the configure script generated from current CVS source for either
> 4.4 or 4.5.  Where did your configure script come from?

And indeed, I now see that the test you quote was present in version 4.2
but was replaced by different, more extensive configuration tests in later
versions.  So I suspect that your configure script is out of date and needs
to be regenerated from current source.
		Ethan

Re: problems with readline (compilation on mac fails)

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

On Monday, February 14, 2011 08:23:21 am Mojca Miklavec wrote:
> On Mon, Feb 14, 2011 at 17:15, Ethan Merritt <merritt@u.washington.edu> wrote:
> > On Monday, February 14, 2011, Mojca Miklavec wrote:
> >> Dear list,
> >>
> >> if I remove MacPorts from PATH (I had to do it since I have serious
> >> problems with AquaTerm), building fails with:
> >>
> >> plot.c:110:30: error: readline/tilde.h: No such file or directory
> >> make[3]: *** [plot.o] Error 1
> >> make[2]: *** [all-recursive] Error 1
> >> make[1]: *** [all-recursive] Error 1
> >> make: *** [all] Error 2
> >>
> >> I indeed have no tilde.h except in /opt/local/include/readline/tilde.h
> >> (and in some TeX-related sources).
> >
> > The configure script explicitly tests for the presence of support for
> > tilde expansion in the local readline.  Did you re-run ./configure
> > after changing your PATH?
> 
> Yes, I did. I tried that again. I did "make clean; ./configure
> --disable-wxwidgets; make".
> 
> From config.log:
> 
> configure:8168: checking readline/tilde.h usability
> configure:8168: gcc -c -g -O2 -ObjC   conftest.c >&5
> conftest.c:133:28: error: readline/tilde.h: No such file or directory
> configure:8168: $? = 1

OK, so then config.h should contain a line
#define MISSING_RL_TILDE_EXPANSION 1

If it does not, then I conclude that your system is missing the
equivalent of the -*devel*- package for readline.  I.e., you still have
the library in your path but you do not have the matching header files
in your path.

On the other hand, I am puzzled by the specific line you show from
config.log, because I don't see any check for "readline/tilde.h usability"
in the configure script generated from current CVS source for either
4.4 or 4.5.  Where did your configure script come from?

	Ethan

Re: problems with readline (compilation on mac fails)

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

On Mon, Feb 14, 2011 at 17:15, Ethan Merritt <merritt@u.washington.edu> wrote:
> On Monday, February 14, 2011, Mojca Miklavec wrote:
>> Dear list,
>>
>> if I remove MacPorts from PATH (I had to do it since I have serious
>> problems with AquaTerm), building fails with:
>>
>> plot.c:110:30: error: readline/tilde.h: No such file or directory
>> make[3]: *** [plot.o] Error 1
>> make[2]: *** [all-recursive] Error 1
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2
>>
>> I indeed have no tilde.h except in /opt/local/include/readline/tilde.h
>> (and in some TeX-related sources).
>
> The configure script explicitly tests for the presence of support for
> tilde expansion in the local readline.  Did you re-run ./configure
> after changing your PATH?

Yes, I did. I tried that again. I did "make clean; ./configure
--disable-wxwidgets; make".

>From config.log:

configure:8168: checking readline/tilde.h usability
configure:8168: gcc -c -g -O2 -ObjC   conftest.c >&5
conftest.c:133:28: error: readline/tilde.h: No such file or directory
configure:8168: $? = 1


Mojca

Re: problems with readline (compilation on mac fails)

[Ethan M. <merritt@u.washington.edu>]

On Monday, February 14, 2011, Mojca Miklavec wrote:
> Dear list,
> 
> if I remove MacPorts from PATH (I had to do it since I have serious
> problems with AquaTerm), building fails with:
> 
> plot.c:110:30: error: readline/tilde.h: No such file or directory
> make[3]: *** [plot.o] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> 
> I indeed have no tilde.h except in /opt/local/include/readline/tilde.h
> (and in some TeX-related sources). 

The configure script explicitly tests for the presence of support for
tilde expansion in the local readline.  Did you re-run ./configure
after changing your PATH?

libedit fixes

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

Hello list,

Could somebody with a Mac and/or Linux system with editline please 
verify the attached patches?

It contains several fixes for using gnuplot with libedit (version 2.11, 
2008-06-14) on Ubuntu 10.04. I believe all recent flavours of Debian 
also include this version. I hope it does not break anything for the 
more recent version used on Macs.

Did anybody else observe the issues described below?

The following issues should be fixed:


1) cannot change editline settings via .editrc

* plot.c(main): init rl_library_name before first call to editline, 
otherwise .editrc does not work
	

2) history gets "out of sync" when issuing a command that is already in 
history and not the last (command.c:rlgets)

* command.c(rlgets): removing duplicate entries from history does not 
work with editline, so just avoid adding same command repeatedly

   Example:
	print 1
	print 2
	history 5
	print 1
	history 5


3) "history ?..." does not find anything (although it should)

* history.c(history_find_all): editline's version of history_set_pos() 
does not work, so traverse history list manually. Also, history indices 
are reversed wrt GNU readline


4) "history n" prints one item less than when using readline

* history.c(write_history_list): editline's version of history_get() 
uses zero based indices


5) some libedit related code "cleanup"

* command.c(history_command): mention editline in message for missing 
history support

* history.c: use ANSI C definitions

* readline.c(getc_wrapper): generalize code for libeditline

* gp_hist.h: fix typo


--

Bastian

Re: Migrating away from CVS? was: [temporal snapshot of cvs source is prepared]

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

On Mon, Feb 14, 2011 at 08:18, Daniel J Sebald wrote:
> On 02/14/2011 12:05 AM, Tait wrote:
>>
>> Importing history from CVS to either
>> git or Mercurial is relatively pain-free.

... and already done.

> That's good, because we don't want to lose the history.  (In fact,
> someone should archive the revision history somewhere from time to time.)

With git (or mercurial) everyone who fetches the repository gets the
whole history. So if someone deletes the repository on server, the
copies will still be around at every developer. If somebody would
delete CVS or SVN repository and if nobody had a backup, all the
history would be lost.

Neither git nor mercurial are capable of tracking timestamps of files
and one cannot have $Version:$ headers expanded automatically though.

Mojca

Re: Migrating away from CVS? was: [temporal snapshot of cvs source is prepared]

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

> > Mercurial is nice, and I've used it, too. The learning curve of Mercurial
> > is lower, and it certainly appeals to those who don't like/use the
> > index. I find the index to be an invaluable tool.
> 
> Please explain index tool.  I can't recall what that is.

Sorry, I should have been clearer. The index is what one manipulates
with "git add". It's the "platform" that you described earlier. It is
variously called the index, the cache (usually for options like git
diff --cached), or the stage (but usually as a verb, "staged"). It all
means the stuff that will become the next commit.

> > For those wanting
> > to mostly pretend it doesn't exist, git has options like git commit -a
> > (which can be aliased using your shell, or git itself).
> 
> Thereby avoiding the "add to platform" step, correct me if I'm wrong.

Correct.

> Mobile phone free, and still going.

I chose a poor analogy, then.  The concept of branches in git is much
the same as it was with CVS, but the practical usage is a world apart.

In git, branching is easy and cheap. It is no effort at all to create
a branch, delete it, move it in history (if there are no conflicts),
merge it, or switch between branches. This makes branches a useful way
to collect related sets of commits (changes).

I make a new branch (locally on my computer) for every development idea
I try. I can record my progress on these ideas as I go. When I'm done,
it's easy to go back, clean, reorganize, and package it so someone
else can make sense of the history. Or I can throw it away and nobody
else knows what a horrible idea I had. Or I can carry forward my idea
indefinitely, keeping it always up-to-date with the latest upstream
changes (git calls this "rebase"). Nobody else benefits from the last
scenario, but it makes maintaining my own private set of changes easy.

With CVS, I would just accumulate more and more uncommitted changes, or
I'd have to track my changes externally somehow. Either way, it's hard
to revisit what I did, or keep it up to date with upstream changes. Easy
branching is useful to developers even if the gnuplot project itself
never actually creates a branch. And I think the project would want to
create a few branches anyway. Developers can make their local changes
in a different tool than the project uses (as I do currently with git
and gnuplot's CVS, for example), but why force the use of two different
tools?

> > Where git does shine a little brighter than Mercurial is in the maintainer
> > role. Whoever is accepting patches (from SourceForge, mailing list, ...)
> > and committing them will have an easier time in that role with git.
> 
> How or why?

I think I touched on this in the explanation of how the git project
handles user contributions, but it comes down to tools for managing and
incorporating contributions from other users, support for delegating
tasks (like conflict resolution) to others, and minimizing the time
involved in merging and creating releases.

problems with readline (compilation on mac fails)

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

Dear list,

if I remove MacPorts from PATH (I had to do it since I have serious
problems with AquaTerm), building fails with:

plot.c:110:30: error: readline/tilde.h: No such file or directory
make[3]: *** [plot.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I indeed have no tilde.h except in /opt/local/include/readline/tilde.h
(and in some TeX-related sources). I configured gnuplot with
    ./configure  --disable-wxwidgets --without-latex --without-tutorial
Adding --with-readline=bsd solved compilation, but this should somehow
be solved automatically ...

(I'm testing with version 2011-01-10. If something has changed with
respect to readline after that date, I do apologise. I'll try to test
with the latest version again.)

Mojca

(I will try to solve the problem with AquaTerm with Per Persson.
Something is broken both with in AquaTerm and in gnuplot, but I need
to figure out what can be done on the AquaTerm-side first.)

Re: Migrating away from CVS? was: [temporal snapshot of cvs source is prepared]

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

On 02/14/2011 12:05 AM, Tait wrote:
>
>> Mercurial is pretty nice...  Mercurial was a little more straightforward
>> than git; not so bulky, easy to start doing basic things.  Mercurial has
>> a way of creating a local html server if one wants to view the change
>> history.
>
> Mercurial is nice, and I've used it, too. The learning curve of Mercurial
> is lower, and it certainly appeals to those who don't like/use the
> index. I find the index to be an invaluable tool.

Please explain index tool.  I can't recall what that is.


> For those wanting
> to mostly pretend it doesn't exist, git has options like git commit -a
> (which can be aliased using your shell, or git itself).

Thereby avoiding the "add to platform" step, correct me if I'm wrong.


> If you want a zero-configuration web server, there's git instaweb.
>    http://www.kernel.org/pub/software/scm/git/docs/git-instaweb.html
>
> Or as was mentioned by someone else, gitk or git log --graph (along
> with options like --oneline to format as one wishes) can offer a visual
> representation of history.
>
>> Git is good at branching and such. But I don't think gnuplot development
>> has the need for much branching.
>
> I used to think nobody needs a mobile phone, but today I would be
> hard-pressed to live without it.

Mobile phone free, and still going.  I always wonder if the mobile phone 
has made companies more efficient...oh wait, there's my phone, sorry, 
got to leave the meeting and take this in the hallway because it's way 
more important than you guys, I'm back, what were we talking about? oh 
yeah...or less efficient.


> Where git does shine a little brighter than Mercurial is in the maintainer
> role. Whoever is accepting patches (from SourceForge, mailing list, ...)
> and committing them will have an easier time in that role with git.

How or why?


>> From my perhaps biased view, git seems to have more momentum in the
> open-source community than Mercurial. There are more developers working on
> git and more projects using git, which means it's easier to find support,
> less likelihood of bugs or missing features, and a faster response when
> there are (bugs or missing features). The mailing list is high-traffic,
> but between that and the IRC channel (#git on freenode), you can get any
> question answered, perhaps several times over.

I recall Mercurial being very solid, bug wise.  The same is probably 
true of git.  Source control programs seem to me to be a case where bugs 
have a lower tolerance level than bigger applications.  Admittedly, 
Mercurial isn't fast evolving, feature wise.


>> When people submit patches to sourceforge...
>
> If we used git, I would look to the git project itself as a model of how
> to accept and manage user contributions. Patches are created based on
> master (the main branch, or trunk as it would be known in CVS/SVN), then
> submitted  -- mostly via the mailing list -- and applied straight from the
> email to the maintainer's repository (the "git am" command does this),
> in a topic-specific branch. If it looks interesting, it may be merged
> into a branch called "pu", which is basically a collection area for rough
> ideas being developed. After suggestions, cleanup, and modifications, the
> topic-specific branch or pu gets merged into a branch called "next". Next
> is a long-lived branch that represents things expected to appear in the
> next release. If everything goes well for this change on next, then it
> will be merged into master when creating the next release.
>
> There is another branch, "maint", used for regressions and bug
> fixes. Before a new release is made, master is merged back to maint.
>
> This may sound complicated, but there are probably only three branches
> for a project gnuplot's size: next, master, and maint. Changes are made
> to next and graduated to master. Fixes are ported forward to master and
> next from maint. (Or whatever names you want to give each branch.)

Your point about a project gnuplot's size is what my point was about 
branching.  Given the activity level of gnuplot, I don't see branching 
as being anything but more work.  However, the way you are describing 
things, it appears the philosophy of code development is to use some 
branch techniques even for linear development.


> Like Mojca, I'm just a gnuplot user. If I could find more time, I might
> contribute to development. I hope some of the information I've offered
> can be helpful to the developers. The SourceForge blog said, "We are
> also considering the end-of-life of the CVS service and hope to have user
> support in migrating CVS users..." Importing history from CVS to either
> git or Mercurial is relatively pain-free.

That's good, because we don't want to lose the history.  (In fact, 
someone should archive the revision history somewhere from time to time.)

Dan

Migrating away from CVS? was: [temporal snapshot of cvs source is prepared]

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

> Mercurial is pretty nice...  Mercurial was a little more straightforward
> than git; not so bulky, easy to start doing basic things.  Mercurial has
> a way of creating a local html server if one wants to view the change
> history.

Mercurial is nice, and I've used it, too. The learning curve of Mercurial
is lower, and it certainly appeals to those who don't like/use the
index. I find the index to be an invaluable tool. For those wanting
to mostly pretend it doesn't exist, git has options like git commit -a
(which can be aliased using your shell, or git itself).

If you want a zero-configuration web server, there's git instaweb.
  http://www.kernel.org/pub/software/scm/git/docs/git-instaweb.html

Or as was mentioned by someone else, gitk or git log --graph (along
with options like --oneline to format as one wishes) can offer a visual
representation of history.

> Git is good at branching and such. But I don't think gnuplot development
> has the need for much branching.

I used to think nobody needs a mobile phone, but today I would be
hard-pressed to live without it. Having a good tool means previously
unimagined uses for it will begin to appear, once it's available and
understood. Git and Mercurial both do well here. I don't think branching,
per se, is what's magical. What git and projects built on top of git,
like quilt, stgit, and so on, do well, is allow moving and merging of
code with minimal effort. Here, CVS falls flat.

Where git does shine a little brighter than Mercurial is in the maintainer
role. Whoever is accepting patches (from SourceForge, mailing list, ...)
and committing them will have an easier time in that role with git.

>From my perhaps biased view, git seems to have more momentum in the
open-source community than Mercurial. There are more developers working on
git and more projects using git, which means it's easier to find support,
less likelihood of bugs or missing features, and a faster response when
there are (bugs or missing features). The mailing list is high-traffic,
but between that and the IRC channel (#git on freenode), you can get any
question answered, perhaps several times over.

> When people submit patches to sourceforge...

If we used git, I would look to the git project itself as a model of how
to accept and manage user contributions. Patches are created based on
master (the main branch, or trunk as it would be known in CVS/SVN), then
submitted  -- mostly via the mailing list -- and applied straight from the
email to the maintainer's repository (the "git am" command does this),
in a topic-specific branch. If it looks interesting, it may be merged
into a branch called "pu", which is basically a collection area for rough
ideas being developed. After suggestions, cleanup, and modifications, the
topic-specific branch or pu gets merged into a branch called "next". Next
is a long-lived branch that represents things expected to appear in the
next release. If everything goes well for this change on next, then it
will be merged into master when creating the next release.

There is another branch, "maint", used for regressions and bug
fixes. Before a new release is made, master is merged back to maint.

This may sound complicated, but there are probably only three branches
for a project gnuplot's size: next, master, and maint. Changes are made
to next and graduated to master. Fixes are ported forward to master and
next from maint. (Or whatever names you want to give each branch.)

Like Mojca, I'm just a gnuplot user. If I could find more time, I might
contribute to development. I hope some of the information I've offered
can be helpful to the developers. The SourceForge blog said, "We are
also considering the end-of-life of the CVS service and hope to have user
support in migrating CVS users..." Importing history from CVS to either
git or Mercurial is relatively pain-free.

Re: term doc: missing IC_RGBA in image

[Ethan M. <merritt@u.washington.edu>]

On Saturday, February 12, 2011, Mojca Miklavec wrote:
> Dear list,
> 
> The following text in term/README

> doesn't mention IC_RGBA. May I request documenting the third option
> (rgba; at least mentioning it)?

done

term doc: missing IC_RGBA in image

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

Dear list,

The following text in term/README


_image(unsigned M, unsigned N, coordval *image, gpiPoint *corner,
t_imagecolor color_mode)
...
   along rows finishing in the lower right corner.  If 'color_mode' is
   IC_PALETTE, the terminal is to use palette lookup to generate color
   information.  In this scenario the size of 'image' is M*N.  If
   'color_mode' is IC_RGB, the terminal is to use RGB components.  In
...


doesn't mention IC_RGBA. May I request documenting the third option
(rgba; at least mentioning it)?

Thank you,
    Mojca

Re: temporal snapshot of cvs source is prepared

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

On Sat, Feb 12, 2011 at 18:13, Daniel J Sebald wrote:
>
>> When people submit patches to sourceforge (as .diff files):
>
> There are still diff files in distributed source control programs. Can't
> save a whole repository for each bug fix and feature in SourceForge.

There is no need to. I didn't talk about saving the whole repository.

But just as an example ... one could have one main repository and one
repository with patches where each patch would be in its own branch
(until it gets incorporated into main tree or deleted as useless).

People willing to play would just check out the branch with patch they
want to test without having to do anything else at all. Bringing
patches up-to-date and including them into main tree could be 99%
automatic (apart from cases when patches conflict). The other
alternative is to allow users to clone projects, apply the patches in
their personal repositories and submit patches as "pull requests".

But it all takes some expertise from the main developer.

> Looking at other projects
> that have used a distributed source control program would be a good plan.

Probably an extreme case:
    https://github.com/mxcl/homebrew

Almost 1700 forks, 141 pull requests.

Mojca

Re: temporal snapshot of cvs source is prepared

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

On 02/12/2011 02:40 AM, Mojca Miklavec wrote:
> On Sat, Feb 12, 2011 at 01:17, Daniel J Sebald wrote:

>>   I found git to be good, but didn't like the platform concept.
>>   Things have to be moved into a platform and from there checked in.  It
>> just seemed like extraneous keyboard typing.
>
> How exactly do you mean that? (I'm not sure that I understood it properly.)
>
> One thing that you need to do with GIT is:
>
> a) git add<all the files that you want to be comitted>  (you can use
> "git add -A")
> b) git commit
> c) git push<to central repository>
>
> In CVS/SVN that is a single command to do all the three operations at
> once. The drawback of SVN is that you cannot change three files and
> easily commit the changes just for one of them + just two out of three
> changes done in the second file. On the other hand it is easier to
> use.

Yes.  As you point out, there is a multiple step process.  The "add" 
part is the analogy to putting things on a platform, then comes the 
commit.  Mercurial does this in one step, if I recall correctly.  (BTW, 
for those unfamiliar, the "push" is what makes the source control 
program distributed.  I.e., all the commits occur locally on one's one 
repository until one pushes the changes across the network to someone 
else's repository.  One can continue to do commits without the remote 
network having to be active.)


> When people submit patches to sourceforge (as .diff files):

There are still diff files in distributed source control programs. 
Can't save a whole repository for each bug fix and feature in SourceForge.


> - It means extra work when people want to try them out. They need to
> check out a clean CVS tree, apply the patch (in the hope that it will
> be easy to apply), recompile everything. Applying two patches at the
> same time nees extra effort if both patches modify the same file (a
> lot of manual work).

Yes, there is an advantage over CVS.  Git and Mercurial both.  What I 
meant is comparing git against Mercurial (I could have been clearer). 
I'm recalling something about git was better at branching than Mercurial 
is, more powerful.  What it was exactly I'm not sure.  (It had something 
to do with the internal data structure, better tracking or integrating 
across branches.)  But I think for the type of branching used in 
gnuplot, Mercurial might be fine.


> But then again this needs to be the decision of those who commit to
> gnuplot repository (and whose efficiency depends on those tools), not
> of some random users of gnuplot (like me).

It would take a while to figure out such a transition.  E.g., how to 
convert and store changes in the patch repositories, etc.  Looking at 
other projects that have used a distributed source control program would 
be a good plan.


> I had to set up my own (git) repository to be able to maintain my own
> patches (for my own terminal) and keep gnuplot up-to-date at the same
> time, with hardly any overhead. I couldn't do the same based on CVS so
> easily. But that it just my personal "workflow". Developers of gnuplot
> might have different experience and different needs and it is up to
> them to decide what suits them best.

Yes, I believe there are clear advantages over CVS.

Dan

Re: temporal snapshot of cvs source is prepared

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

On Sat, Feb 12, 2011 at 01:17, Daniel J Sebald wrote:
> On 02/11/2011 05:15 PM, Tait wrote:
>>>> If anyone wants, the downloads are also available here:
>>>>      https://github.com/gnuplot/gnuplot
>>>> (and complete history).
>>>
>>> Oh! It's nice.
>>
>> I'll second (third?) the recommendation that we switch away from CVS to
>> git. It's widely used across many open-source projects, it's resilient
>> against the kinds of outages that we're experiencing right now (each clone
>> represents the entire repository + history), and I personally prefer using
>> it. I don't think it matters much whether we move from SF to github or
>> anything else, but the time to move away from CVS is overdue.
>
> A couple years back I evaluated several source control programs.
> Mercurial is pretty nice.  Like git, it is a distributed source control
> program.  (All the changes travel with it when users upload the
> source...I'm thinking that maybe once a year it is a good idea to prune
> and archive the changes.)  Mercurial was a little more straightforward
> than git; not so bulky, easy to start doing basic things.  Mercurial has
> a way of creating a local html server if one wants to view the change
> history.

Git has gitk. I use GitX (http://gitx.frim.nl/, but only for mac)
which also allows interactive work with repository. But I agree, web
interfaces are suboptimal (apart from GitHub, but that one is
commercial).

> I found git to be good, but didn't like the platform concept.
> Things have to be moved into a platform and from there checked in.  It
> just seemed like extraneous keyboard typing.

How exactly do you mean that? (I'm not sure that I understood it properly.)

One thing that you need to do with GIT is:

a) git add <all the files that you want to be comitted> (you can use
"git add -A")
b) git commit
c) git push <to central repository>

In CVS/SVN that is a single command to do all the three operations at
once. The drawback of SVN is that you cannot change three files and
easily commit the changes just for one of them + just two out of three
changes done in the second file. On the other hand it is easier to
use.

(But I agree that GIT has a neverending learning curve. There are so
many useful features, but it takes ages to learn them to make your
life easier.)

> Git is good at branching
> and such.  But I don't think gnuplot development has the need for much
> branching.

Let me explain on a particular example.

When people submit patches to sourceforge (as .diff files):

- It means extra work when people want to try them out. They need to
check out a clean CVS tree, apply the patch (in the hope that it will
be easy to apply), recompile everything. Applying two patches at the
same time nees extra effort if both patches modify the same file (a
lot of manual work).

- It often happens that patches lie there for a long time before they
are incorporated. In the meantime a lot changes in gnuplot source, so
that it is not possible to just apply the patch any more. It needs to
be done manually after a while.

- I don't know the workflows, but from what I understood in recent
conversation, Ethan often has to prepare two patches - one for the
main branch and one for "4.4" branch (one that will remain in "trunk"
and one that will be used for the new release)

- If patches were simply separate branches, it would be easy to just
switch to a different branch & recompile gnuplot, to bring patches
up-to-date, less overhead when maintaining "master" branch and the one
approaching release + a few testing branches for new features.


But then again this needs to be the decision of those who commit to
gnuplot repository (and whose efficiency depends on those tools), not
of some random users of gnuplot (like me).

I had to set up my own (git) repository to be able to maintain my own
patches (for my own terminal) and keep gnuplot up-to-date at the same
time, with hardly any overhead. I couldn't do the same based on CVS so
easily. But that it just my personal "workflow". Developers of gnuplot
might have different experience and different needs and it is up to
them to decide what suits them best.

Mojca

Re: temporal snapshot of cvs source is prepared

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

On 02/11/2011 05:15 PM, Tait wrote:
>>> If anyone wants, the downloads are also available here:
>>>      https://github.com/gnuplot/gnuplot
>>> (and complete history).
>>
>> Oh! It's nice.
>
> I'll second (third?) the recommendation that we switch away from CVS to
> git. It's widely used across many open-source projects, it's resilient
> against the kinds of outages that we're experiencing right now (each clone
> represents the entire repository + history), and I personally prefer using
> it. I don't think it matters much whether we move from SF to github or
> anything else, but the time to move away from CVS is overdue.

A couple years back I evaluated several source control programs. 
Mercurial is pretty nice.  Like git, it is a distributed source control 
program.  (All the changes travel with it when users upload the 
source...I'm thinking that maybe once a year it is a good idea to prune 
and archive the changes.)  Mercurial was a little more straightforward 
than git; not so bulky, easy to start doing basic things.  Mercurial has 
a way of creating a local html server if one wants to view the change 
history.  I found git to be good, but didn't like the platform concept. 
  Things have to be moved into a platform and from there checked in.  It 
just seemed like extraneous keyboard typing.  Git is good at branching 
and such.  But I don't think gnuplot development has the need for much 
branching.

Dan

Re: temporal snapshot of cvs source is prepared

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

> > If anyone wants, the downloads are also available here:
> >     https://github.com/gnuplot/gnuplot
> > (and complete history).
>
> Oh! It's nice.

I'll second (third?) the recommendation that we switch away from CVS to
git. It's widely used across many open-source projects, it's resilient
against the kinds of outages that we're experiencing right now (each clone
represents the entire repository + history), and I personally prefer using
it. I don't think it matters much whether we move from SF to github or
anything else, but the time to move away from CVS is overdue.

Re: ylabel not rotated for enhanced windows terminal

[Benjamin L. <bj...@gm...>]

On Fri, Feb 11, 2011 at 2:14 AM, Ethan Merritt <merritt@u.washington.edu> wrote:
>> The problem of the enhanced text positioning is fixed with the patch
>> suggested at
>>    http://article.gmane.org/gmane.comp.graphics.gnuplot.devel/9905
>> which still applies for the 2011-01-25 CVS snapshot.
>>
>> benjamin
>>
>
> I woul d be happy to apply this patch if it indeed fixes a problem for
> Windows users.
>
> I must say, however, that I do not understand the logic behind the patch.
> The existing code in win.trm looks correct to me, as it is
> parallel to code that is demonstrably correct in other terminal drivers.
> Maybe I am misunderstanding what is returned by the routine
> GraphGetTextLength().  I would have thought that it would return
> the bounding rectangle for the text in absolute units (~pixels) with
> 0,0 at the lower left and (xmax,ymax) at the upper right.
> (That's what the analagous routine does in libgd).  But in that case
> modifying the code to scale the bounding rectangle by the terminal
> width and height makes no sense.  Does it not have the effect of expanding
> every text fragment to fill the whole screen?
>
> If the coordinates returned by GraphGetTextLength() are non-uniform,
> then I could understand needing to correct the extent along y by the
> aspect ratio:
>    width = cos(WIN_angle) * len;
>    height = sin(WIN_ANGLE) * len;
>    height *= graphwin.xmax/graphwin.ymax;
>
> But that is different from what the patch does.
> Am I reading this wrong?

Thanks for the criticism, I started to re-think from scratch, and
realized that by trying to fix this problem as proposed, I introduced
another bug elswhere (damn!)

I'm sorry for causing all this confusion, I'll try to explain how I
understand the problem here.
First, remember that the windows terminal introduces an additional
intermediate layer between what gnuplot tells the terminal driver and
what the windows graph windows displays, so you can't compare to
non-interactive terminals like the gd terminals. The terminal driver
generates a virtual coordinate system that extends from (0,0) to
(graphwin.xmax, graphwin.ymax).
The graph window, however has a different coordinate system, extending
from (0,0) to (rect.width, rect.height). So you have to translate
between them.
And the terminal's width and height merely define the resolution of
the positioning within the graw window coordinate system.
Your proposal above does not work, because xmax/ymax is not the same
as width/height - there are two different scaling factors for x and y
coordinates.

Now, the old behaviour was like follows:
GraphGetTextLength() determined the extent of the text along the
horizontal axes (i.e. its width) in physical points, and then
translated the text width but only considering the width of the
terminal canvas and the width of graph window (the only-the-width part
is the mistake here) - so it does not return the text extent in
absolute pixels.
When actually displaying the text, the coordinates are again
transformed into real-world screen pixels.
But the ratio of window width to canvas width is not the same as
window height to canvas height (the canvas extent is hardwired and has
no relation to the graph window's actual width&height) - so scaling
both x and y part of coordinates considering only the ratio of window
width to canvas width will yield a wrong placement in y.

The proposed behaviour is:
GraphGetTextLength() returns the width in points (which are
interpreted as pixels).
The coordinate transformation happens afterwards, now (correctly)
separately for x and y axis.
(BTW this transformation is the inverse of the transformation that is
done in drawgraph() in wgraph.c - the graph window's actual drawing
function)

The actual drawing on the graph window is done in drawgraph() in
wgraph.c. And here all coordinates are transformed back to
pixels-on-the-screen, with x -> x*width/xmax, y -> y*height/ymax.
And these ratios need not be the same, that's why the inverse
transformation in WIN_enhanced_flush() must take both into account.

This now is fixed (for me with 2011-01-25 CVS snapshot on WinXP SP3) with

diff --git a/src/win/wgraph.c b/src/win/wgraph.c
--- a/src/win/wgraph.c
+++ b/src/win/wgraph.c
@@ -2681,7 +2681,7 @@
     GetTextExtentPoint(hdc, text, strlen(text), &size);
     SelectObject(hdc, hprevfont);

-    size.cx = MulDiv(size.cx + GetTextCharacterExtra(hdc),
lpgw->xmax, rect.right-rect.left-1);
+    size.cx += GetTextCharacterExtra(hdc);
     /* shige: restore original font */
     GraphChangeFont(lpgw, lpgw->deffontname, lpgw->deffontsize, hdc, rect);
     return size.cx;
diff --git a/term/win.trm b/term/win.trm
--- a/term/win.trm
+++ b/term/win.trm
@@ -850,8 +850,11 @@

 	/* calculate length of string first */
     	len = GraphGetTextLength(&graphwin, enhanced_text, WIN_font,
WIN_fontsize);
-	width = cos(WIN_angle) * len;
-	height = sin(WIN_angle) * len;
+	RECT rect;
+	GetPlotRect(&graphwin, &rect);
+	
+	width = round(cos(WIN_angle) * len * graphwin.xmax /
(rect.right-rect.left-1));
+	height = round(sin(WIN_angle) * len * graphwin.ymax /
(rect.bottom-rect.top-1));

 	if (ENHwin_show && !ENHwin_sizeonly) {
 	    /* display string */

which simply moves the translation from GraphGetTextLength() to
WIN_enhanced_flush and uses correct scaling factors in x and y.

the other two hunks in the original patch caused problems with
coordinate positioning for all other plotted objects (aside enhanced
rotated text with sub/superscript) - so I have to drop them.
Apoplogies again for introducing them in the first place. The problem
is rather complex on second thoughts...

benjamin