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

Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

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

On 01/04/2012 04:46 PM, Mojca Miklavec wrote:
> On Wed, Jan 4, 2012 at 23:09, Ethan A Merritt wrote:
>> Mojca Miklavec wrote>
>>
>>> There are at least the following issues:
>>> - configure script is unable to find Qt
>>
>> It uses pkg-config.  If your Qt installation does not come with a set of
>> *.pc files then the configuration script will not work.
>
> Even if it would come with *.pc scripts, Mac OS X doesn't ship
> pkg-config by default, so it would be useless.
>
> But the good news is that it is installed at a default location (with
> default binary installer) and many programs, like Geant4 for example,
> take this into account.
>
> Again, I don't know how to use autotools, but the algorithm is simple enough:
> - check if pkg-config finds Qt
> - if not, check if flags that I mentioned work fine
>
>>> - MOC and UIC are set to an empty string; here "moc" and "uic"
>>> commands work fine, but I don't know why configure script doesn't find
>>> them
>>
>> Because it queries pkg-config to find out where they are.
>>    MOC=`pkg-config --variable=moc_location QtCore`
>>
>> By the way, what version of Qt are you trying to use?
>
> I just realized that I had no Qt installed at all (I only had
> developer tools which are installed at some weird location), so I
> installed the latest version, 4.8.0, but I don't think that it really
> matters. I was testing it long ago (around July when 4.8.0 wasn't
> available yet, see "Any chance to fix gnuplot on mac?" thread, but
> there was some additional private conversation with Jérôme Lodewyck
> who helped me solve some issues) with exactly the same outcome.
>
> If needed, I can probably figure out how to uninstall 4.8.0 and
> install 4.7.*, but that won't help solve the two problems with
> compiling (and last time when I tried it there were exactly the same
> problems with running it).
>
>> I've just been debugging configuration problems with Qt 4.7.4, where it turns
>> out that I need to do the same thing in order to pick up locations for
>> the rcc and lrelease utilities.
>>
>>> - if I fix the two above, qt terminal compiles fine, but I cannot plot anything:
>>>
>>> gnuplot>  plot sin(x)
>>> The process has forked and you cannot use this CoreFoundation
>>> functionality safely. You MUST exec().
>>> Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
>>> to debug.
>>
>> No idea what that's about. It is clearly some OSX weirdness.
>> Googling that error message turns up this totally bizarre advice:

The SMB probably means Samba server, which is a Windows emulation thing, 
I think.  This is probably just a consequence of the change that Mojca 
has found below.


> Last time I didn't find anything useful either. However google now
> pointed me to the following:
>
> http://gitorious.org/~friesoft/dinjam/friesoft-development/blobs/master/src/sources/data/standarddirs_mac.cpp
>
> /**
>   Calling CoreFoundation APIs (which is unavoidable in Qt/Mac) has
> always had issues
>   on Mac OS X, but as of 10.5 is explicitly disallowed with an exception.  As a
>   result, in the case where we would normally fork and then dlopen
> code, or continue
>   to run other code, we must now fork-and-exec.

So what you are seeing is the exception that OS X is now throwing when 
it sees you fork() and then not exec(), apparently.  My guess is this 
might be a security measure in some way.  (How?  I don't know, just 
guessing.)


> I would be willing to debug, but I have no idea how to do so. I
> created a ticket:
>      https://sourceforge.net/tracker/?func=detail&aid=3469233&group_id=2055&atid=102055
> where I attached crash report (I just realized where systems stores
> crash reports) if that is of any help, but I'm not sure neither how to
> debug nor how to fix anything.
>
> If you tell me how exactly to "exec()" after fork in qt_term.cpp, I
> can test it, but I don't fully understand the code, so I'm not sure
> what exactly to change and how.

It appears that the fork() is in the qt_init() routine:

236        pid = fork();
237	        if (pid < 0)
238	                fprintf(stderr, "Forking error\n");
239	        else if (pid == 0) // Child: start the GUI
240	        {
241	                signal(SIGINT, SIG_IGN); // Do not listen to SIGINT 
signals anymore
242	
243	#ifndef HAVE_QT_47
244	                /*
245	                 * FIXME: EAM Nov 2011
246	                 * It is better to use environmental variable
247	                 * QT_GRAPHICSSYSTEM but this requires qt >= 4.7
248	                 * "raster" is ~5x faster than "native" (default).
249	                 * Unfortunately "opengl" isn't recognized on my 
test systems :-(
250	                 */
251	                // This makes a huge difference to the speed of 
polygon rendering.
252	                // Alternatives are "native", "raster", "opengl"
253	                QApplication::setGraphicsSystem("raster");
254	#endif
255	
256	                QtGnuplotApplication application(argc, (char**)( NULL));


> It is pretty clear that problems start at this line in qt_term.cpp:
>      QtGnuplotApplication application(argc, (char**)( NULL));
> but after this line gets executed, I cannot even printf (whatever I
> put into print, it doesn't get displayed until something semi-crashes
> and printf sometimes starts working afer QApplication* application =
> new QApplication(argc, (char**)( NULL)); again).

I would guess that the line Ethan conditioned isn't active when you 
compile.  That leaves "signal(SIGINT, SIG_IGN);" as the first line after 
the fork, and that is probably a CoreFunction routine itself so doesn't 
throw the exception or odd behavior.  Thus "QtGnuplotApplication 
application(argc, (char**)( NULL));" is the first line of code to follow 
the fork and probably throws the exception.  According to what you have 
found exec() should nearly follow fork() and you can't have all that 
code in between.  Thus as a first test, perhaps try moving the fork 
before the exec(), e.g.,

