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

Re: speed of qt terminal

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

> In other places Daniel state
> ***************************************************************************************
> For example, qt terminal uses QPixmap 
> 
> http://doc.qt.io/qt-5/qpixmap.html
> 
> which is a feature of Qt to handle display of images.  However, this is 
> at a very high level in which image elements are treated individually, 
> not as a whole image.  Consequently, the user will find that the Qt 
> terminal can be rather slow for large data sets.  x11 is very low level, 
> so is much faster.  Yet, wxt is fast as well.
> ***************************************************************************************
> 


Daniel. 
Can you show me a short script at which qt terminal is rather slow?

I would like to execute it on windows and ubuntu PC.

Tatsuro

Re: speed of qt terminal

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

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

> From: sfeam 
> To: gnuplot-betaTatsuro MATSUOKA 
> Cc: 
> Date: 2015/6/27, Sat 00:25
> Subject: Re: speed of qt terminal
> 
> On Friday, 26 June 2015 04:56:26 PM Tatsuro MATSUOKA wrote:
>>  In octave-maintainers ML, the tread "gnuplot graphics toolkit 
> bugs" is open.
>> 
> http://octave.1599824.n4.nabble.com/gnuplot-graphics-toolkit-bugs-td4671157.html
>> 
>> 
>>  In the discussion there is a statement.(by Daniel J Sebald)
>> 
>> 
> ***************************************************************************************
>>  >    It is now the fastest and most full-featured interactive terminal 
> option. (for qt) 
>> 
>>  except the speed.  Perhaps there is some hardware in which Qt can use, 
>>  say, OpenGL directly, but on my system that isn't the case.  Qt 
> terminal 
>>  is drastically slower. 
>> 
> ***************************************************************************************
>> 
>> 
>>  I have built windows version of gnuplot 5.0 and 5.1 with qt terminal.
>>  For my PC "all.dem" speed of windows, wxt, qt terminals, the qt 
> terminal is fastest.
>> 
>>  Qt development toolkits (Qt 5.3) for gnuplot for windows build are prepared 
> from source
>>  with configure option "-no-opengl".
>> 
>>  To my understanding, gnuplot does not use opengl. Am I right?
> 
> The Qt libraries can use opengl if it is available at run time.
> For some versions of Qt this can be controlled using the environmental
> variable QT_GRAPHICSSYSTEM. I think the default is "native" rather 
> than
> "opengl", which tells the library to use whatever output layer is
> expected to be fastest.
> 
>     Ethan
> 
Thank you for the information. 

Tatsuro

Re: speed of qt terminal

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

On Friday, 26 June 2015 04:56:26 PM Tatsuro MATSUOKA wrote:
> In octave-maintainers ML, the tread "gnuplot graphics toolkit bugs" is open.
> http://octave.1599824.n4.nabble.com/gnuplot-graphics-toolkit-bugs-td4671157.html
> 
> 
> In the discussion there is a statement.(by Daniel J Sebald)
> 
> ***************************************************************************************
> >    It is now the fastest and most full-featured interactive terminal option. (for qt) 
> 
> except the speed.  Perhaps there is some hardware in which Qt can use, 
> say, OpenGL directly, but on my system that isn't the case.  Qt terminal 
> is drastically slower. 
> ***************************************************************************************
> 
> 
> I have built windows version of gnuplot 5.0 and 5.1 with qt terminal.
> For my PC "all.dem" speed of windows, wxt, qt terminals, the qt terminal is fastest.
> 
> Qt development toolkits (Qt 5.3) for gnuplot for windows build are prepared from source
> with configure option "-no-opengl".
> 
> To my understanding, gnuplot does not use opengl. Am I right?

The Qt libraries can use opengl if it is available at run time.
For some versions of Qt this can be controlled using the environmental
variable QT_GRAPHICSSYSTEM. I think the default is "native" rather than
"opengl", which tells the library to use whatever output layer is
expected to be fastest.

	Ethan



> 
> In other places Daniel state
> ***************************************************************************************
> For example, qt terminal uses QPixmap 
> 
> http://doc.qt.io/qt-5/qpixmap.html
> 
> which is a feature of Qt to handle display of images.  However, this is 
> at a very high level in which image elements are treated individually, 
> not as a whole image.  Consequently, the user will find that the Qt 
> terminal can be rather slow for large data sets.  x11 is very low level, 
> so is much faster.  Yet, wxt is fast as well.
> ***************************************************************************************
> 
> This thread is made from just curiosity.
> 
> Tatsuro 
> 
> ------------------------------------------------------------------------------
> Monitor 25 network devices or servers for free with OpManager!
> OpManager is web-based network management software that monitors 
> network devices and physical & virtual servers, alerts via email & sms 
> for fault. Monitor 25 devices for free with no restriction. Download now
> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

speed of qt terminal

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

In octave-maintainers ML, the tread "gnuplot graphics toolkit bugs" is open.
http://octave.1599824.n4.nabble.com/gnuplot-graphics-toolkit-bugs-td4671157.html


In the discussion there is a statement.(by Daniel J Sebald)

***************************************************************************************
>    It is now the fastest and most full-featured interactive terminal option. (for qt) 

except the speed.  Perhaps there is some hardware in which Qt can use, 
say, OpenGL directly, but on my system that isn't the case.  Qt terminal 
is drastically slower. 
***************************************************************************************


