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

Re: gnuplot 1.0

[Ethan A M. <me...@uw...>]

On Wednesday, 2 April 2025 17:52:48 PDT Shigeharu TAKENO wrote:

> shige 04/03 2025
> ----------------
> 
> Old gnuplot-1.1 is in SouceForge site. I found historical old 
> gnuplot 1.0 (1.0.3).
> 
> I make the archive file of them (.tar.Z) 
> 
>  http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/data/gnuplot-1.0.tar.Z
>

Very nice code archaeology.  Congratulations.

I don't have a version of gcc old enough to compile it with without
providing a compatibility header and hacking a couple of lines that
refer to obsolete error handling, but after that the *.c files compile
with only a few complaints!

I will add the tarball to the gnuplot-historical directory on SourceForge.
It would be nice to also add it to the git repository, but ...

When  Eric Raymond helped create our current git repository from a combination
of the cvs content and historical tarballs of earlier versions he made it so that
each of the historical version was present as a tag.  I can check each one
out by name for inspection.  Like this:

=========================================================
[~/git/gnuplot-main] git tag
1.1
1.10A
2.0
3.0
3.1
3.2
3.5
3.7.1
3.7.2
3.7.3
... etc

[~/git/gnuplot-main] git checkout --detach 1.1
HEAD is now at 2f87cf77c Content from historic/gnuplot-1.1.tar.gz
=========================================================

But I have no idea how to add this version 1.0 snapshot to the repository
so that it matches the others.
Does anyone know an appropriate set of git commands?


> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
-- 
Ethan A Merritt
Department of Biochemistry
University of Washington, Seattle

gnuplot 1.0

[Shigeharu T. <sh...@ie...>]

shige 04/03 2025
----------------

Old gnuplot-1.1 is in SouceForge site. I found historical old 
gnuplot 1.0 (1.0.3).

announce: https://usenet.trashworldnews.com/?thread=114748
1/6: https://usenet.trashworldnews.com/?thread=114473
2/6: https://usenet.trashworldnews.com/?thread=114532
3/6: https://usenet.trashworldnews.com/?thread=114531
4/6: https://usenet.trashworldnews.com/?thread=114530
5/6: https://usenet.trashworldnews.com/?thread=114529
6/6: https://usenet.trashworldnews.com/?thread=114528

I make the archive file of them (.tar.Z) 

  http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/data/gnuplot-1.0.tar.Z

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Development binaries for windows are moved

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

Development binaries site for windows has been moved

Development version:
Windows binaries built by Tatsuro Matsuoka: http://ss009322.stars.ne.jp/gnuplot_bin.html (http://tmacchant33.starfree.jp/gnuplot_bin.html)

Tatsuro

Resolved: Gnuplot with Qt terminal on macOS

[Erik L. <eri...@gm...>]

Dear all,

Since the topic of Qt on macOS has come up repeatedly on this mailing list,
I am glad to report that static binaries (which I focus on to make sure
that installation packages are self-contained) for gnuplot 6.0.2 and the Qt
terminal are available now. Executables for Intel- and ARM-based Macs can
be found at
https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_macOS

Please do not hesitate to report any problems.

While on the topic of Qt. I hope this is not a silly question, but am I
correct that the buttons with the magnifying glass and a +/– sign do not do
what I would expect (namely zoom in/out)? Instead, they seem to serve to go
to the next/previous zoom level, IF one has already gone through a sequence
of zoom steps using the + key. At first, this seemed so odd that I assumed
it was a problem with Qt on macOS, but I now confirmed that on Linux
gnuplot + Qt works the same way. Am I missing something?

Kind regards,

Erik

Re: Static compilation with Qt

[Erik L. <eri...@gm...>]

Hi, I did solve the second problem, I believe. In
src/qtterminal/gnuplot_qt.cpp, immediately prior to the line


QtGnuplotApplication application(argc, argv);

one needs the line:

Q_IMPORT_PLUGIN(QCocoaIntegrationPlugin);



As far as I can tell, other platforms would need a similar line if one
wishes to build a static binary. For Qt6, the list is here:
https://doc.qt.io/qt-6/qpa.html

Erik


On Wed, Mar 19, 2025 at 3:28 PM Erik Luijten <eri...@gm...> wrote:

> Dear all,
>
> I am trying to create gnuplot executables for macOS in which the Qt
> libraries are statically linked. It is easy to create static versions of
> Qt, but I run into two problems:
>
>
> 1. Compilation of gnuplot on macOS relies on pkg-config, but to the best
> of my knowledge, pkg-config is not supported in Qt6 (if I am mistaken, I
> would be grateful for pointers).
>
>
> 2. Qt5 has support for pkg-config. A regular (dynamic) binary of gnuplot
> works well with Qt. However, a statically compiled version of gnuplot
> starts properly, but as soon as I issue the first plot command there is a
> warning:
>
> qt.qpa.plugin: Could not find the Qt platform plugin "cocoa" in ""
>
>
>
> If I restart gnuplot after setting "export QT_DEBUG_PLUGINS=1", I get:
>
> FactoryLoader::QFactoryLoader() ignoring
> "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3" since
> plugins are disabled in static builds
>
>
> As far as I can tell, the qtterminal source code should have a
> Q_IMPORT_PLUGIN() command to work properly with static compilation, but I
> do not know enough about Qt to be sure.
>
>
> Any help would be appreciated!
>
> Erik
>