#ifndef HAVE_QT_47
                 /*
                  * FIXME: EAM Nov 2011
                  * It is better to use environmental variable
                  * QT_GRAPHICSSYSTEM but this requires qt >= 4.7
                  * "raster" is ~5x faster than "native" (default).
                  * Unfortunately "opengl" isn't recognized on my test 
systems :-(
                  */
                 // This makes a huge difference to the speed of polygon 
rendering.
                 // Alternatives are "native", "raster", "opengl"
                 QApplication::setGraphicsSystem("raster");
#endif

                 QtGnuplotApplication application(argc, (char**)( NULL));

                 // Make sure the forked copy doesn't trash the history 
file
                 cancel_history();

                 // Load translations for the qt library
                 QTranslator qtTranslator;
                 qtTranslator.load("qt_" + QLocale::system().name(), 
QLibraryInfo::location(QLibraryInfo::TranslationsPath));
                 application.installTranslator(&qtTranslator);

                 // Load translations for the qt terminal
                 QTranslator translator;
                 translator.load("qtgnuplot_" + 
QLocale::system().name(), QTGNUPLOT_DATA_DIR);
                 application.installTranslator(&translator);

	        pid = fork();

	        if (pid < 0)
	                fprintf(stderr, "Forking error\n");
	        else if (pid == 0) // Child: start the GUI
	        {
	                signal(SIGINT, SIG_IGN); // Do not listen to SIGINT 
signals anymore
	                // Start
	                application.exec();
	                exit(0);
	        }


That may fail because of dependence on the fork() being called before 
some of those other routines, but it's a start.  (If it fails, try 
moving the application.exec() up near the fork, but you'll have to leave 
behind the exit(0) otherwise the translations will be missing.)

Dan

Re: Qt on Mac (no such luck, apparently)

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

Mojca Miklavec <moj...@gm...> wrote >
> > sfeam wrote>
> > Do you have a set of instructions we could include with 4.6 that tells
> > people where/how to get a version of aquaterm compatible with current
> > OSX and gnuplot?
> 
> The latest released version of AquaTerm is compatible with Mac OS X
> 10.4-10.7 (and probably later), with PowerPC, i386 and x86_64, so that
> should be no problem.

Aha. So I'm glad I asked for instructions.

The information on the Aquaterm SourceForge page is different from what
you give above.  There it says Aquaterm 1.1 is x86 only, and only tested
on 10.5 and 10.6.  The previous version (Aquaterm 1.0.1) works on PPC under
10.5 and I can't quite figure out what it is saying about OSX 10.1 to 10.4.

So is the information on the SourceForge page out of date,
or is there another place to pull it from, or what?

	Ethan

Re: Getting ready to put out a 4.6 release candidate

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

Hello

--- On Thu, 2012/1/5, Ethan A Merritt  wrote:

> Tatsuro MATSUOKA 
> > Hello
> > 
> > In my opinion, the windows binary distribution is better to done in installer style for gnuplot-4.6.
> > Therefore change for installer is better to be included in the mingw/Makefile for 4.6.
> > 
> > Ethan and Bastian
> > How do you think?
> 
> Fine with me.  
> It just went into 4.5 CVS very recently, right?   
You are right.

> Have there been any user reports to indicate how many people have
> successfully used it?
There have been no reports binaries in installer style.
If you do not want hurry about this matter, the distribution of 4.6.0 will be done in zip style and the distribution of 4.6.1 will be changed to installer style.

Regards

Tatsuro
>     Ethan
> 

Re: Qt on Mac (no such luck, apparently)

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