I have built windows version of gnuplot 5.0 and 5.1 with qt terminal.
For my PC "all.dem" speed of windows, wxt, qt terminals, the qt terminal is fastest.

Qt development toolkits (Qt 5.3) for gnuplot for windows build are prepared from source
with configure option "-no-opengl".

To my understanding, gnuplot does not use opengl. Am I right?

In other places Daniel state
***************************************************************************************
For example, qt terminal uses QPixmap 

http://doc.qt.io/qt-5/qpixmap.html

which is a feature of Qt to handle display of images.  However, this is 
at a very high level in which image elements are treated individually, 
not as a whole image.  Consequently, the user will find that the Qt 
terminal can be rather slow for large data sets.  x11 is very low level, 
so is much faster.  Yet, wxt is fast as well.
***************************************************************************************

This thread is made from just curiosity.

Tatsuro 

Re: Is "border" in pm3d redundant?

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

On Thursday, 25 June, 2015 15:03:14 Daniel J Sebald wrote:
> On 06/25/2015 02:22 PM, Ethan A Merritt wrote:
> > On Thursday, 25 June, 2015 14:05:02 Daniel J Sebald wrote:
> [snip]
> >>  Is there something beneficial to "border" beyond the syntax that already
> >
> >>  existed?
> >
> > I don't know of another way to get the equivalent of
> >
> > set pm3d hidden3d border lc "black"
> >
> > splot x*y with pm3d
> >
> > If you try to draw the lines in a separate plot clause, the
> >
> > hidden3d effect is lost.
> 
> How about?
> 
> set hidden3d front
> set samples 100,10
> set isosamples 100,10
> splot x*y with pm3d, x*y with lines lc "black"
> 
> That seems pretty close to the same plot, at least conceptually.  There 
> may be some subtle difference. 

Right. That is one of the work-arounds that can be made to handle
a common case, as in the "hidden2.dem" example.  But it doesn't
extend to the general case.

Anyhow, if there are two ways to get the same output picture - so what?
I advocate for the Perl philosophy:
  "There's more than one way to do it!"
as opposed to the Python countervailing view:
  "there should be one — and preferably only one - obvious way to do it"

	Ethan

Re: Is "border" in pm3d redundant?

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

On 06/25/2015 02:22 PM, Ethan A Merritt wrote:
> On Thursday, 25 June, 2015 14:05:02 Daniel J Sebald wrote:
[snip]
>>  Is there something beneficial to "border" beyond the syntax that already
>
>>  existed?
>
> I don't know of another way to get the equivalent of
>
> set pm3d hidden3d border lc "black"
>
> splot x*y with pm3d
>
> If you try to draw the lines in a separate plot clause, the
>
> hidden3d effect is lost.

How about?

set hidden3d front
set samples 100,10
set isosamples 100,10
splot x*y with pm3d, x*y with lines lc "black"

That seems pretty close to the same plot, at least conceptually.  There 
may be some subtle difference.  Generally, it may not be true that pm3d 
works with hidden3d, but when the two data sets are the same surface it 
is fairly accurate behavior.

Dan

Re: Is "border" in pm3d redundant?

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

On Thursday, 25 June, 2015 14:05:02 Daniel J Sebald wrote:
> On 06/25/2015 01:51 PM, Ethan A Merritt wrote:
> > On Thursday, 25 June, 2015 12:54:55 Daniel J Sebald wrote:
> >
> >>  I was working on an application for which there's to be color surface
> >
> >>  and mesh lines. I began down the route of "border" feature for pm3d,
> >
> >>  which is fairly new. But after a while of not getting what I'd hoped
> >
> >>  for in hidden3d mode, I began to wonder if pm3d/border is redundant
> >
> >>  because gnuplot almost has such capability without the "border" feature.
> >
> >>  Having
> >
> >>
> >
> >>  splot x+y with pm3d border <line characteristics>
> >
> >>
> >
> >>  is sort of re-implementing
> >
> >>
> >
> >>  splot x+y with pm3d, x+y with lines <line characteristics>
> >
> >>
> >
> >>  In the long run we'd like some type of surface color control and true
> >
> >>  hidden3d surface removal. I know pm3d and hidden3d don't combine just
> >
> >>  right, but that doesn't mean the syntax can't trend in a desired
> > direction.
> >
> >>
> >
> >>  The general principle is that the user may want to use the same function
> >
> >>  or data set for multiple plot elements, e.g.,
> >
> >>
> >
> >>  splot "foo" with lines <line chars> [and] surfels <face chars>
> >
> >>
> >
> >>  (or "polygons", "faces", whatever). However, the "and" concept kind of
> >
> >>  exists already with the special "-" filename:
> >
> >>
> >
> >>  splot "foo" with lines <line chars>,
> >
> >>  "-" with surfels <face chars>
> >
> >>
> >
> >>  That is essentially saying "and" because there is no new function/file
> >
> >>  specification.
> >
> > I don't understand. Maybe you mean "" rather than "-"?
> 
> Yes, something like that.  I was just typing from memory, recalling that 
> there is some syntax that utilizes the previous data.
> 
> 
> > I really don't see any need for an "and" syntax.
> 
> The title of the thread is "Is border in pm3d redundant?"  The question 
> is whether "border" is needed since what it achieves (which is plot this 
> "and" that using the same data file) already essentially exists in a 
> more robust and conceptually consistent manner.
> 
> Is there something beneficial to "border" beyond the syntax that already 
> existed?