Re: Static compilation with Qt

[Dima K. <gn...@di...>]

You don't NEED pkg-config. All it does is give you some compiler flags
and linker flags. You can set those flags yourself, at least until the
pkg-config breakage is resolved. On my box (Debian/sid) I see this:

  dima@shorty:~/projects/gnuplot$ for p (Qt6Core Qt6Gui Qt6Network Qt6Svg Qt6PrintSupport Qt6Widgets Qt6Core5Compat) { pkg-config --cflags $p }
  -I/usr/include/x86_64-linux-gnu/qt6/QtCore -I/usr/include/x86_64-linux-gnu/qt6 -DQT_CORE_LIB -I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ 
  -I/usr/include/x86_64-linux-gnu/qt6/QtGui -I/usr/include/x86_64-linux-gnu/qt6 -DQT_GUI_LIB -I/usr/include/x86_64-linux-gnu/qt6/QtCore -DQT_CORE_LIB -I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ 
  -I/usr/include/x86_64-linux-gnu/qt6/QtNetwork -I/usr/include/x86_64-linux-gnu/qt6 -DQT_NETWORK_LIB -I/usr/include/x86_64-linux-gnu/qt6/QtCore -DQT_CORE_LIB -I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ 
  -I/usr/include/x86_64-linux-gnu/qt6/QtSvg -I/usr/include/x86_64-linux-gnu/qt6 -DQT_SVG_LIB -I/usr/include/x86_64-linux-gnu/qt6/QtCore -I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ -I/usr/include/x86_64-linux-gnu/qt6/QtGui -DQT_GUI_LIB -DQT_CORE_LIB 
  -I/usr/include/x86_64-linux-gnu/qt6/QtPrintSupport -I/usr/include/x86_64-linux-gnu/qt6 -DQT_PRINTSUPPORT_LIB -I/usr/include/x86_64-linux-gnu/qt6/QtCore -I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ -I/usr/include/x86_64-linux-gnu/qt6/QtGui -I/usr/include/x86_64-linux-gnu/qt6/QtWidgets -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB 
  -I/usr/include/x86_64-linux-gnu/qt6/QtWidgets -I/usr/include/x86_64-linux-gnu/qt6 -DQT_WIDGETS_LIB -I/usr/include/x86_64-linux-gnu/qt6/QtCore -I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ -I/usr/include/x86_64-linux-gnu/qt6/QtGui -DQT_GUI_LIB -DQT_CORE_LIB 
  -I/usr/include/x86_64-linux-gnu/qt6/QtCore5Compat -I/usr/include/x86_64-linux-gnu/qt6 -DQT_CORE5COMPAT_LIB -I/usr/include/x86_64-linux-gnu/qt6/QtCore -DQT_CORE_LIB -I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ 

  dima@shorty:~/projects/gnuplot$ for p (Qt6Core Qt6Gui Qt6Network Qt6Svg Qt6PrintSupport Qt6Widgets Qt6Core5Compat) { pkg-config --libs $p }  
  -lQt6Core 
  -lQt6Gui -lQt6Core 
  -lQt6Network -lQt6Core 
  -lQt6Svg -lQt6Gui -lQt6Core 
  -lQt6PrintSupport -lQt6Widgets -lQt6Gui -lQt6Core 
  -lQt6Widgets -lQt6Gui -lQt6Core 
  -lQt6Core5Compat -lQt6Core 

So you can try to feed in the equivalent for your box.

Re: Static compilation with Qt

[Ethan A M. <me...@uw...>]

On Wednesday, 19 March 2025 13:28:24 PDT Erik Luijten wrote:
> Dear all,
> 
> I am trying to create gnuplot executables for macOS in which the Qt
> libraries are statically linked. It is easy to create static versions of
> Qt, but I run into two problems:
> 
> 
> 1. Compilation of gnuplot on macOS relies on pkg-config, but to the best
> of my knowledge, pkg-config is not supported in Qt6 (if I am mistaken, I
> would be grateful for pointers).

I use pkg-config with Qt6 without problems.

I am aware of two past pkg-config +Qt6 related issues on the linux side.
(1) Fedora breaks down the Qt6 dependencies differently, so we needed to add a 
check in the configure script that picked them all up.  That change is in 6.0.1
     https://sourceforge.net/p/gnuplot/bugs/2705/

(2) There was an Ubuntu packaging error that failed in include the pkg-config files
*.pc in the initial Ubuntu Qt6 packages, and this failure propagated to ubuntu
derivatives like Mint.  I confirmed at the time that (at least on Mint)
it was sufficient to regenerate the *.pc files directly from the Qt repository or
to copy them, after inspection, from another linux distro.  That problem was
acknowledged upstream by Unbuntu, but I have not tracked the resolution since then.
Here is a link to one message in the thread exploring this
    https://sourceforge.net/p/gnuplot/mailman/message/58773575/

