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

Re: CVS woes: wxt fails

[<pl...@pi...>]

On 25/11/15 17:36, Karl-Friedrich Ratzsch wrote:
> This is a known quirk, see also the 5.0 release notes and
> https://sourceforge.net/p/gnuplot/bugs/1592/
>
> Try giving
>
>      configure --with-wx-single-threaded
>
> or
>
>      TERMLIBS="-lX11" ./configure
>
> The latter can in some cases be necessary even if the x11 terminal is
> configured.
>
> Best regards,
>
>     Karl
>
> Am 25.11.2015 um 14:48 schrieb pl...@pi...:
>> I still need to tell it where to find wx-config otherwise it builds
>> without wxt
>>
>> ./configure --prefix=/usr/local --without-qt
>> --with-wx=/usr/libexec/compat-wxGTK3-gtk2/
>>
>> Now it seems to fail at the linker stage.
>>
>> /bin/ld: wxterminal/wxt_gui.o: undefined reference to symbol 'XInitThreads'
>> /usr/lib64/libX11.so.6: error adding symbols: DSO missing from command line
>> collect2: error: ld returned 1 exit status
>> make[4]: *** [gnuplot] Error 1
>>
>>
>>

Thanks Karl,

the TERMLIBS idea got it to compile without problems.

TERMLIBS="-lX11" ./configure --prefix=/usr/local --without-qt 
--with-wx=/usr/libexec/compat-wxGTK3-gtk2/

Thanks for sharing your deeper understanding of  automake magic.

It seems like you have come up against this before. Is there something 
that needs changing/fixing here?

regards, Peter.

Re: CVS woes: qt lacks title bar

[<pl...@pi...>]

Hi,

I have just built current CVS and was quickly testing qt. ( built with qt5 )

Terminal type set to 'qt'
gnuplot> plot sin(x*2.0*pi)


It works and resizes cleanly but the window is stuck up against the top 
left corner of the screen and I do not have a title bar on it.

No means to move the window and no close button to get rid of it.

Built on Fedora23 LXDE spin installation.


regards, Peter.

Re: CVS woes: wxt core dump

[<pl...@pi...>]

Hi,

having finally got CVS to build with wxt I did a quick test. All seemed 
fine until I used the spanner button to configure it and selected 
"redraw window while resizing".

I fairly reapidly crashes in a big messy heap. Seems OK without the 
resize option.

Peter.


$ gnuplot

	G N U P L O T
	Version 5.1 patchlevel 0    last modified 2015-11-12

	Copyright (C) 1986-1993, 1998, 2004, 2007-2015
	Thomas Williams, Colin Kelley and many others

	gnuplot home:     http://www.gnuplot.info
	mailing list:     gnu...@li...
	faq, bugs, etc:   type "help FAQ"
	immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to 'wxt'
gnuplot> plot sin(x/2.0/pi)
gnuplot>
(gnuplot:6860): GLib-CRITICAL **: Source ID 3806 was not found when 
attempting to remove it
Segmentation fault (core dumped)

Re: CVS woes: wxt fails

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