I don't know of another way to get the equivalent of 

  set pm3d hidden3d border lc "black"
  splot x*y with pm3d

If you try to draw the lines in a separate plot clause, the
hidden3d effect is lost.

	Ethan


> 
> Dan
> 
> ------------------------------------------------------------------------------
> Monitor 25 network devices or servers for free with OpManager!
> OpManager is web-based network management software that monitors 
> network devices and physical & virtual servers, alerts via email & sms 
> for fault. Monitor 25 devices for free with no restriction. Download now
> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Is "border" in pm3d redundant?

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

On 06/25/2015 01:51 PM, Ethan A Merritt wrote:
> On Thursday, 25 June, 2015 12:54:55 Daniel J Sebald wrote:
>
>>  I was working on an application for which there's to be color surface
>
>>  and mesh lines. I began down the route of "border" feature for pm3d,
>
>>  which is fairly new. But after a while of not getting what I'd hoped
>
>>  for in hidden3d mode, I began to wonder if pm3d/border is redundant
>
>>  because gnuplot almost has such capability without the "border" feature.
>
>>  Having
>
>>
>
>>  splot x+y with pm3d border <line characteristics>
>
>>
>
>>  is sort of re-implementing
>
>>
>
>>  splot x+y with pm3d, x+y with lines <line characteristics>
>
>>
>
>>  In the long run we'd like some type of surface color control and true
>
>>  hidden3d surface removal. I know pm3d and hidden3d don't combine just
>
>>  right, but that doesn't mean the syntax can't trend in a desired
> direction.
>
>>
>
>>  The general principle is that the user may want to use the same function
>
>>  or data set for multiple plot elements, e.g.,
>
>>
>
>>  splot "foo" with lines <line chars> [and] surfels <face chars>
>
>>
>
>>  (or "polygons", "faces", whatever). However, the "and" concept kind of
>
>>  exists already with the special "-" filename:
>
>>
>
>>  splot "foo" with lines <line chars>,
>
>>  "-" with surfels <face chars>
>
>>
>
>>  That is essentially saying "and" because there is no new function/file
>
>>  specification.
>
> I don't understand. Maybe you mean "" rather than "-"?

Yes, something like that.  I was just typing from memory, recalling that 
there is some syntax that utilizes the previous data.


> I really don't see any need for an "and" syntax.

The title of the thread is "Is border in pm3d redundant?"  The question 
is whether "border" is needed since what it achieves (which is plot this 
"and" that using the same data file) already essentially exists in a 
more robust and conceptually consistent manner.

Is there something beneficial to "border" beyond the syntax that already 
existed?

Dan

Re: Is "border" in pm3d redundant?

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

On Thursday, 25 June, 2015 12:54:55 Daniel J Sebald wrote:
> I was working on an application for which there's to be color surface 
> and mesh lines.  I began down the route of "border" feature for pm3d, 
> which is fairly new.  But after a while of not getting what I'd hoped 
> for in hidden3d mode, I began to wonder if pm3d/border is redundant 
> because gnuplot almost has such capability without the "border" feature. 
>   Having
> 
> splot x+y with pm3d border <line characteristics>
> 
> is sort of re-implementing
> 
> splot x+y with pm3d, x+y with lines <line characteristics>
> 
> In the long run we'd like some type of surface color control and true 
> hidden3d surface removal.  I know pm3d and hidden3d don't combine just 
> right, but that doesn't mean the syntax can't trend in a desired direction.
> 
> The general principle is that the user may want to use the same function 
> or data set for multiple plot elements, e.g.,
> 
> splot "foo" with lines <line chars> [and] surfels <face chars>
> 
> (or "polygons", "faces", whatever).  However, the "and" concept kind of 
> exists already with the special "-" filename:
> 
> splot "foo" with lines <line chars>,
>        "-" with surfels <face chars>
> 
> That is essentially saying "and" because there is no new function/file 
> specification.

I don't understand. Maybe you mean "" rather than "-"?

I really don't see any need for an "and" syntax.

	Ethan


> 
> So, I'm wondering if things are branching here a bit with regard to 
> pm3d/border and in the long run what the best approach is.  As I said, 
> after some use, I have second thoughts of adding more plot elements via 
> some existing element's option.  I'd rather use a syntax that seems more 
> in line with the eventual concept.
> 
> Dan

Is "border" in pm3d redundant?

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

I was working on an application for which there's to be color surface 
and mesh lines.  I began down the route of "border" feature for pm3d, 
which is fairly new.  But after a while of not getting what I'd hoped 
for in hidden3d mode, I began to wonder if pm3d/border is redundant 
because gnuplot almost has such capability without the "border" feature. 
  Having

splot x+y with pm3d border <line characteristics>

is sort of re-implementing

splot x+y with pm3d, x+y with lines <line characteristics>

In the long run we'd like some type of surface color control and true 
hidden3d surface removal.  I know pm3d and hidden3d don't combine just 
right, but that doesn't mean the syntax can't trend in a desired direction.

The general principle is that the user may want to use the same function 
or data set for multiple plot elements, e.g.,

splot "foo" with lines <line chars> [and] surfels <face chars>