(Why was the email sent under my name and not under Ethan's?)

On Thu, Jan 5, 2012 at 00:26, Mojca Miklavec wrote:
>
>> http://gitorious.org/~friesoft/dinjam/friesoft-development/blobs/master/src/sources/data/standarddirs_mac.cpp
>>
>> /**
>>  Calling CoreFoundation APIs (which is unavoidable in Qt/Mac) has always had issues
>>  on Mac OS X, but as of 10.5 is explicitly disallowed with an exception.  As a
>>  result, in the case where we would normally fork and then dlopen code, or continue
>>  to run other code, we must now fork-and-exec.
>>
>>
>> I would be willing to debug, but I have no idea how to do so. I
>> created a ticket:
>>     https://sourceforge.net/tracker/?func=detail&aid=3469233&group_id=2055&atid=102055
>> where I attached crash report (I just realized where systems stores
>> crash reports) if that is of any help, but I'm not sure neither how to
>> debug nor how to fix anything.
>>
>> If you tell me how exactly to "exec()" after fork in qt_term.cpp, I
>> can test it, but I don't fully understand the code, so I'm not sure
>> what exactly to change and how.
>
> That's not how it works.  When you call exec() you are basically running
> a new program.  In order to create a suitable program to run, you would have
> to re-write gnuplot so that there is a separate entry path that starts up
> directly  in the state you want the separate process to be in.  Then you
> would have to re-write (I think) the communication channel between the
> original process and the new one so that the drawing commands are passed
> through in one direction and the mousing info is passed back in the other.
>
> At one point Timothée Lecomte was working on something like that for the
> wxt terminal, as another path towards getting it working under OSX.
> It is patchset #1950392 on the SourceForge tracker.
> In the end it turned out not to be necessary.
>
> Alternatively you could use gnuplot(x11.trm) + gnuplot_x11(gplt_x11.c)
> as a model. That is, create two separate programs rather than one program
> with two executaion paths.

I have no idea how communication in gnuplot works at all, so I find it
hard to comment on any of that.

> Either approach is way more complicated that just adding a few lines to
> the existing code.  It seems more reasonable simply to document that the
> qt terminal is not available under OSX.
>
> What ever happened to your efforts to get aquaterm working again?

AquaTerm works. (OK, mouse events are not implemented and there is
still a tiny unresolved bug which makes it impossible to link against
one version and use another one, but as long as a single version
exists, it should work fine.) The only problem is that gnuplot doesn't
properly handle the flags for building. It should test whether
"-framework AquaTerm" works and use that flag, but uses -laquaterm
instead. But I don't know autotools, so I don't know how to fix this.
It is a simple fix in ./configure script, but since ./configure script
is generated, just replacing
    LIBS="-laquaterm ...
with
    LIBS="-framework AquaTerm
in apple.m4 won't work since another "-laquaterm" gets generated
automatically with
    AC_CHECK_LIB(aquaterm, aqtInit,
This means that somebody should write a macro "AC_CHECK_FRAMEWORK" to
do it properly. Or maybe switch to CMake which would probably be a lot
better in the long run.

Still, if a symlink from libaquaterm.dylib to
/Library/Frameworks/AquaTerm.framework/AquaTerm exists on computer,
-laquaterm will work. But if it doesn't, it won't work without
modifications. Also, if one only installs AquaTerm with MacPorts,
gnuplot won't find it (even though it will find all other libraries
installed with MacPorts). So at the moment there is no reason to claim
that AquaTerm doesn't work on Mac.

(I have a serious problem making it work in Octave, but that's a
separate issue.)

> Do you have a set of instructions we could include with 4.6 that tells
> people where/how to get a version of aquaterm compatible with current
> OSX and gnuplot?

The latest released version of AquaTerm *is* compatible with Mac OS X
10.4-10.7 (and probably later), with PowerPC, i386 and x86_64, so that
should be no problem.

> As with qt, if this isn't really an option perhaps
> we should simply document that aquaterm is not supported under
> [OSX 10.6?  64-bit?  I kind of lost track of where the limitation
> entered].

For a long time AquaTerm didn't work on x86_64 (the binaries for
x86_64 weren't released and sources didn't compile without changing
project files). Now it works. But configuration in gnuplot is somewhat
unfortunate and often doesn't work as it should.

(Also: AquaTerm has a nasty "feature" that gnuplot will link against
one version, and when called, it will use the first one that the
system finds. If more incompatible versions are installed, this may
lead to problems. AquaTerm versions have always been compatible with
each other, but the 64 against 32-bits cause mysterious problems when
passing arguments in function calls. Environmental variables may
influence the behaviour, but it is still a bit problematic.
Nevertheless, at least it works.)

Mojca

Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

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

On Wed, Jan 4, 2012 at 23:09, Ethan A Merritt wrote:
> Mojca Miklavec wrote >
>
>> There are at least the following issues:
>> - configure script is unable to find Qt
>
> It uses pkg-config.  If your Qt installation does not come with a set of
> *.pc files then the configuration script will not work.

Even if it would come with *.pc scripts, Mac OS X doesn't ship
pkg-config by default, so it would be useless.

But the good news is that it is installed at a default location (with
default binary installer) and many programs, like Geant4 for example,
take this into account.

Again, I don't know how to use autotools, but the algorithm is simple enough:
- check if pkg-config finds Qt
- if not, check if flags that I mentioned work fine

>> - MOC and UIC are set to an empty string; here "moc" and "uic"
>> commands work fine, but I don't know why configure script doesn't find
>> them
>
> Because it queries pkg-config to find out where they are.
>   MOC=`pkg-config --variable=moc_location QtCore`
>
> By the way, what version of Qt are you trying to use?

I just realized that I had no Qt installed at all (I only had
developer tools which are installed at some weird location), so I
installed the latest version, 4.8.0, but I don't think that it really
matters. I was testing it long ago (around July when 4.8.0 wasn't
available yet, see "Any chance to fix gnuplot on mac?" thread, but
there was some additional private conversation with Jérôme Lodewyck
who helped me solve some issues) with exactly the same outcome.

If needed, I can probably figure out how to uninstall 4.8.0 and
install 4.7.*, but that won't help solve the two problems with
compiling (and last time when I tried it there were exactly the same
problems with running it).

> I've just been debugging configuration problems with Qt 4.7.4, where it turns
> out that I need to do the same thing in order to pick up locations for
> the rcc and lrelease utilities.
>
>> - if I fix the two above, qt terminal compiles fine, but I cannot plot anything:
>>
>> gnuplot> plot sin(x)
>> The process has forked and you cannot use this CoreFoundation
>> functionality safely. You MUST exec().
>> Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
>> to debug.
>
> No idea what that's about. It is clearly some OSX weirdness.
> Googling that error message turns up this totally bizarre advice:

Last time I didn't find anything useful either. However google now
pointed me to the following:

http://gitorious.org/~friesoft/dinjam/friesoft-development/blobs/master/src/sources/data/standarddirs_mac.cpp

/**
 Calling CoreFoundation APIs (which is unavoidable in Qt/Mac) has
always had issues
 on Mac OS X, but as of 10.5 is explicitly disallowed with an exception.  As a
 result, in the case where we would normally fork and then dlopen
code, or continue
 to run other code, we must now fork-and-exec.

 See "CoreFoundation and fork()" at
http://developer.apple.com/releasenotes/CoreFoundation/CoreFoundation.html
*/

(The link is not particularly useful since it now points to Release
Notes of 10.7 instead of 10.5.)

or

http://stackoverflow.com/questions/3835247/do-work-out-of-process-in-a-cocoa-app

I would be willing to debug, but I have no idea how to do so. I
created a ticket:
    https://sourceforge.net/tracker/?func=detail&aid=3469233&group_id=2055&atid=102055
where I attached crash report (I just realized where systems stores
crash reports) if that is of any help, but I'm not sure neither how to
debug nor how to fix anything.

If you tell me how exactly to "exec()" after fork in qt_term.cpp, I
can test it, but I don't fully understand the code, so I'm not sure
what exactly to change and how.

It is pretty clear that problems start at this line in qt_term.cpp:
    QtGnuplotApplication application(argc, (char**)( NULL));
but after this line gets executed, I cannot even printf (whatever I
put into print, it doesn't get displayed until something semi-crashes
and printf sometimes starts working afer QApplication* application =
new QApplication(argc, (char**)( NULL)); again).

Mojca

Re: Getting ready to put out a 4.6 release candidate

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

Tatsuro MATSUOKA <tma...@ya...> wrote >
> Hello
> 
> In my opinion, the windows binary distribution is better to done in installer style for gnuplot-4.6.
> Therefore change for installer is better to be included in the mingw/Makefile for 4.6.
> 
> Ethan and Bastian
> How do you think?

Fine with me.  
It just went into 4.5 CVS very recently, right?   
Have there been any user reports to indicate how many people have
successfully used it?

	Ethan

Re: Getting ready to put out a 4.6 release candidate

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

Mojca Miklavec <moj...@gm...> wrote >
 
> Qt terminal doesn't work on Mac OS X, but I don't know if you plan to
> fix this before 4.6 on not.

Not me :-)  I think we have established very well that people here are not
up to the task of configuring support for new options under OSX.