On 11/25/2015 07:48 AM, pl...@pi... wrote:
> On 25/11/15 09:26, Daniel J Sebald wrote:
>> On 11/25/2015 02:39 AM, pl...@pi... wrote:
>>> Hi,
>>>
>>> Building current CVS gnuplot on Fedora 23 x68_64, I found I had to
>>> explicitly give the WXDIR to get it to configure wxt terminal:
>>>
>>> ./configure --prefix=/usr/local --with-qt --with-wx=/usr/libexec/wxGTK3
>>>
>>> It still fails half way throught the wxt stuff:
>>>
>>> <code>
>>>
>>> wxterminal/wxt_gui.cpp:4197:1: warning: ‘virtual void
>>> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated: use
>>> SetInitialSize() instead. [-Wdeprecated-declarations]
>>> }
>>> ^
>>> In file included from /usr/include/wx-3.0/wx/wx.h:38:0,
>>> from wxterminal/wxt_gui.h:77,
>>> from wxterminal/wxt_gui.cpp:97:
>>> /usr/include/wx-3.0/wx/window.h:1872:13: note: declared here
>>> inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
>>> ^
>>> Makefile:926: recipe for target 'wxterminal/wxt_gui.o' failed
>>> make[4]: *** [wxterminal/wxt_gui.o] Error 1
>>>
>>> </code>
>>>
>>>
>>> There is a raft ( hundreds ) of such deprecation warnings that make it
>>> difficult to find the original error.
>>>
>>> Is there a way to turn off these warnings so that I can see what is
>>> going wrong?
>>
>> Sometimes the warnings and errors go to separate streams, e.g., stdout
>> vs. stderr. Try redirecting the output of the compilation to file and
>> see if there is anything left behind that looks like an error.
>>
>> Dan
>>
>
> Ah, good idea Dan.
>
> make 2>stderr.log
>
> redirecting stderr to a file and searching for "error" found this. It
> seems it is doing an ungodly mix of gtk2.0 and gtk3.0
>
> ============
>
> In file included from /usr/include/gtk-2.0/gdk/gdkscreen.h:32:0,
> from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31,
> from /usr/include/gtk-2.0/gdk/gdk.h:32,
> from wxterminal/wxt_gui.h:191,
> from wxterminal/wxt_gui.cpp:97:
> /usr/include/gtk-2.0/gdk/gdktypes.h:114:39: error: conflicting
> declaration ‘typ$
> typedef struct _GdkDrawable GdkWindow;
> ^
> In file included from /usr/include/wx-3.0/wx/wxprec.h:12:0,
> from wxterminal/wxt_gui.h:75,
> from wxterminal/wxt_gui.cpp:97:
> /usr/include/wx-3.0/wx/defs.h:3412:31: note: previous declaration as
> ‘typedef s$
> typedef struct _GdkWindow GdkWindow;
> ^
> =============
>
> This is probably since I had to provide it with a WXDIR since it could
> not find it on its own.
>
> However the only wx-config on the system is that which I gave it :
> /usr/libexec/wxGTK3/wx-config
>
> If I don't give it a WXDIR in configure it configures to build without wxt.
>
> Fedora seems to offer some kind of gtk3-gtk2 compatability lib ,
> installing this got a bit further:
>
> Installing:
> compat-wxBase3-gtk2 x86_64 3.0.2-5.1.fc23 fedora 1.1 M
> compat-wxGTK3-gtk2 x86_64 3.0.2-5.1.fc23 fedora 5.4 M
> compat-wxGTK3-gtk2-devel x86_64 3.0.2-5.1.fc23 fedora 1.3 M
> compat-wxGTK3-gtk2-gl x86_64 3.0.2-5.1.fc23 fedora 35 k
> compat-wxGTK3-gtk2-media x86_64 3.0.2-5.1.fc23 fedora 56 k
>
> I still need to tell it where to find wx-config otherwise it builds
> without wxt
>
> ./configure --prefix=/usr/local --without-qt
> --with-wx=/usr/libexec/compat-wxGTK3-gtk2/
>
> Now it seems to fail at the linker stage.
>
> /bin/ld: wxterminal/wxt_gui.o: undefined reference to symbol 'XInitThreads'
> /usr/lib64/libX11.so.6: error adding symbols: DSO missing from command line
> collect2: error: ld returned 1 exit status
> make[4]: *** [gnuplot] Error 1
>
>
> I'm a bit included just to give up on wxt and use qt, but from a
> development point of view I suppose this should work.
>
> I don't think I'm trying to do anything particularly odd-ball here. Any
> suggestions?

No real good ideas here Peter, sorry.  Only that maybe you could look at 
the configuration log and search for the first location where gtk2/3 
appears and perhaps try to modify things through a flag or removing some 
developer library that would cause gnuplot to not use gtk3.

Also, qt is good, but slower on some systems and faster on others.  I 
like both qt and wxt, but I've found quite a few odd bugs in each that I 
haven't had time to investigate.

Dan

Re: CVS woes: pango

[<pl...@pi...>]

Hi,

I have a sufficiently new version of pango installed :

dnf install pango pango-devel
...

Package pango-1.38.1-1.fc23.x86_64 is already installed, skipping.
Package pango-devel-1.38.1-1.fc23.x86_64 is already installed, skipping.

Yet configure is not finding it .

checking for CAIROPANGO... yes
checking for PANGO_1_10_2... no

I don't think that this has any bearing of the other issues but it does 
seem to be another thing that is not working properly on current fedora 
23 ( x86_64 LXDE spin ) .

Peter.

Re: CVS woes: wxt fails

[<pl...@pi...>]

On 25/11/15 09:26, Daniel J Sebald wrote:
> On 11/25/2015 02:39 AM, pl...@pi... wrote:
>> Hi,
>>
>> Building current CVS gnuplot on Fedora 23 x68_64, I found I had to
>> explicitly give the WXDIR to get it to configure wxt terminal:
>>
>> ./configure --prefix=/usr/local --with-qt --with-wx=/usr/libexec/wxGTK3
>>
>> It still fails half way throught the wxt stuff:
>>
>> <code>
>>
>> wxterminal/wxt_gui.cpp:4197:1: warning: ‘virtual void
>> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated: use
>> SetInitialSize() instead. [-Wdeprecated-declarations]
>>    }
>>    ^
>> In file included from /usr/include/wx-3.0/wx/wx.h:38:0,
>>                    from wxterminal/wxt_gui.h:77,
>>                    from wxterminal/wxt_gui.cpp:97:
>> /usr/include/wx-3.0/wx/window.h:1872:13: note: declared here
>>    inline void wxWindowBase::SetInitialBestSize(const wxSize&  size)
>>                ^
>> Makefile:926: recipe for target 'wxterminal/wxt_gui.o' failed
>> make[4]: *** [wxterminal/wxt_gui.o] Error 1
>>
>> </code>
>>
>>
>> There is a raft ( hundreds ) of such deprecation warnings that make it
>> difficult to find the original error.
>>
>> Is there a way to turn off these warnings so that I can see what is
>> going wrong?
>
> Sometimes the warnings and errors go to separate streams, e.g., stdout
> vs. stderr.  Try redirecting the output of the compilation to file and
> see if there is anything left behind that looks like an error.
>
> Dan
>