(or "polygons", "faces", whatever).  However, the "and" concept kind of 
exists already with the special "-" filename:

splot "foo" with lines <line chars>,
       "-" with surfels <face chars>

That is essentially saying "and" because there is no new function/file 
specification.

So, I'm wondering if things are branching here a bit with regard to 
pm3d/border and in the long run what the best approach is.  As I said, 
after some use, I have second thoughts of adding more plot elements via 
some existing element's option.  I'd rather use a syntax that seems more 
in line with the eventual concept.

Dan

Re: SourceForge seems to add adware to software (windows installer)

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

On Thu, 18 Jun 2015, Ethan A Merritt wrote:

> On Tuesday, 16 June, 2015 09:54:23 Tatsuro MATSUOKA wrote:
>> Hello
>>
>> SourceForge seems to add adware to software (windows installer).
>
> Today's installment.
> Have your popcorn handy.
>
>
> http://sourceforge.net/blog/project-mirroring-policies-will-be-revisited-with-our-community-panel-existing-mirrors-removed/

That text looks quite satisfactory to me.

It does seem that SF's practice with GIMP was seriously wrong, but I'm 
prepared to take their retraction of that policy at face value until 
proved otherwise.

Allin Cottrell

Re: SourceForge seems to add adware to software (windows installer)

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

----- Original Message -----
>From: Ethan A Merritt 
>To: gnuplot-beta　Tatsuro MATSUOKA  
>Date: 2015/6/19, Fri 06:20
>Subject: Re: SourceForge seems to add adware to software (windows installer)
> 
>
> 
>On Tuesday, 16 June, 2015 09:54:23 Tatsuro MATSUOKA wrote:
>> Hello
>> 
>> SourceForge seems to add adware to software (windows installer).
> 
>Today's installment.
>Have your popcorn handy.
> 
> 
>http://sourceforge.net/blog/project-mirroring-policies-will-be-revisited-with-our-community-panel-existing-mirrors-removed/
> 
> 
>Ethan


Thank you for your information. Unfortunately I could not get popcorn. 
I have read it with drinking coffee.

Tatsuro

Re: SourceForge seems to add adware to software (windows installer)

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

On Tuesday, 16 June, 2015 09:54:23 Tatsuro MATSUOKA wrote:
> Hello
> 
> SourceForge seems to add adware to software (windows installer).

Today's installment.
Have your popcorn handy.


http://sourceforge.net/blog/project-mirroring-policies-will-be-revisited-with-our-community-panel-existing-mirrors-removed/


	Ethan

> 
> 
> Gimp project is an example.
> 
> http://arstechnica.com/information-technology/2015/05/sourceforge-grabs-gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/
> 
> http://www.infoworld.com/article/2929732/open-source-software/sourceforge-commits-reputational-suicide.html
> 
> http://www.engadget.com/2015/05/29/gimp-sourceforge-fight/
> 
> Octave community has started discussions.
>  http://octave.1599824.n4.nabble.com/Sourceforge-adding-adware-to-software-will-we-be-moving-to-github-td4670950.html
>  http://octave.1599824.n4.nabble.com/We-need-to-talk-about-SourceForge-td4670942.html
> 
> 
> However, the problem seems only to be happened only on windows installer.
> 
> Fortunately, the phenomena seem not to be observed on gnuplot windows binary installers.
> 
> The gnuplot windows binary installers are produced by Inno setup dislike other projects.
> It is possible that the selection of Inno setup gives happy a result at this moment.
> 
> 
> I do not think that the gnuplot project should escape SourceForge at this moment but 
> we have to start to consider what should we do when our windows installers will be affected by adwares.
> 
> Tatsuro
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: SourceForge seems to add adware to software (windows installer)

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

On Thu, Jun 18, 2015 at 2:03 AM, Tatsuro MATSUOKA wrote:
>
> 1. File distribution
> Source, small document (NEWS, README), windows binary (installer and zip)
> Facilities of Bitbucket and Github seem not to be so systematical as that in SF.

Distribution of source code is very well supported. But it's *a lot*
easier if ./configure and other vital files become part of the
sources. Then it becomes just a matter of tagging a specific commit
and declaring it to be a version. GitHub/Bitbucket then automatically
generates zip/tar.gz files. GitHub is a bit more picky about
distributing binaries.

> *4 Both Bitbucket and Github do not support CVS.
>  The CVS is now considered to be an old version control. Many other projects uses git or mercurial.
>   Bitbucket git and mercurial
>   Github    git
>
>   Gnuplot project have been used cvs for a long time and code size is not so large and number of people
>   who has write access is limited so that the CVS is enough for the gnuplot project (Am I right?)

I just wanted to say that if anything, CVS is *the* most vulnerable
part of the project and the one that should be "migrated off" with the
highest priority. I don't think the following would happen, but if
SourceForge really starts being evil, you could loose the complete
history of gnuplot source code (unless you make regular backups of CVS
from the server via rsync; not just the current checkout).

>  If the gnuplot project transfer from SF to Bitbucket or Github, the version control system should be changed.

Indeed, but that's a very good thing. Git (and mercurial) have strong
checksumming built in and even if the server disappears out of the
blue, you'll still have a complete copy on everyone's machine and
nobody would be able to tamper with the sources without everyone else
noticing.