> There are at least the following issues:
> - configure script is unable to find Qt 

It uses pkg-config.  If your Qt installation does not come with a set of
*.pc files then the configuration script will not work.

> - MOC and UIC are set to an empty string; here "moc" and "uic"
> commands work fine, but I don't know why configure script doesn't find
> them

Because it queries pkg-config to find out where they are.
   MOC=`pkg-config --variable=moc_location QtCore`

By the way, what version of Qt are you trying to use?
I've just been debugging configuration problems with Qt 4.7.4, where it turns
out that I need to do the same thing in order to pick up locations for
the rcc and lrelease utilities.

> - if I fix the two above, qt terminal compiles fine, but I cannot plot anything:
>
> gnuplot> plot sin(x)
> The process has forked and you cannot use this CoreFoundation
> functionality safely. You MUST exec().
> Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
> to debug.

No idea what that's about. It is clearly some OSX weirdness.
Googling that error message turns up this totally bizarre advice:

  In Server Admin stop SMB, remove it from services (save), re-add it (save), then start SMB.

In other words, people seem to have gotten this error message as a side effect of
the network/SMB configuration.

	Ethan

Re: Getting ready to put out a 4.6 release candidate

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

Hello

In my opinion, the windows binary distribution is better to done in installer style for gnuplot-4.6.
Therefore change for installer is better to be included in the mingw/Makefile for 4.6.

Ethan and Bastian
How do you think?

Regards

Tatsuro

--- On Wed, 2012/1/4, Tatsuro MATSUOKA  wrote:

> Hello
> 
> Please discuss the below for windows distribution,
> contents of docs directory in windows binaries
> http://news.gmane.org/gmane.comp.graphics.gnuplot.devel
> 
> Regards
> 
> Tatsuro
> 
> 
> --- On Tue, 2012/1/3, sfeam (Ethan Merritt) wrote:
> 
> > Over the holidays I resolved several long-standing bugs related to 
> > the helper threads forked by the wxt and qt terminals.
> > This should take care of reported problems with zombie processes,
> > truncated history files, and program failures if mouse and keyboard
> > events arrive out of the expected order.  The qt terminal is now
> > acting very reliably for me under linux, which is a big improvement.
> > 
> > So my list of must-fix-for-4.6 items is now empty.
> > 
> > Does anyone know of issues that should be addressed before putting 
> > out a version 4.6.rc1 release candidate?
> > 
> > You can have a look at a draft announcement on the News section of
> > the gnuplot home page.
> > 
> >         Happy New Year!
> > 
> >             Ethan
> > 
> > ------------------------------------------------------------------------------
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development. Create 
> > new or port existing apps to sell to consumers worldwide. Explore the 
> > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> > http://p.sf.net/sfu/intel-appdev
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create 
> new or port existing apps to sell to consumers worldwide. Explore the 
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Getting ready to put out a 4.6 release candidate

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

Hello

Please discuss the below for windows distribution,
contents of docs directory in windows binaries
http://news.gmane.org/gmane.comp.graphics.gnuplot.devel

Regards

Tatsuro


--- On Tue, 2012/1/3, sfeam (Ethan Merritt) wrote:

> Over the holidays I resolved several long-standing bugs related to 
> the helper threads forked by the wxt and qt terminals.
> This should take care of reported problems with zombie processes,
> truncated history files, and program failures if mouse and keyboard
> events arrive out of the expected order.  The qt terminal is now
> acting very reliably for me under linux, which is a big improvement.
> 
> So my list of must-fix-for-4.6 items is now empty.
> 
> Does anyone know of issues that should be addressed before putting 
> out a version 4.6.rc1 release candidate?
> 
> You can have a look at a draft announcement on the News section of
> the gnuplot home page.
> 
>         Happy New Year!
> 
>             Ethan
> 
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create 
> new or port existing apps to sell to consumers worldwide. Explore the 
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Getting ready to put out a 4.6 release candidate

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

On Tue, Jan 3, 2012 at 01:32, sfeam (Ethan Merritt) wrote:
>
> So my list of must-fix-for-4.6 items is now empty.
>
> Does anyone know of issues that should be addressed before putting
> out a version 4.6.rc1 release candidate?

Qt terminal doesn't work on Mac OS X, but I don't know if you plan to
fix this before 4.6 on not.

There are at least the following issues:
- configure script is unable to find Qt (it should be easy enough to
check for at least one more default location; I don't know how to work
with autotools, but I can tell which flags are needed)
- MOC and UIC are set to an empty string; here "moc" and "uic"
commands work fine, but I don't know why configure script doesn't find
them
- if I fix the two above, qt terminal compiles fine, but I cannot plot anything:


Terminal type set to 'qt'
gnuplot> plot sin(x)
The process has forked and you cannot use this CoreFoundation
functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
to debug.
The process has forked and you cannot use this CoreFoundation
functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
to debug.
The process has forked and you cannot use this CoreFoundation
functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
to debug.
The process has forked and you cannot use this CoreFoundation
functionality safely. You MUST exec().
/.../
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
to debug.

(I'm willing to provide information and test, but I don't know how to
write patches for configure scripts.)

Mojca

Getting ready to put out a 4.6 release candidate

[sfeam (E. Merritt) <eam...@gm...>]

Over the holidays I resolved several long-standing bugs related to 
the helper threads forked by the wxt and qt terminals.
This should take care of reported problems with zombie processes,
truncated history files, and program failures if mouse and keyboard
events arrive out of the expected order.  The qt terminal is now
acting very reliably for me under linux, which is a big improvement.

So my list of must-fix-for-4.6 items is now empty.

Does anyone know of issues that should be addressed before putting 
out a version 4.6.rc1 release candidate?

You can have a look at a draft announcement on the News section of
the gnuplot home page.

		Happy New Year!

			Ethan

y2 stuck upside down

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

HI,

I accidentally entered a y2r with end smaller than start (slip on 
decimal point)

set y2r [0.6:.24]

  it plotted but inverted the axis. So I corrected the typo and loaded 
the script again from the gnuplot command prompt as before

set y2r [0.6:2.4]

I now get the new scale but still upside down !

It seems the erroneous range automatically set some kind of flip bit but 
when I now set the correct scale this automatic magic is not smart 
enough to revert it.

neither does resetting y2r to auto free it up
  set y2r [*:*]

I had to quit gnuplot to get back to normal scaling behaviour.

  G N U P L O T
         Version 4.5 patchlevel 0
         last modified November 2011


regards. Peter.

Re: contents of docs directory in windows binaries

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

Hello
> My preference is old style contents in docs directory.
gpcard.pdf seems to be out dated so that it might be omitted.

BTW, tutorial.pdf can be made with out .prepare and .configure,

gnuplot eg1.plt
gnuplot eg2.plt
gnuplot eg3.plt
gnuplot eg4.plt
gnuplot eg5.plt
gnuplot eg6.plt
gnuplot eg7.plt
gnuplot linepoin.plt
gnuplot test.plt
gnuplot test_tikz.plt
latex tutorial.tex
dvips tutorial.dvi
ps2pdf tutorial.ps tutorial.pdf

Regards

Anyway at the moment, I will distribute current omitted old doc files separately from installer.

Tatsuro
--- On Sat, 2011/12/24, Tatsuro MATSUOKA  wrote:

> Hello
> 
> Thanks to grate efforts by Bastian Maerkisch, I could make windows cvs binary with installer.
> 
> Seeing the contents made by config/mingw/Makefile, contents of docs directory is changed.
> The windows binaries so far have the following in docs directory,
> 
> docs
>   FAQ.pdf
>   gnuplot.pdf
>   gpcard.pdf 
> docs/postscript-terminal
>   ps_file.doc
>   ps_fontfile_doc.tex
>   ps_fontfile_doc.zip
>   ps_guide.ps
>   ps_symbols.gp
>   ps_symbols.gpi
>   ps_symbols.ps
>   README
> 
> docs/tutorial
>   tutorial.pdf
>   README
> 
> In new docs directory, I found
>  BUGS
>  ChangeLog
>  gnuplot.pdf
>  README
> 
> ******************
> My preference is old style contents in docs directory.
> 
> I think that it is better to discuss the contents in docs for windows binaries.
> 
> Regards
> 
> Tatsuro
> 
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create 
> new or port existing apps to sell to consumers worldwide. Explore the 
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

contents of docs directory in windows binaries

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

Hello

Thanks to grate efforts by Bastian Maerkisch, I could make windows cvs binary with installer.

Seeing the contents made by config/mingw/Makefile, contents of docs directory is changed.
The windows binaries so far have the following in docs directory,