Ah, good idea Dan.

make 2>stderr.log

redirecting stderr to a file and searching for "error" found this. It 
seems it is doing an ungodly mix of gtk2.0 and gtk3.0

============

In file included from /usr/include/gtk-2.0/gdk/gdkscreen.h:32:0,
                  from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31,
                  from /usr/include/gtk-2.0/gdk/gdk.h:32,
                  from wxterminal/wxt_gui.h:191,
                  from wxterminal/wxt_gui.cpp:97:
/usr/include/gtk-2.0/gdk/gdktypes.h:114:39: error: conflicting 
declaration ‘typ$
  typedef struct _GdkDrawable           GdkWindow;
                                        ^
In file included from /usr/include/wx-3.0/wx/wxprec.h:12:0,
                  from wxterminal/wxt_gui.h:75,
                  from wxterminal/wxt_gui.cpp:97:
/usr/include/wx-3.0/wx/defs.h:3412:31: note: previous declaration as 
‘typedef s$
      typedef struct _GdkWindow GdkWindow;
                                ^
=============

This is probably since I had to provide it with a WXDIR since it could 
not find it on its own.

However the only wx-config on the system is that which I gave it :
/usr/libexec/wxGTK3/wx-config

If I don't give it a WXDIR in configure it configures to build without wxt.

Fedora seems to offer some kind of gtk3-gtk2 compatability lib , 
installing this got a bit further:

Installing:
  compat-wxBase3-gtk2          x86_64     3.0.2-5.1.fc23        fedora 
    1.1 M
  compat-wxGTK3-gtk2           x86_64     3.0.2-5.1.fc23        fedora 
    5.4 M
  compat-wxGTK3-gtk2-devel     x86_64     3.0.2-5.1.fc23        fedora 
    1.3 M
  compat-wxGTK3-gtk2-gl        x86_64     3.0.2-5.1.fc23        fedora 
     35 k
  compat-wxGTK3-gtk2-media     x86_64     3.0.2-5.1.fc23        fedora 
     56 k

I still need to tell it where to find wx-config otherwise it builds 
without wxt

./configure --prefix=/usr/local --without-qt 
--with-wx=/usr/libexec/compat-wxGTK3-gtk2/

Now it seems to fail at the linker stage.

/bin/ld: wxterminal/wxt_gui.o: undefined reference to symbol 'XInitThreads'
/usr/lib64/libX11.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[4]: *** [gnuplot] Error 1


I'm a bit included just to give up on wxt and use qt, but from a 
development point of view I suppose this should work.

I don't think I'm trying to do anything particularly odd-ball here. Any 
suggestions?

Thanks,  Peter.

Re: CVS woes: deps

[<pl...@pi...>]

On 25/11/15 10:07, Ethan A Merritt wrote:
>
>
>
> On Wed, 25 Nov 2015, pl...@pi... wrote:
>
>> Hi,
>>
>>
>> >>
>> The jive is now sorted out; CVS is accessible again.
>> Allin Cottrell
>> >>
>>
>> Thanks for the heads up, good to see this back in action.
>>
>> I am trying to build on a new x86_64 Fedora installation. After a bit of
>> poking and encouragement it did get through ./configure --with-qt but
>> with a rather odd warming:
>>
>> configure: WARNING: The Qt terminal will use Qt5.
>>
>> Why is that a warming, is it expected to give problems?
>>
>> After compiling a fair amount of qt related sfuff, it finally dropped
>> out with this:
>>
>>
>> make
>>
>> ....
>>
>> /usr/lib64/qt5/bin/lrelease qtterminal/po/qtgnuplot_fr.ts -qm
>> qtgnuplot_fr.qm
>> make[4]: /usr/lib64/qt5/bin/lrelease: Command not found
>> Makefile:1282: recipe for target 'qtgnuplot_fr.qm' failed
>>
>>
>>
>> Is the a missing -devel package that the automake tools failed to test
>> for, or what? Any suggestions ?
>
> qt5 lrelease is in package qttools5
>
> The error should not be fatal, as the only thing not built is the
> french and japanese translations of the error messages. Possibly
> it will also want the i18n locale support for French and Japanese.
>
>     Ethan
>
>>
>> TIA, Peter.
>>


Thanks Ethan,

I added qt5-qttools and qt5-qttools-devel packages ( which pulled in a 
total of 10 new pkgs ).

after make clean and config it built with qt.

This seems to raise a question about the automake sniffing:
1. Why does it not detect the need for these packages during config

Since I have fr language support configured in by some GUI tool, it may 
be correct that failed.

Regards, Peter.

Re: CVS woes: deps

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

On Wed, 25 Nov 2015, pl...@pi... wrote:

> Hi,
>
>
> >>
> The jive is now sorted out; CVS is accessible again.
> Allin Cottrell
> >>
>
> Thanks for the heads up, good to see this back in action.
>
> I am trying to build on a new x86_64 Fedora installation. After a bit of
> poking and encouragement it did get through ./configure --with-qt but
> with a rather odd warming:
>
> configure: WARNING: The Qt terminal will use Qt5.
>
> Why is that a warming, is it expected to give problems?
>
> After compiling a fair amount of qt related sfuff, it finally dropped
> out with this:
>
>
> make
>
> ....
>
> /usr/lib64/qt5/bin/lrelease qtterminal/po/qtgnuplot_fr.ts -qm
> qtgnuplot_fr.qm
> make[4]: /usr/lib64/qt5/bin/lrelease: Command not found
> Makefile:1282: recipe for target 'qtgnuplot_fr.qm' failed
>
>
>
> Is the a missing -devel package that the automake tools failed to test
> for, or what? Any suggestions ?

qt5 lrelease is in package qttools5

The error should not be fatal, as the only thing not built is the
french and japanese translations of the error messages. Possibly
it will also want the i18n locale support for French and Japanese.

    Ethan

>
> TIA, Peter.
>
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: CVS woes: wxt fails

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

On 11/25/2015 02:39 AM, pl...@pi... wrote:
> Hi,
>
> Building current CVS gnuplot on Fedora 23 x68_64, I found I had to
> explicitly give the WXDIR to get it to configure wxt terminal:
>
> ./configure --prefix=/usr/local --with-qt --with-wx=/usr/libexec/wxGTK3
>
> It still fails half way throught the wxt stuff:
>
> <code>
>
> wxterminal/wxt_gui.cpp:4197:1: warning: ‘virtual void
> wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated: use
> SetInitialSize() instead. [-Wdeprecated-declarations]
>    }
>    ^
> In file included from /usr/include/wx-3.0/wx/wx.h:38:0,
>                    from wxterminal/wxt_gui.h:77,
>                    from wxterminal/wxt_gui.cpp:97:
> /usr/include/wx-3.0/wx/window.h:1872:13: note: declared here
>    inline void wxWindowBase::SetInitialBestSize(const wxSize&  size)
>                ^
> Makefile:926: recipe for target 'wxterminal/wxt_gui.o' failed
> make[4]: *** [wxterminal/wxt_gui.o] Error 1
>
> </code>
>
>
> There is a raft ( hundreds ) of such deprecation warnings that make it
> difficult to find the original error.
>
> Is there a way to turn off these warnings so that I can see what is
> going wrong?

Sometimes the warnings and errors go to separate streams, e.g., stdout 
vs. stderr.  Try redirecting the output of the compilation to file and 
see if there is anything left behind that looks like an error.

Dan

Re: CVS woes: wxt fails

[<pl...@pi...>]

Hi,

Building current CVS gnuplot on Fedora 23 x68_64, I found I had to 
explicitly give the WXDIR to get it to configure wxt terminal:

./configure --prefix=/usr/local --with-qt --with-wx=/usr/libexec/wxGTK3

It still fails half way throught the wxt stuff:

<code>

wxterminal/wxt_gui.cpp:4197:1: warning: ‘virtual void 
wxWindowBase::SetInitialBestSize(const wxSize&)’ is deprecated: use 
SetInitialSize() instead. [-Wdeprecated-declarations]
  }
  ^
In file included from /usr/include/wx-3.0/wx/wx.h:38:0,
                  from wxterminal/wxt_gui.h:77,
                  from wxterminal/wxt_gui.cpp:97:
/usr/include/wx-3.0/wx/window.h:1872:13: note: declared here
  inline void wxWindowBase::SetInitialBestSize(const wxSize& size)
              ^
Makefile:926: recipe for target 'wxterminal/wxt_gui.o' failed
make[4]: *** [wxterminal/wxt_gui.o] Error 1

</code>


There is a raft ( hundreds ) of such deprecation warnings that make it 
difficult to find the original error.

Is there a way to turn off these warnings so that I can see what is 
going wrong?

Thanks, Peter.

CVS woes: deps

[<pl...@pi...>]

Hi,


 >>
The jive is now sorted out; CVS is accessible again.
Allin Cottrell
 >>

Thanks for the heads up, good to see this back in action.

I am trying to build on a new x86_64 Fedora installation. After a bit of 
poking and encouragement it did get through ./configure --with-qt but 
with a rather odd warming:

configure: WARNING: The Qt terminal will use Qt5.

Why is that a warming, is it expected to give problems?

After compiling a fair amount of qt related sfuff, it finally dropped 
out with this:


make

....

/usr/lib64/qt5/bin/lrelease qtterminal/po/qtgnuplot_fr.ts -qm 
qtgnuplot_fr.qm
make[4]: /usr/lib64/qt5/bin/lrelease: Command not found
Makefile:1282: recipe for target 'qtgnuplot_fr.qm' failed