CVS is vulnerable. It has a bit of "dementia" (it's not always
possible to reconstruct the exact history), if one deletes a folder,
the whole history of that folder is gone, one can easily modify files
on the server ...

>  The automatic transfer tools from cvs to git or mercurial exist but they seem not to be complete.
>  Human resources will be required if we change the version control system.

People offered help, but it was usually declined because developers
wanted to stick to CVS. The problem with "incompleteness" of the tools
is that CVS history cannot be reconstructed exactly, so one needs some
 heuristics and guessing (and some obscure features like tagging
together files from different times cannot easily be reproduced in
git). And the longer one waits, the more history gets "forgotten".

The main problem with CVS -> GIT conversion is that it's feasible to
do it once, but it's very annoying to do incremental updates.

Mojca

Re: SourceForge seems to add adware to software (windows installer)

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

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

> From: Tatsuro MATSUOKA 
> To: "plotter; Clark Gaylord
> Cc: gnu...@li...
> Date: 2015/6/18, Thu 09:03
> Subject: Re: SourceForge seems to add adware to software (windows installer)
> 
> ----- Original Message -----
> 
>>  From: "plotter
>>  To: Clark Gaylord 
>>  Cc: gnuplot-beta
>>  Date: 2015/6/17, Wed 20:18
>>  Subject: Re: SourceForge seems to add adware to software (windows 
> installer)
>> 
>>  On 17/06/15 13:04, Clark Gaylord wrote:
>>>   The only exception I would make is that this change in philosophy at 
>>  SourceForge isn't new. I have never felt they were trustworthy, only 
>>  (begrudgingly) convenient.
>>> 
>>>   Action item: we should always (have had) reference to the canonical 
> gnuplot 
>>  domain: gnuplot.info At this time, that points to SourceForge and will for 
> the 
>>  foreseeable future, but when it changes to another hosting service we only 
> want 
>>  a simple DNS update to make it happen. This change is an eventuality, so we 
> 
>>  should make changes to all documentation now.
>>> 
>>>   --
>>>   Clark Gaylord
>>>   cla...@fa...
>> 
>>  Good suggestion.
>> 
>> 
>>  Hijacking an account then calling it a "mirror" when it delivers 
>>  something else with undeclared additional software being installed on 
>>  the end user's computer is fundamentally dishonest.
>> 
>>  If it was a mirror it would provide the same thing: byte perfect, not 
>>  commercial crap.
>> 
>>  It betrays the confidence people have in the original product and 
>>  damages the reputation thereof.  Image is important and can be 
>>  monetised, which is what they are doing, except it is someone else's 
>>  rep. they profiting from and damaging in the process.
>> 
>>    If someone could get it together to sue, they would likely be entitled 
>>  to damages.
>> 
>>  Peter.
> 
> 
> I also think that SourceForge (SF) behavior becomes really bad but facilities 
> that
> SF provides is not so bad.
> 
> I summarized what services the gnuplot project are offered from SF and compare 
> them
> on those alternative (Bitbucket and Github).
> (I do not have write access right to the gnuplot project on SF so my summary
> may not be complete. Please correct errors the below.)
> 
>  1. File distribution
>   Source, small document (NEWS, README), windows binary (installer and zip)
> 
>  2. Project Trackers
>   Bugs
> 
>   Feature Requests
>   Patches
>   Support Requests
> 
>  3. Project Mailing Lists
>   gnuplot-beta: Subscribe | Archive | Search — Developers and beta testers of 
> new gnuplot code
>   gnuplot-info: Subscribe | Archive | Search — For questions and discussion 
> about gnuplot
> 
> 
>  4. CVS version control system
> 
>  # The "News" facility on SF has been used until ver 4.6.4 but later 
> version do not use this facility.
> 
> According to the page I introduced in my previous post
>  https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities
> 
> 
> Popular source code hosting facilities seems to be Bitbucket and Github.
> 
> For Bitbucket and Github
> 1.* 2. 4.* are supported but 3*. is not supported.
> 
> *1 Facilities of Bitbucket and Github seem not to be so systematical as that in 
> SF.
> 
> *3 Bitbucket and Github do not also support forum. 
>   I found the tortoisehg uses Bitbucket but their mailing list is hosted on SF
>   Mailing list (Personally I prefer mailing list than forum.) or forum cannot be 
> omitted from the project. 
> 
> *4 Both Bitbucket and Github do not support CVS.
>  The CVS is now considered to be an old version control. Many other projects 
> uses git or mercurial.
>   Bitbucket git and mercurial
>   Github    git  
> 
>   Gnuplot project have been used cvs for a long time and code size is not so 
> large and number of people 
>   who has write access is limited so that the CVS is enough for the gnuplot 
> project (Am I right?)
> 
>  If the gnuplot project transfer from SF to Bitbucket or Github, the version 
> control system should be changed.
>  The automatic transfer tools from cvs to git or mercurial exist but they seem 
> not to be complete.
>  Human resources will be required if we change the version control system.
> 
> To be honest, I myself cannot judge that the gnuplot project should leave SF 
> because I have never done maintaining
> works on SF system.
> 
> Tatsuro 


Perhaps many people know the below but at least for me I have found this today
(2015-06-18).

Third party offers will be presented with Opt-In projects only

http://sourceforge.net/blog/third-party-offers-will-be-presented-with-opt-in-projects-only/