docs
  FAQ.pdf
  gnuplot.pdf
  gpcard.pdf 
docs/postscript-terminal
  ps_file.doc
  ps_fontfile_doc.tex
  ps_fontfile_doc.zip
  ps_guide.ps
  ps_symbols.gp
  ps_symbols.gpi
  ps_symbols.ps
  README

docs/tutorial
  tutorial.pdf
  README

In new docs directory, I found
 BUGS
 ChangeLog
 gnuplot.pdf
 README

******************
My preference is old style contents in docs directory.

I think that it is better to discuss the contents in docs for windows binaries.

Regards

Tatsuro

Re: what should monochrome option do exactly?

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

On 12/14/2011 04:27 PM, Daniel J Sebald wrote:

> http://akvis.com/en/coloriage-tutorial/examples/sepia-photo.php

Actually, reading this whole tutorial is useful as J.C.G. addresses all 
the things we've discussed, e.g., first creating a b&w image from a 
color image (otherwise skip those steps) and messing around with 
hue/saturation to adjust the sepia appearance.

Dan

Re: what should monochrome option do exactly?

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

On 12/14/2011 03:45 PM, Tait wrote:
>> set term foo monochrome (1,0.8,0.5)
>> set term foo monochrome red
>>     [above is equivalent to "set term foo monochrome (1,0,0)"]
>> set term foo monochrome sepia
>>
>> Thoughts?
>
> My first thoughts are, "is that useful?" "is it necessary?"

Don't know.  Could be to a small percentage of people, but if it is an 
easily implemented thing then perhaps it is worth making the feature 
available.  I searched for some examples of sepia tone.  Here are a few:

http://akvis.com/en/coloriage-tutorial/examples/sepia-photo.php
http://www.pxleyes.com/photography-picture/4bb664349c057/Civita.html
http://www.eltonography.com/albums/STANDARD/TCONN.html

My point is that I would call the above monochrome, but not greyscale.


> But if we do go that route, I see no reason to limit the possibilities
> to a linear arithmetic weighted average. If one wants a nonlinear
> dependence on one or more of the color channels, the more general
> solution would be something like "set term foo monochrom using
> ((2.0*$1**2+$2+$3)/(2*255**2+2*255))" or replace 255 with 1.0 if we're
> using a 0-1.0 scale instead of 0-255. I am assuming $1, $2, $3 are red,
> green, blue respectively.

Actually, what you are describing is something different.  I was 
describing the monochrome scale; you are describing the input mapping. 
Let's see if I can draw a little I/O diagram:

                ------------                   ----------
RGB values     | I(R,G,B) |                   |a_r*mono|--> R
    or       -->|   or     |--> mono values -->|a_g*mono|--> G
Mono values    |no mapping|                   |a_b*mono|--> B
                ------------                   ----------

The formula you have given would be I(R,G,B) in the above diagram. 
(a_r,a_g,a_b) are the weighting parameters that I was describing.  And 
for greyscale, a_r=1, a_g=1, a_b=1.  I think, and I may be wrong, that 
currently one could apply the formula you are describing at the point of 
reading data from an image file.  Manipulating a_r, a_g, a_b would be 
possible as well, but with slightly more complex manipulations of input 
data.

Dan

Re: what should monochrome option do exactly?

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

> set term foo monochrome (1,0.8,0.5)
> set term foo monochrome red
>    [above is equivalent to "set term foo monochrome (1,0,0)"]
> set term foo monochrome sepia
>
> Thoughts?

My first thoughts are, "is that useful?" "is it necessary?"

But if we do go that route, I see no reason to limit the possibilities
to a linear arithmetic weighted average. If one wants a nonlinear
dependence on one or more of the color channels, the more general
solution would be something like "set term foo monochrom using
((2.0*$1**2+$2+$3)/(2*255**2+2*255))" or replace 255 with 1.0 if we're
using a 0-1.0 scale instead of 0-255. I am assuming $1, $2, $3 are red,
green, blue respectively.

Re: what should monochrome option do exactly?

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

On 12/13/2011 06:37 PM, Mojca Miklavec wrote:
> On Tue, Dec 13, 2011 at 23:32, Ethan A Merritt wrote:
>> On Tuesday, December 13, 2011 02:19:58 pm Mojca Miklavec wrote:
>>> Hello,
>>>
>>> I just remembered that implementation of monochrome option in context
>>> terminal is slightly suboptimal (in standalone mode it lets TeX do
>>> color conversion into gray scale as "rgb2gray").
>>>
>>> I should probably fix that, but I'm not sure what exactly to do:
>>> should I simply make all the colors black or should I use different
>>> shades of gray, and in the second case - which colors exactly?
>>
>> In my opinion, which may not be universally shared,
>> 'set term foo monochrome' should cause it to choose a default palette
>> in shades of grey, and a default set of lines that are not colored.
>
> On the other hand, mochrome means "mono" (= single color).
> I understand the second. The colors lc 1, lc 2, ... should be gray,
> except that I would be grateful for some proposal of which shades of
> gray exactly.

What object is it exactly that the monochrome qualifier refers to? 
Lines, images, symbols?  All of the above?

Monochrome means as you say, a single color or point on the chromatic 
scale.  However, I'd say that greyscale is a special type of monochrome. 
  The thing that varies in monochrome is the intensity of the light 