Is the a missing -devel package that the automake tools failed to test 
for, or what? Any suggestions ?

TIA, Peter.

Re: CVS woes

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

On 24 November 2015 at 23:15, Eric S. Raymond <es...@th...> wrote:
> Daniel J Sebald <dan...@ie...>:
>> >But the real show-stopper is that, if this project is anything like
>> >typical, a single ChangeLog entry often actually summarizes work from
>> >*multiple* commits.  It may not be clear which ones, since one of
>> >the bedevilling quirks of older CVSes was that commit timestamps were
>> >take *client-side* and tended to be flaky.
>>
>> Could the documentation be integrated into the git commit history in an
>> approximate way?  Say, associate all the comments for a particular day with
>> the last CVS entry for that date?  But it would have to be that the full
>> Changelog header and date appears in the comment.  So for example, one
>> commit message might have three Changelog entries listed.  It would only be
>> an approximate alignment of commit messages and the changelog, but anyone
>> who would go through the history to manually decipher and reconstruct things
>> would be faced with an approximate association with what is in CVS anyway.
>
> Yes, something like that could be attempted.  The reason it's never been done
> is that the implementation would be a swamp of complexity, and the results of
> very dubious quality.
>
> The easiest way I could imagine to do it (all the alternatives would require
> a larger volume of custom code) would be to:
>
> (1) Write a Python program that could convert the entire sequence of ChangeLog
> into a shelf object keyed by date, with the values being a pair consisting of
> a name and the comment text.
>
> (2) Write a custom plugin for reposurgeon that would load the shelf object
> produced by the previous program and walk through the commit sequence looking
> for where a copy of each item should be inserted.
>
> The heart of the code would be a predicate that takes as arguments the
> following:
>
>    * the git commit date
>    * the git commit committer ID
>    * a ChangeLog entry date
>    * a ChangeLog author ID
>
> and returns yes or no according as the entry should or should not be appended
> to the comment of the specified commit.
>
> Good luck writing a predicate that produces consistently reasonable results.
> Here are some of the complications:
>
>    * ChangeLog entry dates only have resolution to a day
>
>    * The commit dates are unreliable both due to clock skew and unreported
>      time-zone offsets (remember CVS commit stamps are taken client side)
>
>    * Git committer IDs may not match ChangeLog committer IDs even if they
>      were the same persion. There are just too many ways for email addresses
>      and personal names to have variations that are transparent to a human
>      but not to a string-matching algorithm.
>
> As an example of the latter, I've often run into situations where a committer
> used a correct spelling of his name (featuring, for example, a Latin-1 umlaut)
> one context and a plain-ASCII approximtion in the other.
>
> My prediction is that the attempt will not end well.

Honestly I don't see the reason to attempt this. The Gnuplot's
ChangeLog seems like a manually written document to me, usually citing
the real authors of patches, while the CVS log would mention the
committer.

Unless someone goes through the list semi-manually, I don't see a way
to make this work reliably and I also don't see any reason to do so
now as a prerequisite for the conversion. Anyone can check the old
ChangeLog and then find the relevant release in the git log if needed.

Mojca

Re: CVS woes

[Eric S. R. <es...@th...>]

Daniel J Sebald <dan...@ie...>:
> >But the real show-stopper is that, if this project is anything like
> >typical, a single ChangeLog entry often actually summarizes work from
> >*multiple* commits.  It may not be clear which ones, since one of
> >the bedevilling quirks of older CVSes was that commit timestamps were
> >take *client-side* and tended to be flaky.
> 
> Could the documentation be integrated into the git commit history in an
> approximate way?  Say, associate all the comments for a particular day with
> the last CVS entry for that date?  But it would have to be that the full
> Changelog header and date appears in the comment.  So for example, one
> commit message might have three Changelog entries listed.  It would only be
> an approximate alignment of commit messages and the changelog, but anyone
> who would go through the history to manually decipher and reconstruct things
> would be faced with an approximate association with what is in CVS anyway.

Yes, something like that could be attempted.  The reason it's never been done
is that the implementation would be a swamp of complexity, and the results of
very dubious quality.  

The easiest way I could imagine to do it (all the alternatives would require
a larger volume of custom code) would be to:

(1) Write a Python program that could convert the entire sequence of ChangeLog
into a shelf object keyed by date, with the values being a pair consisting of
a name and the comment text.

(2) Write a custom plugin for reposurgeon that would load the shelf object
produced by the previous program and walk through the commit sequence looking
for where a copy of each item should be inserted.

The heart of the code would be a predicate that takes as arguments the
following:

   * the git commit date
   * the git commit committer ID
   * a ChangeLog entry date
   * a ChangeLog author ID

and returns yes or no according as the entry should or should not be appended
to the comment of the specified commit.

Good luck writing a predicate that produces consistently reasonable results.
Here are some of the complications:

   * ChangeLog entry dates only have resolution to a day

   * The commit dates are unreliable both due to clock skew and unreported
     time-zone offsets (remember CVS commit stamps are taken client side)

   * Git committer IDs may not match ChangeLog committer IDs even if they
     were the same persion. There are just too many ways for email addresses
     and personal names to have variations that are transparent to a human
     but not to a string-matching algorithm.