I personally feel that their statement is not consistent with that Gimp project insists on 
this issue.  However, they state that they added adware to the binary of unmaintained project.
The gnuplot project is very active on SF. 
 * Changes on the source tree have been done very frequently.

 * Version up has been regularly done. 

Believing SF's statement the above, the gnuplot project may not become a target.
Therefore we do not need hurry at this moment and discuss this issue with taking time involving 
other people who are related to the gnuplot project. 

# However, what they did on Gimp windows installer is quite horrible.
# I wonder that SF will change their matter again to illy direction.

Tatsuro

Re: SourceForge seems to add adware to software (windows installer)

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

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

> From: "plotter
> To: Clark Gaylord 
> Cc: gnuplot-beta
> Date: 2015/6/17, Wed 20:18
> Subject: Re: SourceForge seems to add adware to software (windows installer)
> 
> On 17/06/15 13:04, Clark Gaylord wrote:
>>  The only exception I would make is that this change in philosophy at 
> SourceForge isn't new. I have never felt they were trustworthy, only 
> (begrudgingly) convenient.
>> 
>>  Action item: we should always (have had) reference to the canonical gnuplot 
> domain: gnuplot.info At this time, that points to SourceForge and will for the 
> foreseeable future, but when it changes to another hosting service we only want 
> a simple DNS update to make it happen. This change is an eventuality, so we 
> should make changes to all documentation now.
>> 
>>  --
>>  Clark Gaylord
>>  cla...@fa...
> 
> Good suggestion.
> 
> 
> Hijacking an account then calling it a "mirror" when it delivers 
> something else with undeclared additional software being installed on 
> the end user's computer is fundamentally dishonest.
> 
> If it was a mirror it would provide the same thing: byte perfect, not 
> commercial crap.
> 
> It betrays the confidence people have in the original product and 
> damages the reputation thereof.  Image is important and can be 
> monetised, which is what they are doing, except it is someone else's 
> rep. they profiting from and damaging in the process.
> 
>   If someone could get it together to sue, they would likely be entitled 
> to damages.
> 
> Peter.


I also think that SourceForge (SF) behavior becomes really bad but facilities that
SF provides is not so bad.

I summarized what services the gnuplot project are offered from SF and compare them
on those alternative (Bitbucket and Github).
(I do not have write access right to the gnuplot project on SF so my summary
may not be complete. Please correct errors the below.)

 1. File distribution
  Source, small document (NEWS, README), windows binary (installer and zip)

 2. Project Trackers
  Bugs

  Feature Requests
  Patches
  Support Requests

 3. Project Mailing Lists
  gnuplot-beta: Subscribe | Archive | Search — Developers and beta testers of new gnuplot code
  gnuplot-info: Subscribe | Archive | Search — For questions and discussion about gnuplot


 4. CVS version control system

 # The "News" facility on SF has been used until ver 4.6.4 but later version do not use this facility.

According to the page I introduced in my previous post
 https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities


Popular source code hosting facilities seems to be Bitbucket and Github.

For Bitbucket and Github
1.* 2. 4.* are supported but 3*. is not supported.

*1 Facilities of Bitbucket and Github seem not to be so systematical as that in SF.

*3 Bitbucket and Github do not also support forum. 
  I found the tortoisehg uses Bitbucket but their mailing list is hosted on SF
  Mailing list (Personally I prefer mailing list than forum.) or forum cannot be omitted from the project. 

*4 Both Bitbucket and Github do not support CVS.
 The CVS is now considered to be an old version control. Many other projects uses git or mercurial.
  Bitbucket git and mercurial
  Github    git  

  Gnuplot project have been used cvs for a long time and code size is not so large and number of people 
  who has write access is limited so that the CVS is enough for the gnuplot project (Am I right?)

 If the gnuplot project transfer from SF to Bitbucket or Github, the version control system should be changed.
 The automatic transfer tools from cvs to git or mercurial exist but they seem not to be complete.
 Human resources will be required if we change the version control system.

To be honest, I myself cannot judge that the gnuplot project should leave SF because I have never done maintaining
works on SF system.

Tatsuro 

Re: SourceForge seems to add adware to software (windows installer)

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

On 17/06/15 13:04, Clark Gaylord wrote:
> The only exception I would make is that this change in philosophy at SourceForge isn't new. I have never felt they were trustworthy, only (begrudgingly) convenient.
>
> Action item: we should always (have had) reference to the canonical gnuplot domain: gnuplot.info At this time, that points to SourceForge and will for the foreseeable future, but when it changes to another hosting service we only want a simple DNS update to make it happen. This change is an eventuality, so we should make changes to all documentation now.
>
> --
> Clark Gaylord
> cla...@fa...

Good suggestion.


Hijacking an account then calling it a "mirror" when it delivers 
something else with undeclared additional software being installed on 
the end user's computer is fundamentally dishonest.

If it was a mirror it would provide the same thing: byte perfect, not 
commercial crap.

It betrays the confidence people have in the original product and 
damages the reputation thereof.  Image is important and can be 
monetised, which is what they are doing, except it is someone else's 
rep. they profiting from and damaging in the process.

  If someone could get it together to sue, they would likely be entitled 
to damages.

Peter.

Re: SourceForge seems to add adware to software (windows installer)

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