I don't know why a Fedora or Ubuntu glitch would affect macOS, but perhaps there was
a parallel failure with the same result. 

> 
> 
> 2. Qt5 has support for pkg-config. A regular (dynamic) binary of gnuplot
> works well with Qt. However, a statically compiled version of gnuplot
> starts properly, but as soon as I issue the first plot command there is a
> warning:
> 
> qt.qpa.plugin: Could not find the Qt platform plugin "cocoa" in ""

I can't help you here. I believe that Cocoa is one of several possible graphics 
backends for Qt on macOS, but if you switch to one of the others you may well
just get the equivalent warning for that new backend.

	Ethan


> 
> 
> If I restart gnuplot after setting "export QT_DEBUG_PLUGINS=1", I get:
> 
> FactoryLoader::QFactoryLoader() ignoring
> "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3" since
> plugins are disabled in static builds
> 
> 
> As far as I can tell, the qtterminal source code should have a
> Q_IMPORT_PLUGIN() command to work properly with static compilation, but I
> do not know enough about Qt to be sure.
> 
> 
> Any help would be appreciated!
> 
> Erik
> 

Static compilation with Qt

[Erik L. <eri...@gm...>]

Dear all,

I am trying to create gnuplot executables for macOS in which the Qt
libraries are statically linked. It is easy to create static versions of
Qt, but I run into two problems:


1. Compilation of gnuplot on macOS relies on pkg-config, but to the best
of my knowledge, pkg-config is not supported in Qt6 (if I am mistaken, I
would be grateful for pointers).


2. Qt5 has support for pkg-config. A regular (dynamic) binary of gnuplot
works well with Qt. However, a statically compiled version of gnuplot
starts properly, but as soon as I issue the first plot command there is a
warning:

qt.qpa.plugin: Could not find the Qt platform plugin "cocoa" in ""



If I restart gnuplot after setting "export QT_DEBUG_PLUGINS=1", I get:

FactoryLoader::QFactoryLoader() ignoring
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3" since
plugins are disabled in static builds


As far as I can tell, the qtterminal source code should have a
Q_IMPORT_PLUGIN() command to work properly with static compilation, but I
do not know enough about Qt to be sure.


Any help would be appreciated!

Erik

Re: Website doesn't have links to the bug tracker

[Ethan A M. <me...@uw...>]

On Monday, 24 February 2025 10:34:46 PST Dima Kogan wrote:
> Hi.
> 
> Our website:
> 
>   gnuplot.sourceforge.net

> has links to the git repo, but not to the bug tracker or mailing lists
> or anything like that. That stuff lives on the sourceforge project page:

???
I am not 100% certain what you see when you cllck on the "git repo" link.
Perhaps it is browser-dependent, or depends on whether SourceForge recognizes you?
For me it lands on a page where the navigation panel directly below the line with the
gnuplot logo and title "gnuplot Git Repository" looks like this:

  Summary  Files  Reviews  Support  Tickets▾  Git Repository  Mailing Lists Discussion News ...


The Tickets pull-down opens up the bug tracker, feature requests, etc.