As an example of the latter, I've often run into situations where a committer
used a correct spelling of his name (featuring, for example, a Latin-1 umlaut)
one context and a plain-ASCII approximtion in the other.

My prediction is that the attempt will not end well.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: CVS woes

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

On Tue, 24 Nov 2015, pl...@pi... wrote:

> Thanks for all the attention this is getting. When I hit this about 5
> days ago I assumed it was just temporary glitch. It's starting to look
> like it may have been an intentional 'feature' to push everyone still
> using CVS to stop doing so.

No, surely not intentional. It's just that CVS is low priority (and 
they certainly would prefer that projects not use CVS any more).

> Wasn't there some discussion and a hosting offer from some faculty to
> host the archive in a more controlled environment?
>
> BTW is there a recent tarball I can grab from somewhere until this jive
> is sorted out?

The jive is now sorted out; CVS is accessible again.

Allin Cottrell

Re: CVS woes

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

On 24 November 2015 at 21:17,  <pl...@pi...> wrote:
> Thanks for all the attention this is getting. When I hit this about 5
> days ago I assumed it was just temporary glitch. It's starting to look
> like it may have been an intentional 'feature' to push everyone still
> using CVS to stop doing so.
>
> Wasn't there some discussion and a hosting offer from some faculty to
> host the archive in a more controlled environment?

What kind of archive do you have in mind?

(If the developers would switch to git, every user would have the
complete archive at hand. :)

> BTW is there a recent tarball I can grab from somewhere until this jive
> is sorted out?

You can get an unreliable clone at
    https://github.com/gnuplot/gnuplot
and I have a complete backup of the CVS repository should anyone need
it (but it's about 171 MB, so I'm unable to send it over email).

But it would be sooooo great if the developers would switch to any other VCS.

Mojca

Re: CVS woes

[<pl...@pi...>]

Thanks for all the attention this is getting. When I hit this about 5 
days ago I assumed it was just temporary glitch. It's starting to look 
like it may have been an intentional 'feature' to push everyone still 
using CVS to stop doing so.

Wasn't there some discussion and a hosting offer from some faculty to 
host the archive in a more controlled environment?

BTW is there a recent tarball I can grab from somewhere until this jive 
is sorted out?

I foolishly deleted by old copy in order to get a clean download, under 
the illusion that sourceforge could be relied upon. We get wiser every 
day...


Thanks, Peter.

Re: CVS woes

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

On 11/24/2015 01:59 PM, Daniel J Sebald wrote:
> On 11/23/2015 08:08 PM, Eric S. Raymond wrote:

[snip]

>> What everyone ends up doing when they convert is treating ChangeLogs as
>> historical documents related to but not merged with the commit history.
>
> I suppose that wouldn't be too bad, but I don't like the idea of having
> a commit message history that is void of any context.  The nice thing is
> having a viewer that displays the diffs between versions along with an
> overall description of changes.

I forgot to add, saving the ChangeLogs as documents in addition to 
distributed within the git history would be fine too.

Dan

Re: CVS woes

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

On 11/23/2015 08:08 PM, Eric S. Raymond wrote:
> Allin Cottrell<cot...@wf...>:
>> On Mon, 23 Nov 2015, Daniel J Sebald wrote:
>>
>>> On 11/23/2015 03:46 PM, Allin Cottrell wrote:
>> [...]
>>>> Any plans for gnuplot to migrate to git? That seems to be _much_
>>>> better supported at sourceforge.
>> [...]
>>>
>>> One of the requirements is that the git log output would have to
>>> be converted to ChangeLog format using some type of script for
>>> development moving forward. And it would be good for the existing
>>> ChangeLog to serve as the commit messages for the initial git
>>> repository.
>>
>> This may not be exactly what you're talking about, but currently
>> available software will translate the entire history of a CVS
>> repository into the git equivalent -- making for a seamless
>> transition -- so I don't suppose that handling ChangeLogs would be a
>> problem.
>
> It depends on what the maintainers actually want.  I speak as an
> expert at this kind of conversion; among other things, I moved
> groff and NUT from CVS to git.
>
> Unfortunately, the combination of ChangeLogs and CVS comments is actually very
> difficult to integrate into a single comment history.
>
> The first step would be mapping the per-file CVS commits to git-style
> multi-file commits.  I maintain the best-in-class tools for this -
> cvs-fast-export and reposurgeon - and unless your CVS repo has
> particularly odd malformations it won't be difficult.
>
> I just ran a test conversion of your SourceForge CVS; took about 5
> minutes to do it and correctness-check the result at every tag. There's
> some mild hinkiness with an import branch that can probably be
> discarded, and three file histories under docs/ps that should probably
> be snipped off, but for a conversion of a CVS repo this old that is
> barely any cruft at all, and reposurgeon could fix it right up.
>
> It also wouldn't be any real problem, mechanically speaking, to edit
> individual change comments to include ChangeLog entries.  The problem is
> in figuring what commit each entry should be inserted into.  Their dates
> are only recorded to the day, so it isn't usually going to be possible
> to mechanically associate a ChangeLog entry with a single commit.  Even
> the disambiguation of being able to match against committer names turns
> out not to help much.
>
> But the real show-stopper is that, if this project is anything like
> typical, a single ChangeLog entry often actually summarizes work from
> *multiple* commits.  It may not be clear which ones, since one of
> the bedevilling quirks of older CVSes was that commit timestamps were
> take *client-side* and tended to be flaky.