On 17/06/15 02:50, Tatsuro MATSUOKA wrote:
> ----- Original Message -----
>
>> From: sfeam
>> To: gnuplot-beta Tatsuro MATSUOKA
>> Cc:
>> Date: 2015/6/16, Tue 15:18
>> Subject: Re: SourceForge seems to add adware to software (windows installer)
>
>> Anyhow, I have added md5 checksums for the gnuplot windows installer binaries
>> on the download page.   Anyone worried about authenticity should confirm
>> the checksum values before running the installer.
>>
>>      Ethan
>
>
> This is information:
> Usual windows users are not familiar with checksum.
> Please see:
>
> https://en.wikipedia.org/wiki/Checksum
>
>
>
> On windows, Checksum software is not installed by default.
> (I have been used "md5sum" on msys or cygwin.)
>
> A command line tool "File Checksum Integrity Verifier" fciv.exe can be downloaded from
> Microsoft site
> https://www.microsoft.com/en-us/download/details.aspx?id=11533
>
>
> GUI based Checksum software working on windows can be found on the web.
> (There are many softwares for this purpose so that I cannot recommend which is the best.)
>
> Tatsuro
>


Most lambda Windoze users don't even know what a command line is , let 
alone a checksum. It's just click, click. double click; say OK to some 
EULA they never read then reboot Windoze.


Adding checksum information is probably a good step anyway, though.

Since SF's dishonest behaviour is motivated by creating a revenue 
source, it would seem that gnuplot will not be likely target, at least 
until they do this kind of crap to every download on their site, which I 
suppose is the logical conclusion.

Initially they will target only large circulation packages like GIMP. 
Gnuplot is fairly specialised and requires a fair degree of technical 
competence and has a fairly studious learning curve.
Those wanting banal graph plotting capabilities will use Exce.

However, since SF is clearly becoming unreliable and dishonest, it may 
be worth looking for an exit plan before it becomes a pressing problem, 
possibly with added constraints which do not currently exist.

It seems like it should be treated like shutting down a FaceBook 
account: you never say you want to close it but remove everything and 
retain your log-in rather than relinquishing access. In the case of SF 
update the readme every month or so, so as not to have it  picked up as 
'dormant' and re-appropriated.

Removing any references to SF as a download source will wither the 
traffic and make it progressively less and less attractive as an adware 
revenue source

Presenting this kind of thing as a "mirror" which is supposed to 
*reflect* exactly the same content as the source is again dishonest . 
Hopefully someone like Mozilla, who have the resources will sue their 
butt and get this practice stopped.


Peter.

Re: SourceForge seems to add adware to software (windows installer)

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

I have investigated how the source code hosting services are different.

Perhaps many people know the below but I myself found this today.

As information for those who are not familiar to the below (including me) 

Comparison of source code hosting facilities

 https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities

Tatsuro

Re: SourceForge seems to add adware to software (windows installer)

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

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

> From: sfeam 
> To: gnuplot-beta Tatsuro MATSUOKA 
> Cc: 
> Date: 2015/6/16, Tue 15:18
> Subject: Re: SourceForge seems to add adware to software (windows installer)

> Anyhow, I have added md5 checksums for the gnuplot windows installer binaries
> on the download page.   Anyone worried about authenticity should confirm
> the checksum values before running the installer.
> 
>     Ethan


This is information:
Usual windows users are not familiar with checksum.
Please see:

https://en.wikipedia.org/wiki/Checksum



On windows, Checksum software is not installed by default.
(I have been used "md5sum" on msys or cygwin.)

A command line tool "File Checksum Integrity Verifier" fciv.exe can be downloaded from
Microsoft site
https://www.microsoft.com/en-us/download/details.aspx?id=11533


GUI based Checksum software working on windows can be found on the web.
(There are many softwares for this purpose so that I cannot recommend which is the best.)

Tatsuro

Re: SourceForge seems to add adware to software (windows installer)

[Clark G. <cla...@fa...>]

Signing is definitely a good idea.

If you guys want to move away from sf, I'm willing to facilitate as needed. At one time we hosted everything at Virginia Tech (I think the primary v6 location might actually still be here - sf's IPv6 routing was frequently broken when I set this up).