I can change the home page to say "git repository and issue tracker".
That's a reasonable idea.
I don't know if there's a better label than "Tickets" for the pull-down menu on the
project page (and for that matter I don't know if I can change it).

>> but that's not linked from our website either. Can we add some links?

I agree it would be good to duplicate that link at the top of the home page.

> Today, filing a bug is non-obvious if you don't already know where the
> tracker is.

Every time one runs gnuplot it starts with the splash page
        G N U P L O T
        Version 6.0 patchlevel 2    last modified 2024-12-04 

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

        gnuplot home:     http://www.gnuplot.info
        faq, bugs, etc:   type "help FAQ"

gnuplot> help FAQ
[snip]
 Bug reports and feature requests should be uploaded to the trackers at
           https://sourceforge.net/p/gnuplot/_list/tickets
 Please check previous reports to see if the bug you want to report has
 already been fixed in a newer version.
[snip]

    Ethan

Website doesn't have links to the bug tracker

[Dima K. <gn...@di...>]

Hi.

Our website:

  https://gnuplot.sourceforge.net/

has links to the git repo, but not to the bug tracker or mailing lists
or anything like that. That stuff lives on the sourceforge project page:

  https://sourceforge.net/projects/gnuplot/

but that's not linked from our website either. Can we add some links?
Today, filing a bug is non-obvious if you don't already know where the
tracker is.

Thanks

Re: AquaTerm (all solved)

[Erik L. <eri...@gm...>]

Intel version:
https://pergamon.ms.northwestern.edu/Download/Gnuplot/aquaterm-1.1.1p1-x86_64.pkg

These are just intended for testing, e.g. by you, Jun.

Thanks,

Erik


On Sat, Feb 1, 2025 at 8:29 AM Erik Luijten <eri...@gm...> wrote:

> Here is a version for ARM-based Macs, probably requiring Sequoia 15.2 or
> up:
> https://pergamon.ms.northwestern.edu/Download/Gnuplot/aquaterm-1.1.1p1-arm64.pkg
>
> On Sat, Feb 1, 2025 at 8:19 AM Erik Luijten <eri...@gm...>
> wrote:
>
>> Hi Jun,
>>
>> Yes, that resolves the problem! How do we proceed? Ideally, this bugfix
>> should be made in the distribution of AquaTerm. If this is hard, maybe I
>> can distribute compiled AquaTerm packages for ARM and Intel as "1.1.1
>> patchlevel 1" or so.
>>
>> By the way, I have not checked for any unintended side effects in
>> AquaTerm.
>>
>> Best,
>>
>> Erik
>>
>> On Fri, Jan 31, 2025 at 7:06 PM Jun. T <tak...@kb...>
>> wrote:
>>
>>>
>>> > 2025/01/28 7:00, Ethan A Merritt <me...@uw...> wrote:
>>> >
>>> > Also, can someone now check whether Bug #1969 "Aquaterm: plot using
>>> third column for color palette value loses every 2nd line" is still a
>>> problem or can now be closed?   Maybe I should close it anyhow, since the
>>> aquaterm project seems moribund.
>>> >     https://sourceforge.net/p/gnuplot/bugs/1969/
>>>
>>>
>>> > 2025/01/28 7:05、Erik Luijten <eri...@gm...>のメール:
>>> >
>>> > I just checked. The problem still exists (screenshots below). I know
>>> nothing about AquaTerm, so cannot assist in resolving this, unfortunately.
>>>
>>> Could you please try the following patch when building AquaTerm.app?
>>> (I hope it has no bad side effects.)
>>>
>>> Jun
>>>
>>>
>>>
>>> --- AQTPlotBuilder.m.ORG        2012-07-30 23:39:50.000000000 +0900
>>> +++ AQTPlotBuilder.m    2025-02-01 09:10:01.000000000 +0900
>>> @@ -149,7 +149,15 @@
>>>     // FIXME: Use AQTEqualColor instead
>>>     if ((newColor.red != _color.red) || (newColor.green != _color.green)
>>> || (newColor.blue != _color.blue) || (newColor.alpha != _color.alpha))
>>>     {
>>> +      int32_t count_save = _polylinePointCount;
>>>        [self _flushBuffers];
>>> +      if (count_save > 0) {
>>> +        // if color changes in the middle of polyline,
>>> +        // the last point of the path should be the
>>> +        // first point of the next path.
>>> +        _polylinePoints[0] = _polylinePoints[count_save - 1];
>>> +        _polylinePointCount = 1;
>>> +      }
>>>        _color = newColor;
>>>     }
>>>  }
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> gnuplot-beta mailing list
>>> gnu...@li...
>>> Membership management via:
>>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>>
>>

Re: AquaTerm (all solved)

[Erik L. <eri...@gm...>]

Here is a version for ARM-based Macs, probably requiring Sequoia 15.2 or
up:
https://pergamon.ms.northwestern.edu/Download/Gnuplot/aquaterm-1.1.1p1-arm64.pkg

On Sat, Feb 1, 2025 at 8:19 AM Erik Luijten <eri...@gm...> wrote:

> Hi Jun,
>
> Yes, that resolves the problem! How do we proceed? Ideally, this bugfix
> should be made in the distribution of AquaTerm. If this is hard, maybe I
> can distribute compiled AquaTerm packages for ARM and Intel as "1.1.1
> patchlevel 1" or so.
>
> By the way, I have not checked for any unintended side effects in AquaTerm.
>
> Best,
>
> Erik
>
> On Fri, Jan 31, 2025 at 7:06 PM Jun. T <tak...@kb...>
> wrote:
>
>>
>> > 2025/01/28 7:00, Ethan A Merritt <me...@uw...> wrote:
>> >
>> > Also, can someone now check whether Bug #1969 "Aquaterm: plot using
>> third column for color palette value loses every 2nd line" is still a
>> problem or can now be closed?   Maybe I should close it anyhow, since the
>> aquaterm project seems moribund.
>> >     https://sourceforge.net/p/gnuplot/bugs/1969/
>>
>>
>> > 2025/01/28 7:05、Erik Luijten <eri...@gm...>のメール:
>> >
>> > I just checked. The problem still exists (screenshots below). I know
>> nothing about AquaTerm, so cannot assist in resolving this, unfortunately.
>>
>> Could you please try the following patch when building AquaTerm.app?
>> (I hope it has no bad side effects.)
>>
>> Jun
>>
>>
>>
>> --- AQTPlotBuilder.m.ORG        2012-07-30 23:39:50.000000000 +0900
>> +++ AQTPlotBuilder.m    2025-02-01 09:10:01.000000000 +0900
>> @@ -149,7 +149,15 @@
>>     // FIXME: Use AQTEqualColor instead
>>     if ((newColor.red != _color.red) || (newColor.green != _color.green)
>> || (newColor.blue != _color.blue) || (newColor.alpha != _color.alpha))
>>     {
>> +      int32_t count_save = _polylinePointCount;
>>        [self _flushBuffers];
>> +      if (count_save > 0) {
>> +        // if color changes in the middle of polyline,
>> +        // the last point of the path should be the
>> +        // first point of the next path.
>> +        _polylinePoints[0] = _polylinePoints[count_save - 1];
>> +        _polylinePointCount = 1;
>> +      }
>>        _color = newColor;
>>     }
>>  }
>>
>>
>>
>>
>>
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> Membership management via:
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
>