Could the documentation be integrated into the git commit history in an 
approximate way?  Say, associate all the comments for a particular day 
with the last CVS entry for that date?  But it would have to be that the 
full Changelog header and date appears in the comment.  So for example, 
one commit message might have three Changelog entries listed.  It would 
only be an approximate alignment of commit messages and the changelog, 
but anyone who would go through the history to manually decipher and 
reconstruct things would be faced with an approximate association with 
what is in CVS anyway.


> You'd have to have some human slog through all ChangeLog entries by
> eyeball, applying contextual knowledge and editing ChangeLog entries
> into the commit history by hand.  I know of no project that has ever
> actually done this.

I doubt anyone is willing to volunteer to fix the whole history, but 
having an approximate alignment of messages would be convenient enough, 
I would think.


> What everyone ends up doing when they convert is treating ChangeLogs as
> historical documents related to but not merged with the commit history.

I suppose that wouldn't be too bad, but I don't like the idea of having 
a commit message history that is void of any context.  The nice thing is 
having a viewer that displays the diffs between versions along with an 
overall description of changes.


> Now, as for generating ChangeLog entries after conversion.  It can be
> done, but it's like mounting an ornamental buggy-whip holder on the
> dashboard of a car - quite pointless in practice.  When you have a
> proper VCS with multi-file commits, those should *be* your Changelog.
> Enough said.

The git log is pretty close to Changelog format already.  I would think 
some tweaking is all that is needed to make the output very close.  Then 
if the original Changelog comments are in the git commit messages, a 
"git-to-changelog" conversion would be close to the original changelog 
plus new commits.

For those who haven't used git, or mercurial, I think you'd find it a 
very helpful tool beyond just the code maintenance portion of it.  I 
typically have something like TortoiseHg or gitg open so that it shows 
me what all the changes are for my local version of code which just 
helps organize things in one's mind, and one can easily pick and choose 
the code hunks that should be included in a commit/changeset, etc. 
Something I find very clumsy with CVS is generating diffs to post on the 
bug tracker or whatnot.  But with git/hg this sort of operation is easy. 
  Basically, programming is just a much more fluent thing with a good 
version control system.

Dan

Re: CVS woes

[Eric S. R. <es...@th...>]

Allin Cottrell <cot...@wf...>:
> On Mon, 23 Nov 2015, Daniel J Sebald wrote:
> 
> > On 11/23/2015 03:46 PM, Allin Cottrell wrote:
> [...]
> >> Any plans for gnuplot to migrate to git? That seems to be _much_
> >> better supported at sourceforge.
> [...]
> >
> > One of the requirements is that the git log output would have to 
> > be converted to ChangeLog format using some type of script for 
> > development moving forward. And it would be good for the existing 
> > ChangeLog to serve as the commit messages for the initial git 
> > repository.
> 
> This may not be exactly what you're talking about, but currently 
> available software will translate the entire history of a CVS 
> repository into the git equivalent -- making for a seamless 
> transition -- so I don't suppose that handling ChangeLogs would be a 
> problem.

It depends on what the maintainers actually want.  I speak as an
expert at this kind of conversion; among other things, I moved
groff and NUT from CVS to git.

Unfortunately, the combination of ChangeLogs and CVS comments is actually very
difficult to integrate into a single comment history.

The first step would be mapping the per-file CVS commits to git-style
multi-file commits.  I maintain the best-in-class tools for this -
cvs-fast-export and reposurgeon - and unless your CVS repo has
particularly odd malformations it won't be difficult.

I just ran a test conversion of your SourceForge CVS; took about 5
minutes to do it and correctness-check the result at every tag. There's
some mild hinkiness with an import branch that can probably be
discarded, and three file histories under docs/ps that should probably
be snipped off, but for a conversion of a CVS repo this old that is
barely any cruft at all, and reposurgeon could fix it right up.

It also wouldn't be any real problem, mechanically speaking, to edit
individual change comments to include ChangeLog entries.  The problem is
in figuring what commit each entry should be inserted into.  Their dates
are only recorded to the day, so it isn't usually going to be possible
to mechanically associate a ChangeLog entry with a single commit.  Even
the disambiguation of being able to match against committer names turns
out not to help much.

But the real show-stopper is that, if this project is anything like
typical, a single ChangeLog entry often actually summarizes work from
*multiple* commits.  It may not be clear which ones, since one of
the bedevilling quirks of older CVSes was that commit timestamps were
take *client-side* and tended to be flaky.

