help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: octave's graphics interface / linux operating system


From: Sergei Steshenko
Subject: Re: octave's graphics interface / linux operating system
Date: Wed, 14 May 2008 23:20:39 -0700 (PDT)

--- "John W. Eaton" <address@hidden> wrote:

> On 14-May-2008, Francesco Potorti` wrote:
> 
> | The trick of sending the gnuplot commands to a file for further refining
> | satisfies this need.
> 
> It seems you are assuming that Octave will continue to emit gnuplot
> commands.  I keep trying to say that this might not happen in the
> future, but apparently the message isn't getting through.
> 
> jwe
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://www.cae.wisc.edu/mailman/listinfo/help-octave
> 

John,

I think the issue is somewhat wider.

To the same extent GNU == GNU is not UNIX let's assume the next plotting backend
with be based on NOT == NOT is not gnuplot - whatever NOT will be.

For general reasons it makes sense to have NOT running as a separate process
- in such a case crashes in it will not cause 'octave' to crash - very 
important practically.

So, I expect IPC.

An easy way to implement IPC is using pipes - I do not insist on such approach, 
but it's
simple/popular.

If IPC + pipes are to be used, then end users want a simple way to have IPC 
protocolled,
i.e. they want the ability to take the octave -> NOT stream, analyze it, modify 
if necessary
and feed it into NOT again without 'octave'.

This end users' desire makes perfect sense to me.

Thanks,
  Sergei.


Applications From Scratch: http://appsfromscratch.berlios.de/


      


reply via email to

[Prev in Thread] Current Thread [Next in Thread]