Re: AquaTerm (all solved)

[Erik L. <eri...@gm...>]

Hi Jun,

Yes, that resolves the problem! How do we proceed? Ideally, this bugfix
should be made in the distribution of AquaTerm. If this is hard, maybe I
can distribute compiled AquaTerm packages for ARM and Intel as "1.1.1
patchlevel 1" or so.

By the way, I have not checked for any unintended side effects in AquaTerm.

Best,

Erik

On Fri, Jan 31, 2025 at 7:06 PM Jun. T <tak...@kb...> wrote:

>
> > 2025/01/28 7:00, Ethan A Merritt <me...@uw...> wrote:
> >
> > Also, can someone now check whether Bug #1969 "Aquaterm: plot using
> third column for color palette value loses every 2nd line" is still a
> problem or can now be closed?   Maybe I should close it anyhow, since the
> aquaterm project seems moribund.
> >     https://sourceforge.net/p/gnuplot/bugs/1969/
>
>
> > 2025/01/28 7:05、Erik Luijten <eri...@gm...>のメール:
> >
> > I just checked. The problem still exists (screenshots below). I know
> nothing about AquaTerm, so cannot assist in resolving this, unfortunately.
>
> Could you please try the following patch when building AquaTerm.app?
> (I hope it has no bad side effects.)
>
> Jun
>
>
>
> --- AQTPlotBuilder.m.ORG        2012-07-30 23:39:50.000000000 +0900
> +++ AQTPlotBuilder.m    2025-02-01 09:10:01.000000000 +0900
> @@ -149,7 +149,15 @@
>     // FIXME: Use AQTEqualColor instead
>     if ((newColor.red != _color.red) || (newColor.green != _color.green)
> || (newColor.blue != _color.blue) || (newColor.alpha != _color.alpha))
>     {
> +      int32_t count_save = _polylinePointCount;
>        [self _flushBuffers];
> +      if (count_save > 0) {
> +        // if color changes in the middle of polyline,
> +        // the last point of the path should be the
> +        // first point of the next path.
> +        _polylinePoints[0] = _polylinePoints[count_save - 1];
> +        _polylinePointCount = 1;
> +      }
>        _color = newColor;
>     }
>  }
>
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: AquaTerm (all solved)

[Jun. T <tak...@kb...>]

> 2025/01/28 7:00, Ethan A Merritt <me...@uw...> wrote:
> 
> Also, can someone now check whether Bug #1969 "Aquaterm: plot using third column for color palette value loses every 2nd line" is still a problem or can now be closed?   Maybe I should close it anyhow, since the aquaterm project seems moribund.
>     https://sourceforge.net/p/gnuplot/bugs/1969/


> 2025/01/28 7:05、Erik Luijten <eri...@gm...>のメール:
> 
> I just checked. The problem still exists (screenshots below). I know nothing about AquaTerm, so cannot assist in resolving this, unfortunately.

Could you please try the following patch when building AquaTerm.app?
(I hope it has no bad side effects.)

Jun



--- AQTPlotBuilder.m.ORG	2012-07-30 23:39:50.000000000 +0900
+++ AQTPlotBuilder.m	2025-02-01 09:10:01.000000000 +0900
@@ -149,7 +149,15 @@
    // FIXME: Use AQTEqualColor instead
    if ((newColor.red != _color.red) || (newColor.green != _color.green) || (newColor.blue != _color.blue) || (newColor.alpha != _color.alpha))
    {
+      int32_t count_save = _polylinePointCount;
       [self _flushBuffers];
+      if (count_save > 0) {
+        // if color changes in the middle of polyline,
+        // the last point of the path should be the
+        // first point of the next path.
+        _polylinePoints[0] = _polylinePoints[count_save - 1];
+        _polylinePointCount = 1;
+      }
       _color = newColor;
    }
 }

Re: AquaTerm (all solved)

[Jun. T <tak...@kb...>]

> 2025/01/28 6:28、Erik Luijten <eri...@gm...>のメール:
> 
> Final note (hopefully): The x86_64 (Intel) and arm64 versions of Gnuplot 6.0.2 with and without AquaTerm can now be downloaded from https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_macOS
> 
> Jun: If you have a chance, can you see if these work on your MacBook?

It works fine on my Intel-Mac (Ventura or Monterey).

On my Arm-Mac (Sequoia), your AquaTerm.app didn't start until I update
Sequoia from 15.0 to 15.3.

Re: AquaTerm (all solved)

[Ethan A M. <me...@uw...>]

On Mon, Jan 27, 2025 at 1:28 PM Erik Luijten <eri...@gm...> wrote:

> Final note (hopefully): The x86_64 (Intel) and arm64 versions of Gnuplot
> 6.0.2 with and without AquaTerm can now be downloaded from
> https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_macOS
> <https://urldefense.com/v3/__https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_macOS__;!!K-Hz7m0Vt54!k6_7v96XUB92jkWDkKn7vehA8FMRodGOU0ER4MD1hHKdxt9irpTWDGe5NE5VhDwt21gA25BtGS45ZIJ0Ib1p$>
>
> Jun: If you have a chance, can you see if these work on your MacBook?
>
> Kind regards,
>
> Erik
>