You'd have to have some human slog through all ChangeLog entries by
eyeball, applying contextual knowledge and editing ChangeLog entries
into the commit history by hand.  I know of no project that has ever
actually done this.

What everyone ends up doing when they convert is treating ChangeLogs as
historical documents related to but not merged with the commit history.

Now, as for generating ChangeLog entries after conversion.  It can be
done, but it's like mounting an ornamental buggy-whip holder on the
dashboard of a car - quite pointless in practice.  When you have a
proper VCS with multi-file commits, those should *be* your Changelog.
Enough said.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: CVS woes

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

On Mon, 23 Nov 2015, Daniel J Sebald wrote:

> On 11/23/2015 03:46 PM, Allin Cottrell wrote:
[...]
>> Any plans for gnuplot to migrate to git? That seems to be _much_
>> better supported at sourceforge.
[...]
>
> One of the requirements is that the git log output would have to 
> be converted to ChangeLog format using some type of script for 
> development moving forward. And it would be good for the existing 
> ChangeLog to serve as the commit messages for the initial git 
> repository.

This may not be exactly what you're talking about, but currently 
available software will translate the entire history of a CVS 
repository into the git equivalent -- making for a seamless 
transition -- so I don't suppose that handling ChangeLogs would be a 
problem.

Allin Cottrell

Re: CVS woes

[Eric S. R. <es...@th...>]

Allin Cottrell <cot...@wf...>:
> Any plans for gnuplot to migrate to git? That seems to be _much_
> better supported at sourceforge. I recently converted gretl 
> (econometrics software on sourceforge) from CVS to git and it has 
> been trouble-free since. If there's interest I can send my recipe 
> for the transition. (There are several "how-to"s out there, but 
> they're not all up to date.)

I still lurk on this list because I offered to do a git conversion a
couple years back.  I'm a former GNUPlot contributor and now maintain
cvs-fast-export; I'm the author of one of those how-tos.

The maintainers weren't interested, last time.  We'll see if anything
has changed.  It should; in 2015 still using CVS has gone beyond quaint
and retro into embarrassing, do-you-never-want-to-have-new-contributors
territory.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: CVS woes

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

On 11/23/2015 03:46 PM, Allin Cottrell wrote:
> Following up on Stefan Husmann's question the other day: There's
> still no access to gnuplot CSV on sourceforge ("waiting for
> anoncvs_gnuplot's lock...").
>
> This is not specific to gnuplot: support tickets going back to
> 2015-11-11 complain of CVS hanging waiting for a lock, for several
> projects. I added one for gnuplot 3 days ago. Apparently none of
> these tickets has even been read yet, though some more recent
> submissions on other topics are already in the "pending" stack. It
> seems that CVS comes at the bottom of the list for attention.
>
> Any plans for gnuplot to migrate to git? That seems to be _much_
> better supported at sourceforge. I recently converted gretl
> (econometrics software on sourceforge) from CVS to git and it has
> been trouble-free since. If there's interest I can send my recipe
> for the transition. (There are several "how-to"s out there, but
> they're not all up to date.)

One of the requirements is that the git log output would have to be 
converted to ChangeLog format using some type of script for development 
moving forward.  And it would be good for the existing ChangeLog to 
serve as the commit messages for the initial git repository.

Dan

mp terminal

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

It seems to me that the mp terminal misses a trick: unlike other 
TeX-related terminals such as cairolatex and tikz, it doesn't use a 
proper TeX minux sign in tic labels for negative numbers.

I'm attaching a little patch. It's conditional on one of TeX options 
being selected (as opposed to "notex") and it works on the heuristic 
that if text begins with '-' followed by a digit then a minus sign 
is wanted. There may be a better way of achieving the same effect 
but it works OK in my trials.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

CVS woes

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

Following up on Stefan Husmann's question the other day: There's 
still no access to gnuplot CSV on sourceforge ("waiting for 
anoncvs_gnuplot's lock...").

This is not specific to gnuplot: support tickets going back to 
2015-11-11 complain of CVS hanging waiting for a lock, for several 
projects. I added one for gnuplot 3 days ago. Apparently none of 
these tickets has even been read yet, though some more recent 
submissions on other topics are already in the "pending" stack. It 
seems that CVS comes at the bottom of the list for attention.

Any plans for gnuplot to migrate to git? That seems to be _much_
better supported at sourceforge. I recently converted gretl 
(econometrics software on sourceforge) from CVS to git and it has 
been trouble-free since. If there's interest I can send my recipe 
for the transition. (There are several "how-to"s out there, but 
they're not all up to date.)

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: CVS repo unaccessible

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

On Fri, 20 Nov 2015, Stefan Husmann wrote:

> is it just me? I cannot access the cvs repo of gnuplot.
>
> cvs update: [18:37:12] waiting for anoncvs_gnuplot's lock in 
> /cvsroot/gnuplot/gnuplot

No, not just you; I submitted an SF support ticket earlier today.

Allin Cottrell