source (i.e., pixel) while the color components remain fixed, relatively 
speaking.  Greyscale is a monochrome in which all primary components are 
weighted equally.  However, one could create a monochrome image where 
the color components (RGB) are not weighted equally.  Examples of this 
would be well known historic photographic prints that, for example, have 
a sepia tone.

So with the "monochrome" option, I'd suggest a second qualifier option 
which is the RGB components.  (We must have a standard way of expressing 
RGB by now.  Names might work too.)  For example,

set term foo monochrome (1,0.8,0.5)
set term foo monochrome red
   [above is equivalent to "set term foo monochrome (1,0,0)"]
set term foo monochrome sepia

Thoughts?


> But what exactly is meant with default palette? PM3D? But how can a
> terminal influence the choice of palette formulas?
>
>> But it should not prevent the user from drawing explicitly in whatever
>> color they like, and it should not prevent the user from selecting a
>> color palette later.
>
> What exactly do you mean with selecting a color palette? (Probably the
> same question as earlier.)

Color palette is different from monochrome and different from RGB. 
Palette is a series of colors acting as a look-up-table for various 
values.  Give the LUT a value of 3 and it returns a triple representing 
the RGB values.  The palette can be asigned vary strange color 
combinations to create various effects, e.g., weather map, cartography, 
so on.

Dan

Re: what should monochrome option do exactly?

[sfeam (E. Merritt) <eam...@gm...>]

On Tuesday, 13 December 2011, Mojca Miklavec wrote:
> On Tue, Dec 13, 2011 at 23:32, Ethan A Merritt wrote:
> > On Tuesday, December 13, 2011 02:19:58 pm Mojca Miklavec wrote:
> >> Hello,
> >>
> >> I just remembered that implementation of monochrome option in context
> >> terminal is slightly suboptimal (in standalone mode it lets TeX do
> >> color conversion into gray scale as "rgb2gray").
> >>
> >> I should probably fix that, but I'm not sure what exactly to do:
> >> should I simply make all the colors black or should I use different
> >> shades of gray, and in the second case - which colors exactly?
> >
> > In my opinion, which may not be universally shared,
> > 'set term foo monochrome' should cause it to choose a default palette
> > in shades of grey, and a default set of lines that are not colored.
> 
> On the other hand, mochrome means "mono" (= single color).

Like black and white photography?  Black and white movies?

> I understand the second. The colors lc 1, lc 2, ... should be gray,
> except that I would be grateful for some proposal of which shades of
> gray exactly.

Do you really mean "lc"?  Why would you use that if not to set colors?

The default sequence of line _types_ should IMHO all be black, for better
reproduction in print.  Use  "set term post mono dashed" as a model.
Something like  solid / dot / thick / dash / dot-dot-dash

But really in version 4.5 you don't need a special terminal option for
this.  You would just need to load a "mono" set of linetypes.

> But what exactly is meant with default palette? PM3D? But how can a
> terminal influence the choice of palette formulas?

Again look at the postscript terminal.  A greyscale palette is really
easy. It doesn't need any formulae unless you want to get fancy and
handle gamma correction.

	Ethan