Also, can someone now check whether Bug #1969 "Aquaterm: plot using third
column for color palette value loses every 2nd line" is still a problem or
can now be closed?   Maybe I should close it anyhow, since the aquaterm
project seems moribund.
    https://sourceforge.net/p/gnuplot/bugs/1969/

  - Ethan

Re: AquaTerm (all solved)

[Erik L. <eri...@gm...>]

Final note (hopefully): The x86_64 (Intel) and arm64 versions of Gnuplot
6.0.2 with and without AquaTerm can now be downloaded from
https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_macOS

Jun: If you have a chance, can you see if these work on your MacBook?

Kind regards,

Erik

On Sun, Jan 26, 2025 at 3:59 PM Erik Luijten <eri...@gm...> wrote:

> Hi Ethan,
>
> The new configure script works correctly (at least on my ARM-based Mac
> running masOS 15.2 Sequioa); thank you.
>
> As for "-g": As long as it's a deliberate choice, I have no problem with
> it. (I thought this flag could interfere with optimization, but I realize
> now that this is not true; thus, the only difference is the size of the
> executable.)
>
> Erik
>
> On Sun, Jan 26, 2025 at 3:03 PM Ethan A Merritt <me...@uw...> wrote:
>
>> On Sunday, 26 January 2025 08:59:41 PST Erik Luijten wrote:
>> > Dear all,
>> >
>> > I apologize for the clutter on this mailing list, but to save others
>> work,
>> > I wanted to let you know that all AquaTerm issues listed in my email
>> from
>> > yesterday have been resolved:
>> >
>> > 1. Thanks to the MacPorts project, I figured out what patches are
>> needed to
>> > compile AquaTerm 1.1.1 on a current version of macOS.
>> >
>> > 2. Moreover, Ethan, I found out what needs to be changed in the Gnuplot
>> > configure script. Line 10668 needs to read:
>> >
>> > CFLAGS="$CFLAGS -ObjC"; LDFLAGS="$LDFLAGS -framework Foundation
>> -framework
>> > AquaTerm -F/Library/Frameworks"
>> >
>> > (the missing -F flag causes subsequent tests to go wrong)
>>
>> This is getting deep into the autoconf/packaging weeds.
>>
>> <begin weedy section>
>> The ./configure file is not a primary source;  it is produced by running
>> various
>> autoconf tools  (aclocal autoheader automake m4 ...) using the master
>> template
>> file configure.ac and the scripts in the subdirectory .../m4/
>> If you are starting from the files in the git repository (i.e. not from a
>> packaged tarball) this is done by running the script named "prepare"
>> which does all this magic and produces the ./configure script.
>>
>> I didn't write that prepare script and have only a superficial
>> understanding of
>> what all it is doing.  I can see that there is script in the m4 directory
>> .../m4/apple.m4 that is supposed to set the appropriate flags for
>> building on a Mac.
>> <end weedy section>
>>
>> I can tweak it, but I'll be working blind since I don't have a Mac to
>> test it on.
>> Please try the attached configure script (for 6.0.2) generated after
>> modifying
>> apple.m4
>>
>> >
>> > 3. I need to create an ARM package for AquaTerm and then I will provide
>> new
>> > packages on my Wiki page. Please allow a few days for me to finish this.
>> >
>> > Lastly, on a side note: I noticed that gnuplot on my machine always
>> builds
>> > with "-g -O2"; is this default on purpose? ("-g" seems undesirable for
>> > production builds)
>>
>> Why undesirable?
>> The advantage is that it allows people to provide more information in a
>> bug report.
>> As in "here's a backtrace I got for the segfault I'm reporting".
>> Is there a disadvantage?
>>
>>     Ethan
>
>

Re: AquaTerm (all solved)

[Erik L. <eri...@gm...>]

Hi Ethan,

The new configure script works correctly (at least on my ARM-based Mac
running masOS 15.2 Sequioa); thank you.

As for "-g": As long as it's a deliberate choice, I have no problem with
it. (I thought this flag could interfere with optimization, but I realize
now that this is not true; thus, the only difference is the size of the
executable.)

Erik

On Sun, Jan 26, 2025 at 3:03 PM Ethan A Merritt <me...@uw...> wrote:

> On Sunday, 26 January 2025 08:59:41 PST Erik Luijten wrote:
> > Dear all,
> >
> > I apologize for the clutter on this mailing list, but to save others
> work,
> > I wanted to let you know that all AquaTerm issues listed in my email from
> > yesterday have been resolved:
> >
> > 1. Thanks to the MacPorts project, I figured out what patches are needed
> to
> > compile AquaTerm 1.1.1 on a current version of macOS.
> >
> > 2. Moreover, Ethan, I found out what needs to be changed in the Gnuplot
> > configure script. Line 10668 needs to read:
> >
> > CFLAGS="$CFLAGS -ObjC"; LDFLAGS="$LDFLAGS -framework Foundation
> -framework
> > AquaTerm -F/Library/Frameworks"
> >
> > (the missing -F flag causes subsequent tests to go wrong)
>
> This is getting deep into the autoconf/packaging weeds.
>
> <begin weedy section>
> The ./configure file is not a primary source;  it is produced by running
> various
> autoconf tools  (aclocal autoheader automake m4 ...) using the master
> template
> file configure.ac and the scripts in the subdirectory .../m4/
> If you are starting from the files in the git repository (i.e. not from a
> packaged tarball) this is done by running the script named "prepare"
> which does all this magic and produces the ./configure script.
>
> I didn't write that prepare script and have only a superficial
> understanding of
> what all it is doing.  I can see that there is script in the m4 directory
> .../m4/apple.m4 that is supposed to set the appropriate flags for building
> on a Mac.
> <end weedy section>
>
> I can tweak it, but I'll be working blind since I don't have a Mac to test
> it on.
> Please try the attached configure script (for 6.0.2) generated after
> modifying
> apple.m4
>
> >
> > 3. I need to create an ARM package for AquaTerm and then I will provide
> new
> > packages on my Wiki page. Please allow a few days for me to finish this.
> >
> > Lastly, on a side note: I noticed that gnuplot on my machine always
> builds
> > with "-g -O2"; is this default on purpose? ("-g" seems undesirable for
> > production builds)
>
> Why undesirable?
> The advantage is that it allows people to provide more information in a
> bug report.
> As in "here's a backtrace I got for the segfault I'm reporting".
> Is there a disadvantage?
>
>     Ethan

AquaTerm (all solved)

[Erik L. <eri...@gm...>]

Dear all,

I apologize for the clutter on this mailing list, but to save others work,
I wanted to let you know that all AquaTerm issues listed in my email from
yesterday have been resolved:

1. Thanks to the MacPorts project, I figured out what patches are needed to
compile AquaTerm 1.1.1 on a current version of macOS.

2. Moreover, Ethan, I found out what needs to be changed in the Gnuplot
configure script. Line 10668 needs to read:

CFLAGS="$CFLAGS -ObjC"; LDFLAGS="$LDFLAGS -framework Foundation -framework
AquaTerm -F/Library/Frameworks"

(the missing -F flag causes subsequent tests to go wrong)

3. I need to create an ARM package for AquaTerm and then I will provide new
packages on my Wiki page. Please allow a few days for me to finish this.

Lastly, on a side note: I noticed that gnuplot on my machine always builds
with "-g -O2"; is this default on purpose? ("-g" seems undesirable for
production builds)

Erik

Gnuplot + aquaterm

[Erik L. <eri...@gm...>]

Hi (I took the liberty to change the subject),

Here is an update:

1. configuration with "--with-aquaterm" completely throws off the
compilation. I found that this is caused by a specific line in the
./configure script (line 10668 in Gnuplot 6.0.2):

    CFLAGS="$CFLAGS -ObjC"; LDFLAGS="$LDFLAGS -framework Foundation
-framework AquaTerm"

The LDFLAGS make the configure script subsequently fail finding various
libraries (GNU readline, etc.) and the configuration of the source code is
completely wrong (numerous error messages during compilation). The problem
occurs in 5.4.10 and 6.0.2, and both on my old Intel-based Mac running
macOS Catalina and my ARM-based Mac running macOS Sequioa. I do not
understand why this happens.


2. Despite the above, I was able to compile (by changing the configure
script) Gnuplot with AquaTerm. On the Intel machine, this was
straightforward using the precompiled AquaTerm package on sourceforge. The
compiled version of Gnuplot can also be run on an ARM Mac, via emulation.
On the other hand, attempting direct compilation of Gnuplot with aquaterm
on my ARM Mac caused a problem during linking, since the sourceforge
AquaTerm framework does not provide arm64 object code.



3. To circumvent this, I tried building AquaTerm on ARM using "xcodebuild
build"; however, this failed. I admittedly do not have the bandwidth to
sort this out; pointers would be very welcome! One problem is that "
Message/NSMailDelivery.h" is used, which has been deprecated by Apple. This
may be easy to address - I simply do not know.



4. I can confirm Jun's statement: Copy/Paste from an AquaTerm window yields
a scalable (vector) object. On the other hand, Copy/Paste from a wxt
terminal seems to be a bitmap.