Likewise, we can always separate the canonical gnuplot.info distribution location from wherever we manage code (part of the reason we shouldn't publicize the SourceForge links directly even when is hosted there). Github is clearly a good option for code repository; bitbucket is also quite good.

So far it sounds like there's not a lot of groundswell for moving, but let me know. Worth considering, imho.

Regards
Clark

--
Clark Gaylord
cla...@fa...

... thumbed on Android
    auto-correct may have improved this message ...

On Jun 16, 2015 4:48 AM, Lars Hecking <lhe...@us...> wrote:
>
>
> > It is a good idea to add md5 checksums. 
> > 
> > (I have been providing md5 checksums for my own binaries of cvs version gnuplot for windows on my ??distribution site.) 
>
> I used to sign releases with my gpg key. Maybe the creation of a signing key 
> would not be such a bad idea. 
>
>
> ------------------------------------------------------------------------------ 
> _______________________________________________ 
> gnuplot-beta mailing list 
> gnu...@li... 
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta 

Re: SourceForge seems to add adware to software (windows installer)

[Lars H. <lhe...@us...>]

> It is a good idea to add md5 checksums.
> 
> (I have been providing md5 checksums for my own binaries of cvs version gnuplot for windows on my ??distribution site.)
 
 I used to sign releases with my gpg key. Maybe the creation of a signing key
 would not be such a bad idea.

Re: SourceForge seems to add adware to software (windows installer)

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

----- Original Message -----
> From: sfeam 
> To: gnuplot-beta Tatsuro MATSUOKA
> Cc: 
> Date: 2015/6/16, Tue 15:18
> Subject: Re: SourceForge seems to add adware to software (windows installer)
> 
> On Tuesday, 16 June 2015 09:54:23 AM Tatsuro MATSUOKA wrote:
>>  Hello
>> 
>>  SourceForge seems to add adware to software (windows installer).
>> 
>> 
>>  Gimp project is an example.
>> 
>> 
> http://arstechnica.com/information-technology/2015/05/sourceforge-grabs-gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/
>> 
>> 
> http://www.infoworld.com/article/2929732/open-source-software/sourceforge-commits-reputational-suicide.html
>> 
>>  http://www.engadget.com/2015/05/29/gimp-sourceforge-fight/
>> 
>>  Octave community has started discussions.
>>   
> http://octave.1599824.n4.nabble.com/Sourceforge-adding-adware-to-software-will-we-be-moving-to-github-td4670950.html
>>   
> http://octave.1599824.n4.nabble.com/We-need-to-talk-about-SourceForge-td4670942.html
>> 
>> 
>>  However, the problem seems only to be happened only on windows installer.
> 
> More information and discussion here:
> 
>   http://lwn.net/Articles/646118/
> 
Thank you for your information. 
I have gotten to know what happened in the Gimp Project in more details.



>>  I do not think that the gnuplot project should escape SourceForge at this 
> moment but 
>>  we have to start to consider what should we do when our windows installers 
> will be affected by adwares.
> 


> In the case of the Gimp project, the project had *already left* SourceForge.
> The Gimp developers themselves were no longer placing any files on SourceForge.
> The offending installers were placed in the former (no longer in use) 
> project page on SourceForge.  
> 
> Anyhow, I have added md5 checksums for the gnuplot windows installer binaries
> on the download page.   Anyone worried about authenticity should confirm
> the checksum values before running the installer.
> 


It is a good idea to add md5 checksums.

(I have been providing md5 checksums for my own binaries of cvs version gnuplot for windows on my  distribution site.)

Tatsuro

Re: SourceForge seems to add adware to software (windows installer)

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

On Tuesday, 16 June 2015 09:54:23 AM Tatsuro MATSUOKA wrote:
> Hello
> 
> SourceForge seems to add adware to software (windows installer).
> 
> 
> Gimp project is an example.
> 
> http://arstechnica.com/information-technology/2015/05/sourceforge-grabs-gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/
> 
> http://www.infoworld.com/article/2929732/open-source-software/sourceforge-commits-reputational-suicide.html
> 
> http://www.engadget.com/2015/05/29/gimp-sourceforge-fight/
> 
> Octave community has started discussions.
>  http://octave.1599824.n4.nabble.com/Sourceforge-adding-adware-to-software-will-we-be-moving-to-github-td4670950.html
>  http://octave.1599824.n4.nabble.com/We-need-to-talk-about-SourceForge-td4670942.html
> 
> 
> However, the problem seems only to be happened only on windows installer.

More information and discussion here:

  http://lwn.net/Articles/646118/

 
> Fortunately, the phenomena seem not to be observed on gnuplot windows binary installers.
> 
> The gnuplot windows binary installers are produced by Inno setup dislike other projects.
> It is possible that the selection of Inno setup gives happy a result at this moment.
> 
> 
> I do not think that the gnuplot project should escape SourceForge at this moment but 
> we have to start to consider what should we do when our windows installers will be affected by adwares.

In the case of the Gimp project, the project had *already left* SourceForge.
The Gimp developers themselves were no longer placing any files on SourceForge.
The offending installers were placed in the former (no longer in use) 
project page on SourceForge.  

Anyhow, I have added md5 checksums for the gnuplot windows installer binaries
on the download page.   Anyone worried about authenticity should confirm
the checksum values before running the installer.

	Ethan

SourceForge seems to add adware to software (windows installer)

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

Hello

SourceForge seems to add adware to software (windows installer).


Gimp project is an example.

http://arstechnica.com/information-technology/2015/05/sourceforge-grabs-gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/

http://www.infoworld.com/article/2929732/open-source-software/sourceforge-commits-reputational-suicide.html

http://www.engadget.com/2015/05/29/gimp-sourceforge-fight/

Octave community has started discussions.
 http://octave.1599824.n4.nabble.com/Sourceforge-adding-adware-to-software-will-we-be-moving-to-github-td4670950.html
 http://octave.1599824.n4.nabble.com/We-need-to-talk-about-SourceForge-td4670942.html


However, the problem seems only to be happened only on windows installer.

Fortunately, the phenomena seem not to be observed on gnuplot windows binary installers.

The gnuplot windows binary installers are produced by Inno setup dislike other projects.
It is possible that the selection of Inno setup gives happy a result at this moment.


I do not think that the gnuplot project should escape SourceForge at this moment but 
we have to start to consider what should we do when our windows installers will be affected by adwares.

Tatsuro