> > But it should not prevent the user from drawing explicitly in whatever
> > color they like, and it should not prevent the user from selecting a
> > color palette later.
> 
> What exactly do you mean with selecting a color palette? (Probably the
> same question as earlier.)
> 
> > I see it as exactly analagous to "set term foo dashed", which
> > defaults to dashed lines but does not stop you from explictly
> > drawing with solid lines instead
> 
> Yes, but solid line is one particular type of dashed line (one can
> always draw with "lt 0 lc 3"), while the opposite is not true. If one
> selects "solid", it is impossible to draw dashed lines later.
> 
> In the same way, if one chooses "color", one can always plot with "lc
> 0" (black) or with proper black since black is just one type of color.
> (If analogy with dashes was true, one would not be able to draw in
> color once monochrome is selected. On the other hand there exists a
> mechanism to set colors explicitly as rgb values, but no mechanism to
> set an explicit dash type [unless I'm mistaken].)
> 
> Mojca
> 

Re: what should monochrome option do exactly?

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

On Tue, Dec 13, 2011 at 23:32, Ethan A Merritt wrote:
> On Tuesday, December 13, 2011 02:19:58 pm Mojca Miklavec wrote:
>> Hello,
>>
>> I just remembered that implementation of monochrome option in context
>> terminal is slightly suboptimal (in standalone mode it lets TeX do
>> color conversion into gray scale as "rgb2gray").
>>
>> I should probably fix that, but I'm not sure what exactly to do:
>> should I simply make all the colors black or should I use different
>> shades of gray, and in the second case - which colors exactly?
>
> In my opinion, which may not be universally shared,
> 'set term foo monochrome' should cause it to choose a default palette
> in shades of grey, and a default set of lines that are not colored.

On the other hand, mochrome means "mono" (= single color).
I understand the second. The colors lc 1, lc 2, ... should be gray,
except that I would be grateful for some proposal of which shades of
gray exactly.

But what exactly is meant with default palette? PM3D? But how can a
terminal influence the choice of palette formulas?

> But it should not prevent the user from drawing explicitly in whatever
> color they like, and it should not prevent the user from selecting a
> color palette later.

What exactly do you mean with selecting a color palette? (Probably the
same question as earlier.)

> I see it as exactly analagous to "set term foo dashed", which
> defaults to dashed lines but does not stop you from explictly
> drawing with solid lines instead

Yes, but solid line is one particular type of dashed line (one can
always draw with "lt 0 lc 3"), while the opposite is not true. If one
selects "solid", it is impossible to draw dashed lines later.

In the same way, if one chooses "color", one can always plot with "lc
0" (black) or with proper black since black is just one type of color.
(If analogy with dashes was true, one would not be able to draw in
color once monochrome is selected. On the other hand there exists a
mechanism to set colors explicitly as rgb values, but no mechanism to
set an explicit dash type [unless I'm mistaken].)

Mojca

Re: what should monochrome option do exactly?

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

On Tuesday, December 13, 2011 02:19:58 pm Mojca Miklavec wrote:
> Hello,
> 
> I just remembered that implementation of monochrome option in context
> terminal is slightly suboptimal (in standalone mode it lets TeX do
> color conversion into gray scale as "rgb2gray").
> 
> I should probably fix that, but I'm not sure what exactly to do:
> should I simply make all the colors black or should I use different
> shades of gray, and in the second case - which colors exactly?

In my opinion, which may not be universally shared, 
'set term foo monochrome' should cause it to choose a default palette
in shades of grey, and a default set of lines that are not colored.
But it should not prevent the user from drawing explicitly in whatever
color they like, and it should not prevent the user from selecting a
color palette later.

I see it as exactly analagous to "set term foo dashed", which
defaults to dashed lines but does not stop you from explictly
drawing with solid lines instead, or "set term foo font 'blah'",
which doesn't stop you from changing the font later.

	Ethan


> Thank you,
>     Mojca
> 
> ------------------------------------------------------------------------------
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and 
> improve service delivery. Take 5 minutes to use this Systems Optimization 
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

what should monochrome option do exactly?

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

Hello,

I just remembered that implementation of monochrome option in context
terminal is slightly suboptimal (in standalone mode it lets TeX do
color conversion into gray scale as "rgb2gray").

I should probably fix that, but I'm not sure what exactly to do:
should I simply make all the colors black or should I use different
shades of gray, and in the second case - which colors exactly?

Thank you,
    Mojca

X11 terminal doesn't respond to mouse on Mac OS

[FX <fxc...@gm...>]

Hi all,

I compiled gnuplot on Mac OS 10.7.2 (x86_64-apple-darwin11), and while the X11 terminal properly displays graphs, it doesn't let the mouse interact with them (such as rotating an splot, for example).

I configured with: ./configure --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib (the XQuartz X server is in /opt/X11). It compiles fine, and when run, I type "splot sin(x+y)", obtain the graph, however the mouse cannot make the graph rotate as it can on my linux install. The configuration script says:

  X Window System terminal: yes
    (with multi-byte fonts)
    (enable plotting to windows opened by external apps) 
    (with application defaults, in /etc/X11/app-defaults/)

and

  gnuplot will be compiled with the following features:

  Mouse support in interactive terminals: yes
  Zooming or refresh of volatile data: yes 
  Typing <space> in plot window raises console
  Command line macros: yes 
  Placement of rectangles and other objects: yes 

which hint that all should be okay. Is this a known issue? How can I get a working X11 terminal?


Thanks,
FX

Re: How to reset the x/yrange?

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

On Thursday, December 08, 2011 02:01:29 pm Mojca Miklavec wrote:
>> however 'unzoom' is not recognized.

> That is very strange.  'unzoom' is a standard command that should always
> be recognized.  Or you can use the 'u' hotkey in the plot window.

What's even stranger is that my memory obviously isn't working so well today.
The 'u' hotkey does exist, as does an 'unzoom' widget in various terminals.
But 'unzoom' at the command line is apparently a figment of my imagination.
That seems like an oversight that can be fixed!

	Ethan  

Re: How to reset the x/yrange?

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

On Thursday, December 08, 2011 02:01:29 pm Mojca Miklavec wrote:
> On Thu, Dec 8, 2011 at 22:36, Ethan Merritt wrote:
> > On Thursday, December 08, 2011 01:26:54 pm Mojca Miklavec wrote:
> >> Dear gnuplotters,
> >>
> >> I'm sorry for the slightly weird question, but I'm experiencing a
> >> weird behaviour with x11 terminal (under Mac OS X; I used to use Aqua
> >> a lot so far, so I'm not very familiar with mouse events ...).
> >>
> >> If I run
> >>     plot 'somedata' w l
> >> and then zoom into the data with mouse's scroll wheel (+shift and
> >> ctrl), I'm unable to reset the range back to the original one. replot
> >> has zero effect. Another plot just leaves the range where mouse left
> >> it last.
> >
> > Correct. "replot" does not change the current range of the plot.
> > You can can type "unzoom" to return to the original scale, or
> > you can step back and forth through previous zoom operations by
> > using the 'p' or 'n' hotkeys in the plot window.
> 
> Thank you.
> 
> The keys p and n help (it may happen that one has to hold 'p' for a
> very very long time though if there were many iterations done with a
> mouse), however 'unzoom' is not recognized.

That is very strange.  'unzoom' is a standard command that should always
be recognized.  Or you can use the 'u' hotkey in the plot window.

> But even now that I know about p & n: how can I reset the range for
> plotting data to the same state as when gnuplot is started? So that it
> doesn't default to [-10:10][5:5], but adjust to data range instead.

I don't understand the question.
'unzoom' will return to the same state as the previous 'plot' command,
but that isn't the same thing as "when gnuplot is started".
Are you asking about 'set autoscale'?

	Ethan