So, as a brief summary:
- I can make available an x86_64 version of Gnuplot with aquaterm, which
will run on ARM machines as well (but not natively).
- I would much appreciate help in building AquaTerm (
https://sourceforge.net/projects/aquaterm/files/AquaTerm/v1.1.1/) on an
arm-based Mac.



Apologies for the long message!


Erik




On Fri, Jan 24, 2025 at 2:23 AM Jun T <tak...@kb...> wrote:

>
> > 2025/01/24 14:08、Ethan A Merritt <me...@uw...>のメール:
> >
> > The wxt and qt terminals can both dump PDF output of the plot currently
> > on the screen.  Is the issue that you would like it sent to a clipboard
> rather
> > than to a file?
>
> With wxt, you can copy the plot into the clipboard by pushing
> a button in the title bar of the wxt window.
> With qt, you can select the 'copy to clipboard' from the pull-down
> menu in the title bar of the qt window.
> But in both cases the plot is copied in bitmap format, not as
> vector graphics.
>
> On macOS with aquaterm, I can use the key combination Cmd-C
> to copy the plot to the clipboard in PDF format, and paste it into
> PowerPoint etc. by hitting Cmd-V.
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: New version for macOS

[Jun T <tak...@kb...>]

> 2025/01/24 14:08、Ethan A Merritt <me...@uw...>のメール:
> 
> The wxt and qt terminals can both dump PDF output of the plot currently
> on the screen.  Is the issue that you would like it sent to a clipboard rather
> than to a file?

With wxt, you can copy the plot into the clipboard by pushing
a button in the title bar of the wxt window.
With qt, you can select the 'copy to clipboard' from the pull-down
menu in the title bar of the qt window.
But in both cases the plot is copied in bitmap format, not as
vector graphics.

On macOS with aquaterm, I can use the key combination Cmd-C
to copy the plot to the clipboard in PDF format, and paste it into
PowerPoint etc. by hitting Cmd-V.

Re: New version for macOS

[Ethan A M. <me...@uw...>]

On Thursday, 23 January 2025 17:20:55 PST Jun T wrote:
> 
> > 2025/01/23 22:53、Erik Luijten <eri...@gm...>のメール:
> > 
> > I will see if I can get it to work, hopefully this weekend. 
> 
> Thanks. I hope it works.
> Which version of macOS are you using (on Intel Mac)?
> 
> > On a side note, you wrote "EPSF, or PDF as Apple calls it". However, EPSF = Encapsulated Postscript, which is closely related to PDF, but definitely not the same.
> 
> I've been thinking it is EPSF but Apple (wrongly) calls it PDF.
> But I looked into the actual content of the clipboard; it seems
> it is indeed PDF.

The wxt and qt terminals can both dump PDF output of the plot currently
on the screen.  Is the issue that you would like it sent to a clipboard rather
than to a file?   I don't know exactly what "clipboard" means on a Mac,
but if there is a standard way to paste things there maybe this is worth a
feature request for those other terminals.

  - Ethan

Re: New version for macOS

[Jun T <tak...@kb...>]

> 2025/01/23 22:53、Erik Luijten <eri...@gm...>のメール:
> 
> I will see if I can get it to work, hopefully this weekend. 

Thanks. I hope it works.
Which version of macOS are you using (on Intel Mac)?

> On a side note, you wrote "EPSF, or PDF as Apple calls it". However, EPSF = Encapsulated Postscript, which is closely related to PDF, but definitely not the same.

I've been thinking it is EPSF but Apple (wrongly) calls it PDF.
But I looked into the actual content of the clipboard; it seems
it is indeed PDF.

Re: New version for macOS

[Erik L. <eri...@gm...>]

Hi Jun,

I will see if I can get it to work, hopefully this weekend.

On a side note, you wrote "EPSF, or PDF as Apple calls it". However, EPSF =
Encapsulated Postscript, which is closely related to PDF, but definitely
not the same.

In any case, I'll keep you posted on aquaterm.

Erik



On Wed, Jan 22, 2025 at 9:44 PM Jun T <tak...@kb...> wrote:

>
> > 2025/01/23 7:52, Erik Luijten <eri...@gm...> wrote:
> >
> > I deliberately omitted aquaterm from my compiled version, since the
> project appears to be dormant (last change 2013, likewise for the mailing
> list) and the wxt terminal seems to work well. If there are reasons for me
> to reconsider, please let me know.
>
> Aauaterm works fine on macOS 13 Ventura. My Intel Mac
> is rather old (2017 iMac) and can't test on the newer macOS
> (14 Sonoma, 15 Sequoia). Can anyone test on these OSes?
>
> If aquaterm works on Sonoma/Sequoia I think it would be
> useful to include it since quaterm is the only terminal that
> can copy a plot into clipboard in vector format (EPSF, or
> PDF as Apple calls it).
>
> This is quite useful if you want to copy/paste the plot
> into Keynote, PowerPoint etc. (with wxt terminal we need
> to save the plot in .pdf file and then include the file into
> the presentation etc.).
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: New version for macOS

[Jun T <tak...@kb...>]

> 2025/01/23 7:52, Erik Luijten <eri...@gm...> wrote:
> 
> I deliberately omitted aquaterm from my compiled version, since the project appears to be dormant (last change 2013, likewise for the mailing list) and the wxt terminal seems to work well. If there are reasons for me to reconsider, please let me know.

Aauaterm works fine on macOS 13 Ventura. My Intel Mac
is rather old (2017 iMac) and can't test on the newer macOS
(14 Sonoma, 15 Sequoia). Can anyone test on these OSes?

If aquaterm works on Sonoma/Sequoia I think it would be
useful to include it since quaterm is the only terminal that
can copy a plot into clipboard in vector format (EPSF, or
PDF as Apple calls it).

This is quite useful if you want to copy/paste the plot
into Keynote, PowerPoint etc. (with wxt terminal we need
to save the plot in .pdf file and then include the file into
the presentation etc.).