kmatplot-general

[Kmatplot-general] ISO C++ fixes

[Sam H. <sa...@ne...>]

should
kmatplot/dialogs/ksattrpanel.cpp 
not have a
#include <iostream>
in it?

cheers,
Sam
-- 
Q:	Why did the germ cross the microscope?
A:	To get to the other slide.

Re: [Kmatplot-general] compile errors

[Sam H. <sa...@ne...>]

i think i found what the problem is with the compile errors!! yipee! its
the --enable-final flag, when i last posted i only removed
--disable-debug, but now i tried with only what you said, and by adding
a new flag on and trying, i pinpointed the error....

so everybody be warned the --enable-final flag produces bad code!! i
think it adds all the code into one big file (well, includes cpp files
in a big file), and then tries to compile that, but the preprocessor
replaces occurrences of constants with their value, and this produces a
parse error when it tries to compile something like;
5 = 3;

due to the lack of kde dependence now, will the name be changed? matplot
seems logical but exists already.

cheers i am sooo glad i got this to work, kmatplot is instrumental to my
work, and i was considering putting entire kde2 in just for an older
version!!!
thanks again! i'm away to finish the compile and see what it is like!

Sam
BTW is kmatplot still being maintained, kamil used to respond to any bug
reports i sent in the early days, but now i don't hear anything? anyone
concerned about him?

[Kmatplot-general] compile errors

[Sam H. <sa...@ne...>]

> What happens if you do:
> ./configure --prefix=/usr/X11R6
> then make on a clean tree?
no joy, i still get;

c++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/lib/qt3/include
-I/usr/X11R6/include    -O0 -O2 -march=i686 -mcpu=i686 -fno-exceptions
-fno-check-new  -c libplot_a.all_cpp.cpp
In file included from libplot_a.all_cpp.cpp:13:
qsaxes3d.cpp:87: warning: `FILLS_NUM' redefined
qsaxes2d.cpp:37: warning: this is the location of the previous
definition
qsaxes3d.cpp:88: warning: `LINES_NUM' redefined
qsaxes2d.cpp:38: warning: this is the location of the previous
definition
In file included from libplot_a.all_cpp.cpp:14:
qsplot.cpp:343: warning: `FILLS_NUM' redefined
qsaxes3d.cpp:87: warning: this is the location of the previous
definition
qsplot.cpp:344: warning: `LINES_NUM' redefined
qsaxes3d.cpp:88: warning: this is the location of the previous
definition
qsplot.cpp:345: warning: `POINTS_NUM' redefined
qsaxes3d.cpp:89: warning: this is the location of the previous
definition
In file included from libplot_a.all_cpp.cpp:21:
qsdrvopengl.cpp:585: warning: `EPS' redefined
qsaxes3d.cpp:609: warning: this is the location of the previous
definition
In file included from libplot_a.all_cpp.cpp:23:
qscurve.cpp:74: warning: `CHANNELS_NUM' redefined
qsaxes3d.cpp:85: warning: this is the location of the previous
definition
qscurve.cpp:75: warning: `FILLS_NUM' redefined
qsplot.cpp:343: warning: this is the location of the previous definition
qscurve.cpp:77: warning: `LINES_NUM' redefined
qsplot.cpp:344: warning: this is the location of the previous definition
qscurve.cpp:590: warning: `BOX_SPACE' redefined
qsplot.cpp:393: warning: this is the location of the previous definition
In file included from libplot_a.all_cpp.cpp:24:
qscontour.cpp:43: warning: `MAX_BUFF_SIZE' redefined
qsplot.cpp:282: warning: this is the location of the previous definition
qscontour.cpp:137: warning: `FILLS_NUM' redefined
qscurve.cpp:75: warning: this is the location of the previous definition
qscontour.cpp:139: warning: `LINES_NUM' redefined
qscurve.cpp:77: warning: this is the location of the previous definition
qscontour.cpp:871: warning: `BOX_SPACE' redefined
qscurve.cpp:590: warning: this is the location of the previous
definition
In file included from libplot_a.all_cpp.cpp:25:
qsimage.cpp:49: warning: `CHANNELS_NUM' redefined
qscurve.cpp:74: warning: this is the location of the previous definition
In file included from libplot_a.all_cpp.cpp:26:
qsfigure.cpp:227: warning: `CHANNELS_NUM' redefined
qsimage.cpp:49: warning: this is the location of the previous definition
In file included from libplot_a.all_cpp.cpp:27:
qssurface.cpp:158: warning: `CHANNELS_NUM' redefined
qsfigure.cpp:227: warning: this is the location of the previous
definition
In file included from libplot_a.all_cpp.cpp:24:
qscontour.cpp: In method `QSGriddedContour::QSGriddedContour(QSAxes *,
const char * = 0)':
qscontour.cpp:1010: parse error before `11'
qscontour.cpp: In method
`QSNonGriddedContour::QSNonGriddedContour(QSAxes *, const char * = 0)':
qscontour.cpp:1558: parse error before `11'
In file included from libplot_a.all_cpp.cpp:31:
qsctool.cpp: In method `bool QSTool::canvasEvent(QEvent *)':
qsctool.cpp:64: parse error before `2'
qsctool.cpp:65: parse error before `3'
make[3]: *** [libplot_a.all_cpp.o] Error 1
make[3]: Leaving directory `/usr/src/kmatplot-0.4/kmatplot/widgets'

Sam
-- 
Cops never say good-bye. They're always hoping to see you again in the
line-up.
		-- Raymond Chandler

Re: [Kmatplot-general] compile errors

[Sam H. <sa...@ne...>]

> what is exactly your linux system ?
> Redhat, Debian, LFS, Suse ?
i am runngin Linux From Scratch, a variant on verison 3.0... i have
compield everythign on my system myself, so i'm pretty sure i have
everythign that is required, i never had any problems compiling earlier
versions of kmatplot on qt2, and i have used qt3 to compile kde3 (which
i promptly removed becuase it is VERY bloated) and i deleted the qt3
tree and recompiled the non-threaded version jsut so kmatplot could use
it, when compiling qt3 i use;

../configure -shared -xinerama -xrender -xkb -sm -no-thread -qt-gif
-system-libpng -system-libmng -system-zlib -system-libjpeg -xft
-no-g++-exceptions -release

and for kmatplot i use;
../configure --prefix=/usr/X11R6 --disable-debug
--with-qt-dir=/usr/lib/qt3 -with-pythondir=/usr/lib/python2.2
--with-numpy=/usr/lib/python2.2 --with-scilab-lib-dir=/usr/X11R6
--enable-final

the kmatplot code seems to redeclare a whoel lot of values, i get parse
errrors when constants are changed. i use gcc-2.95.3 with glibc 2.2.5,
linux 2.4.18.

cheers,
Sam
-- 
Misfortune, n.:
	The kind of fortune that never misses.
		-- Ambrose Bierce, "The Devil's Dictionary"

Re: [Kmatplot-general] compile errors

[Laurent J. <lja...@fy...>]

Hello,

what is exactly your linux system ?
Redhat, Debian, LFS, Suse ?

Under debian you have to use libqt3 (3.0.4, runtime version) and the 
associated development package libqt3-dev.

Under Redhat 7.3, 
http://rpmfind.net//linux/RPM/redhat/7.3/i386/qt-3.0.3-11.i386.html
is ok with
http://rpmfind.net//linux/RPM/redhat/7.3/i386/qt-devel-3.0.3-11.i386.html

Then, complete the .configure's options according to the qt libraries and 
headers locations.

Laurent.

[Kmatplot-general] compile errors

[Sam H. <sa...@ne...>]

hi again,

i have tried compiling kmatplot 0.4 again with qt-3.0.4 no-threads, but
i still get the parse errors... on closer inspection, the parse errors
seem to be coming from constants being redefined... i fixed this by
removing the files
#include "qsaxes3d.cpp"
#include "qsplot.cpp"
#include "qscurve.cpp"
#include "qscontour.cpp"
#include "qsimage.cpp"
#include "qsfigure.cpp"
#include "qssurface.cpp"
#include "qsctool.cpp"
from the dynamically made file kmatplot/widgets/libplot_a.all_cpp.cpp
and also the same sort of thing with function redeclarations in
kmatplot/dialogs/libdialogs_a.all_cpp.cpp

i gave up tryign to fix it there as obviously any version i compile will
be missing many features if it even loads at all.... is it maybe that my
version of qt is too recent for kmatplot?

also i seem to be gettign a lot of warings like;
/usr/lib/qt3/bin/uic -i ksgraphwizardinterf.h ./ksgraphwizardinterf.ui >
ksgraphwizardinterf.cpp || rm -f ksgraphwizardinterf.cpp
Session management error: Authentication Rejected, reason : None of the
authentication protocols specified are supported and host-based
authentication failed

cheers,
Sam
-- 
Osborn's Law:
	Variables won't; constants aren't.

Re: [Kmatplot-general] kmatplot-dev ?

[Laurent J. <lja...@fy...>]

On Wednesday 22 May 2002 00:08, you wrote:
> Hello Hugo,
>
> Do you think to be able (when you have time of course) to create a
> development package for kmatplot ?
>
> I would be great to have a package kmatplot-dev which gathers
> - headers of kmatplot;
> - dynamic and static libraries;
> - demos like demo2d.cpp and demo3d.cpp;
> - ... anything interesting for development.
>
> In particular, it allows us to create new functions for the octave
> interface when we want to compile new .oct file with mkoctfile.

To complete what I said, the important library for the development of an 
octave interface (but this is not the most important library for a kmatplot 
development package) is
	libkmatplot_interface.a
created into 
	kmatplot-0.4/kmatplot/interface/libkmatplot_interface.a

Bye,
Laurent.

[Kmatplot-general] Re: /etc/kmatplotrc solved

[Laurent J. <lja...@fy...>]

On Thursday 23 May 2002 11:14, Hugo van der Merwe wrote:
> QSETTINGSDIR was set etc.=20

In my case, QSETTINGSDIR was empty in the main Makefile until I put the=20
export line in the debian/rules. Then, QSETTINGSDIR has been set to /etc =
in=20
the main Makefile.

> It's this that was missing:
> > 2=B0) uncomment the line 132 of /kmatplot-0.4/kmatplot/ksglobalsettin=
gs.cpp
> > // s.insertSearchPath( QSettings::Unix, "/etc" );
>
> Thanks. Does --with-qsettings-dir then actually do anything? I have not
> yet bothered testing what happens if I don't supply it.

I think it does something in the kmatplot configuration but not in the ma=
in=20
Makefile. Why ?

Not related: Kamil, do you receive our messages from the kmatplot mailing=
=20
list ?


Laurent.

[Kmatplot-general] Re: /etc/kmatplotrc solved

[Hugo v. d. M. <s13...@ba...>]

> I have solved the problem of the not found /etc/kmatplotrc.

Thanks!

> 	export QSETTINGSDIR=/etc

This I already have for the call to configure, which is the only time
it's needed, it seems. (It works right now.)

> If you don't do that, the variable QSETTINGDIR is not set in the building of 
> the main Makefile by configure, whatever is the --with-qsettings-dir option.

QSETTINGSDIR was set etc. It's this that was missing:

> 2°) uncomment the line 132 of /kmatplot-0.4/kmatplot/ksglobalsettings.cpp
> // s.insertSearchPath( QSettings::Unix, "/etc" );

Thanks. Does --with-qsettings-dir then actually do anything? I have not
yet bothered testing what happens if I don't supply it.

Hugo

[Kmatplot-general] /etc/kmatplotrc solved

[Laurent J. <lja...@fy...>]

Hello Hugo,

I have solved the problem of the not found /etc/kmatplotrc.
This problem comes from two points: one in the kmatplot source, the other=
 in=20
the compilation process.

To obtain a correct link of kmatplot with /etc/kmatplotrc, you have to
1=B0) add a line=20
	export QSETTINGSDIR=3D/etc
in the beginning of your kmatplot-0.4/debian/rules.
If you don't do that, the variable QSETTINGDIR is not set in the building=
 of=20
the main Makefile by configure, whatever is the --with-qsettings-dir opti=
on.

2=B0) uncomment the line 132 of /kmatplot-0.4/kmatplot/ksglobalsettings.c=
pp
// s.insertSearchPath( QSettings::Unix, "/etc" );

This seems to add the directory /etc to the list of places where kmatplot=
=20
search kmatplotrc (but it is not activate by default).
I have found that by applying=20
	egrep -r /usr/local *
on the global kmatplot source.


This works for me. I have modified /etc/kmatplotrc to test that and it ha=
s=20
been directly reported on the kmatplot Setting->Configure Kmatplot->Paths

Now it's time for me to sleep ;-)
Bye,
Laurent.

Re: [Kmatplot-general] build problems

[Hugo v. d. M. <s13...@ba...>]

> > <blowing off steam> If people stop tripping the power here I'd also find
> > it easier to reply to emails... grrr </blowing off steam>
> ah well, thats stellenbosch for ya ;)

<g>

> thats not it, kmatplot is finding the directory OK, its looking for the wrong 
> file

> > Debian qt3 has a libqt.so ... What distro are you using, does it have
> > proper qt3 packages / support? (Or did you install qt3 from sources.)
> LFS, but libqt.so is the non-threaded version of QT3 so it shouldnt really be 
> there.... what version of QT is needed? the website says Qt 3.0.1 but the 
> configure script says Qt 2.2.2... do i need both 2 and 3 versions?

I build kmatplot in a chroot which only has qt3, version 3.0.3. I have
not been building with the threaded lib either. Yes, it does seem
kmatplot specifically wants the non-threaded version...

I don't know enough of autotools to know how one would try to change
this...

BTW, in the words of Kamil: "KMatplot 0.4 needs Qt 3.0.1. It won't work
with earlier versions probably." The README needs updating too, it
claims 2.3

Hugo

Re: [Kmatplot-general] build problems

[Sam H. <sa...@ne...>]

> <blowing off steam> If people stop tripping the power here I'd also fin=
d
> it easier to reply to emails... grrr </blowing off steam>
ah well, thats stellenbosch for ya ;)

> Try setting the "QTDIR" environment variable to the base of your QT3
> installation / development files?
thats not it, kmatplot is finding the directory OK, its looking for the w=
rong=20
file

> Debian qt3 has a libqt.so ... What distro are you using, does it have
> proper qt3 packages / support? (Or did you install qt3 from sources.)
LFS, but libqt.so is the non-threaded version of QT3 so it shouldnt reall=
y be=20
there.... what version of QT is needed? the website says Qt 3.0.1 but the=
=20
configure script says Qt 2.2.2... do i need both 2 and 3 versions?

cheers,
Sam

Re: [Kmatplot-general] build problems

[Hugo v. d. M. <s13...@ba...>]

<blowing off steam> If people stop tripping the power here I'd also find
it easier to reply to emails... grrr </blowing off steam>

> please please sombody help!!!! this program is why i use kde.....

Note that KDE isn't necessary for kmatplot 0.4.

> ANY advice on the build problems ofg Kmatplot.... i woudl REALLY liek to get 
> thsi version workign, sice after all i upgraded the whole of kde and qt just 
> to use the latest kmatplot.....
> 
> the error again...
> checking for Qt... configure: error: Qt (>= Qt 2.2.2) (libraries) not found. 
> Please check your installation!

You know more about these things than I do, I believe, thus I doubt I
can help you. But I'll try anyway:

Try setting the "QTDIR" environment variable to the base of your QT3
installation / development files?

> the config.log shows that it is looking for -lqt... this library doesnt really 
> exist in qt3, unless you build without threads, which sort of defeats the 
> purpose of upgrading to qt3.....

Debian qt3 has a libqt.so ... What distro are you using, does it have
proper qt3 packages / support? (Or did you install qt3 from sources.)

Hugo van der Merwe

[Kmatplot-general] build problems

[Sam H. <sa...@ne...>]

ANY advice on the build problems ofg Kmatplot.... i woudl REALLY liek to =
get=20
thsi version workign, sice after all i upgraded the whole of kde and qt j=
ust=20
to use the latest kmatplot.....

the error again...
checking for Qt... configure: error: Qt (>=3D Qt 2.2.2) (libraries) not f=
ound.=20
Please check your installation!

the config.log shows that it is looking for -lqt... this library doesnt r=
eally=20
exist in qt3, unless you build without threads, which sort of defeats the=
=20
purpose of upgrading to qt3.....

please please sombody help!!!! this program is why i use kde.....
Sam

Re: [Kmatplot-general] kmatplot-dev ?

[Hugo v. d. M. <s13...@ba...>]

> Do you think to be able (when you have time of course) to create a 
> development package for kmatplot ? 

Certainly. I will try my best to get round to it this weekend, or before
this weekend. (No guarantees though.)

> I would be great to have a package kmatplot-dev which gathers
> - headers of kmatplot;
> - dynamic and static libraries;
> - demos like demo2d.cpp and demo3d.cpp;
> - ... anything interesting for development.
> 
> In particular, it allows us to create new functions for the octave interface 
> when we want to compile new .oct file with mkoctfile.
> 
> What is your opinion ?

It's a great idea.

What bothers me most about the current package though is "qsettingsdir",
kmatplotrc, and not knowing where I should install that file, how to get
kmatplot to actually find it...

I am hoping Kamil might be able to help when he gets to read the mailing
list again, he apparently has some connection problems at the moment.

Hugo

[Kmatplot-general] kmatplot-dev ?

[Laurent J. <lja...@fy...>]

Hello Hugo,

Do you think to be able (when you have time of course) to create a 
development package for kmatplot ? 

I would be great to have a package kmatplot-dev which gathers
- headers of kmatplot;
- dynamic and static libraries;
- demos like demo2d.cpp and demo3d.cpp;
- ... anything interesting for development.

In particular, it allows us to create new functions for the octave interface 
when we want to compile new .oct file with mkoctfile.

What is your opinion ?

Bye,
Laurent.

	

Re: [Kmatplot-general] Wish list for kmatplot/octave

[Laurent J. <lja...@fy...>]

On Tuesday 21 May 2002 19:09, you wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hey,
> Perhaps there needs to be a mode switch kautoaxes(bool, type) which tel=
ls
> KMatplot whether to auto add axis when a call to kplot is made. This wo=
uld
> make it more like Matlab. (Perhaps such a function already exists, and =
I
> don't know about it...)


Good idea. I like this way of doing.

>
> > 4=B0) a function
> > 	kginput(n)
> > to obtain n coordinates on a 1D and 2D plot by clicking n times on it
>
> I don't understand how this works, perhaps that's because I haven't use=
d
> the equivalent function under Matlab.

I was not very clear, sorry.

This function works like this in Matlab:

>> pos=3Dginput(1)
wait until you click one time on the current plot (1D or 2D) and return t=
he=20
coordinates of the click relatively to the current axes into the vector p=
os=20
(size: 1x2)

>> pos=3Dginput(n)
Do the same but wait for n clicks and returns n coordinates in pos (size:=
=20
nx2): one couple of coordinates for each click.

Regards,
Laurent.

Re: [Kmatplot-general] Wish list for kmatplot/octave

[Timothy H. <ti...@po...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey,
Perhaps there needs to be a mode switch kautoaxes(bool, type) which tells=
=20
KMatplot whether to auto add axis when a call to kplot is made. This woul=
d=20
make it more like Matlab. (Perhaps such a function already exists, and I=20
don't know about it...)

> 4=B0) a function
> =09kginput(n)
> to obtain n coordinates on a 1D and 2D plot by clicking n times on it

I don't understand how this works, perhaps that's because I haven't used =
the=20
equivalent function under Matlab.

Thanks,
Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE86n86BYrcB1iEURERAtCVAKCnTsUzwyV7J8IViRu1IG4rNIVrzQCePy3h
3DYwxbFEhtFH+29mWyDXI00=3D
=3DUx6G
-----END PGP SIGNATURE-----

[Kmatplot-general] buld problems with gcc-2.95.3

[Sam H. <sa...@ne...>]

hi again, i was just wondering if anyoen knew what my buld probelm was wh=
en=20
building kmatplot on kde-3.0 with qt-3.0.4 using gcc-2.95.3.... i hav ea=20
sneaky suspicion it might be because all you guys are using redhat (am i=20
right?) and their gcc-2.96 which seems to have its own c rules ;) has any=
one=20
built with gcc-2.95.3, ore does anyoen know a workaround for my compile=20
error.

by the way, i just deleted qt2, an dnow running teh configure script, i g=
et
checking for Qt... configure: error: Qt (>=3D Qt 2.2.2) (libraries) not f=
ound.=20
Please check your installation!

is kmatplot definitely qt3 only? i dont have the no-theeads version just =
the=20
qt-mt threads version.... config.log seems to show that configure is tryg=
in=20
to find -lqt

thanks in advance!
Sam
--=20
Politicians speak for their parties, and parties never are, never have
been, and never will be wrong.
=09=09-- Walter Dwight

[Kmatplot-general] Wish list for kmatplot/octave

[Laurent J. <lja...@fy...>]

Hello,

Here are my dreams for an interface kmatplot/octave. I can eventually giv=
e a=20
hand to concretize that.=20

Please, don't hesitate to critic and comment the following list:

1=B0) Like I said in a preceeding mail, a function=20
	kcolormap(<colormap_string>)
to control the colormap of any plots will be great with a set of predefin=
ed=20
colormap (matrices Mx3 for M>=3D1)

2=B0) A couple of function kset/kget to control the object tree of kmatpl=
ot=20
through octave exactly like get and set do that in matlab.=20

In other words,
the command
	kget(<object_number>)
	kget(<object_number>,<property_name>)
would give respectively a complete list of the properties of the object=20
refered by <object_number>, or the value of the <property_name> belonging=
 to=20
this object.

And the command
	kset(<object_number>,<property_name>,<property_value>)
would set <property_name> to <property_value>.


3=B0) a function=20
	kview(azimut, elevation)
to control the camera position around a 3D plot

4=B0) a function=20
	kginput(n)
to obtain n coordinates on a 1D and 2D plot by clicking n times on it

5=B0) functions like
	kxlabel(<string>)
	kylabel(<string>)
	kzlabel(<string>)
	ktitle(<string>)
to write the xlabel, ylabel, zlabel (if 3D) and title through octave.

6=B0) and finally, a function
	kprint <options> <filename>
	kprint <other_options> <printername>

to export the current figure in $PWD in various format like EPS, QT Metaf=
ile,=20
Bitmap, JPEG, or to send figure to a given printer.


These six points represent the only wall for me to adopt completely Octav=
e=20
instead of Matlab. I think I'm not the only one in that case.=20

Kmatplot is a great step for that.

Bye,
Laurent.

Re: [Kmatplot-general] Documentation

[Hugo v. d. M. <s13...@ba...>]

> > In my experience, kmatlot dies if one passes it e.g. kmesh(g), but is
> > happy if you pass it kmesh(x,y,g). I have to replace meshgrid(1:256)
> > with meshgrid(1:40) though, as anything larger causes the graph to not
> > be displayed. With it displayed, it's a set of vertical planes, not a
> > nice meshed surface...
> 
> Strange limitation. It's a bit annoying.

Is there a BTS somewhere for kmatplot, where one can also report
wishlist items, etc?

> Kamil, it's a detail but, is the kaddaxes procedure is absolutely necessary 
> in Octave ? 
> I think that a good use for a kmatplot "octaved" will be to approach the 
> matlab way where you have no equivalent of kaddaxes.

I think that while it is useful to be able to access different sets of
axes from octave, ideally it should also be more "directly compatible"
with what people already know. I would suggest that if a call is made to
kmesh or kplot etc. before a call to kaddaxes has been made, that axes
could be created automatically?

At a later version, if one wants more compatibility, one would want to
have a "hold" clone as well. It is always difficult to remain
"compatible" with existing solutions, while at the same time trying to
develop something new with more features. Hence maybe there needs to
(eventually) be "two modes" of operation, one compatible as far as
possible, the other - possibly turned on as soon as any of its features
are used - something that gives access to all the nice new features?

> Another point, do you it is possible to control the colormap through octave ?
> I think about something like 
> 	kcolormap("colormap_string");

Ideally, eventually, an octave would want to be able to e.g. generate
nice postscript output from kmatplot without ever touching his mouse, or
the kmatplot app for that matter: while one of kmatplot's design
features is its "interactiveness", an octave user would often want to
write a script that generates graph output. And if he changes something
in this script, he(/she) wants to regenerate all the output without
intervention...

> But perhaps it already exists and I didn't have read correctly the doc (RTFM)?

Is there a doc to read that I do not know about? On the topic of docs,
does octave have some nice docs (I'm sure it does...) on writing
extensions, e.g. the kmatplot octave functions? (Depending on how my
holiday looks - depending on what work I'm given at my holiday job - I'd
like to play with octave/kmatplot coding a bit.)

Thanks,
Hugo van der Merwe

Re: [Kmatplot-general] Documentation

[Laurent J. <lja...@fy...>]

On Thursday 16 May 2002 20:32, Hugo van der Merwe wrote:
> It's kmesh that I want to figure out. (One uses kaddaxes(1) to get 3D
> axes instead of 2D.)

Of course, I forgot that point.

Instead of killing kmatplot, a bad use of kmesh after kaddaxes(0) instead of 
kaddaxes(1) would have to return an error message.

>
> In my experience, kmatlot dies if one passes it e.g. kmesh(g), but is
> happy if you pass it kmesh(x,y,g). I have to replace meshgrid(1:256)
> with meshgrid(1:40) though, as anything larger causes the graph to not
> be displayed. With it displayed, it's a set of vertical planes, not a
> nice meshed surface...

Strange limitation. It's a bit annoying.

Kamil, it's a detail but, is the kaddaxes procedure is absolutely necessary 
in Octave ? 
I think that a good use for a kmatplot "octaved" will be to approach the 
matlab way where you have no equivalent of kaddaxes.

Another point, do you it is possible to control the colormap through octave ?
I think about something like 
	kcolormap("colormap_string");
But perhaps it already exists and I didn't have read correctly the doc (RTFM)?

Thanks,
Laurent.

Re: [Kmatplot-general] Documentation

[Hugo v. d. M. <s13...@ba...>]

> > Here is a simple example (I hope it helps you)
> >
> > octave:26> [x,y]=meshgrid(1:256);
> > octave:27> g=exp(-((x-128).^2+(y-128).^2)/1000);
> > octave:28> kaddaxes(0)
> > ans = 5
> > octave:29> kimage(g)
> > ans = 0

Thanks, kimage is nice. kcontour is also. I'm happy with the 2D stuff.

> Bug detected:
> 
> In the above example, it seems that kmesh of octave causes a segfault of 
> kmatplot. I haven't produced it on a i386 but on an alpha (debian woody 
> sidded, octave2.1) so I don't know if this bug is also present on i386 ?

It's kmesh that I want to figure out. (One uses kaddaxes(1) to get 3D
axes instead of 2D.)

In my experience, kmatlot dies if one passes it e.g. kmesh(g), but is
happy if you pass it kmesh(x,y,g). I have to replace meshgrid(1:256)
with meshgrid(1:40) though, as anything larger causes the graph to not
be displayed. With it displayed, it's a set of vertical planes, not a
nice meshed surface...

Hugo

[Kmatplot-general] error building

[Sam H. <sa...@ne...>]

hi i get this error compiling KMatplot 0.4 on kde3 with gcc-2.95.3....

c++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/lib/qt3/include=20
-I/usr/X11R6/include    -DNDEBUG -O0 -O2 -march=3Di386 -mcpu=3Di686=20
-fno-exceptions -fno-check-new  -c libplot_a.all_cpp.cpp
In file included from libplot_a.all_cpp.cpp:13:
qsaxes3d.cpp:87: warning: `FILLS_NUM' redefined
qsaxes2d.cpp:37: warning: this is the location of the previous definition
qsaxes3d.cpp:88: warning: `LINES_NUM' redefined
qsaxes2d.cpp:38: warning: this is the location of the previous definition
In file included from libplot_a.all_cpp.cpp:14:
qsplot.cpp:343: warning: `FILLS_NUM' redefined
qsaxes3d.cpp:87: warning: this is the location of the previous definition
qsplot.cpp:344: warning: `LINES_NUM' redefined
qsaxes3d.cpp:88: warning: this is the location of the previous definition
qsplot.cpp:345: warning: `POINTS_NUM' redefined
qsaxes3d.cpp:89: warning: this is the location of the previous definition
In file included from libplot_a.all_cpp.cpp:21:
qsdrvopengl.cpp:585: warning: `EPS' redefined
qsaxes3d.cpp:609: warning: this is the location of the previous definitio=
n
In file included from libplot_a.all_cpp.cpp:23:
qscurve.cpp:74: warning: `CHANNELS_NUM' redefined
qsaxes3d.cpp:85: warning: this is the location of the previous definition
qscurve.cpp:75: warning: `FILLS_NUM' redefined
qsplot.cpp:343: warning: this is the location of the previous definition
qscurve.cpp:77: warning: `LINES_NUM' redefined
qsplot.cpp:344: warning: this is the location of the previous definition
qscurve.cpp:590: warning: `BOX_SPACE' redefined
qsplot.cpp:393: warning: this is the location of the previous definition
In file included from libplot_a.all_cpp.cpp:24:
qscontour.cpp:43: warning: `MAX_BUFF_SIZE' redefined
qsplot.cpp:282: warning: this is the location of the previous definition
qscontour.cpp:137: warning: `FILLS_NUM' redefined
qscurve.cpp:75: warning: this is the location of the previous definition
qscontour.cpp:139: warning: `LINES_NUM' redefined
qscurve.cpp:77: warning: this is the location of the previous definition
qscontour.cpp:871: warning: `BOX_SPACE' redefined
qscurve.cpp:590: warning: this is the location of the previous definition
In file included from libplot_a.all_cpp.cpp:25:
qsimage.cpp:49: warning: `CHANNELS_NUM' redefined
qscurve.cpp:74: warning: this is the location of the previous definition
In file included from libplot_a.all_cpp.cpp:26:
qsfigure.cpp:227: warning: `CHANNELS_NUM' redefined
qsimage.cpp:49: warning: this is the location of the previous definition
In file included from libplot_a.all_cpp.cpp:27:
qssurface.cpp:158: warning: `CHANNELS_NUM' redefined
qsfigure.cpp:227: warning: this is the location of the previous definitio=
n
In file included from libplot_a.all_cpp.cpp:24:
qscontour.cpp: In method `QSGriddedContour::QSGriddedContour(QSAxes *, co=
nst=20
char * =3D 0)':
qscontour.cpp:1010: parse error before `11'
qscontour.cpp: In method `QSNonGriddedContour::QSNonGriddedContour(QSAxes=
 *,=20
const char * =3D 0)':
qscontour.cpp:1558: parse error before `11'
In file included from libplot_a.all_cpp.cpp:31:
qsctool.cpp: In method `bool QSTool::canvasEvent(QEvent *)':
qsctool.cpp:64: parse error before `2'
qsctool.cpp:65: parse error before `3'
make[3]: *** [libplot_a.all_cpp.o] Error 1
make[3]: Leaving directory `/usr/src/kmatplot-0.4/kmatplot/widgets'

any suggestions? i have qt-3.0.4.

Sam
--=20
All most men really want in life is a wife, a house, two kids and a car,
a cat, no maybe a dog.  Ummm, scratch one of the kids and add a dog.
Definitely a dog.

Re: [Kmatplot-general] Documentation

[Laurent J. <lja...@fy...>]

On Thursday 16 May 2002 17:53, Laurent Jacques wrote:
>
> Here is a simple example (I hope it helps you)
>
> octave:26> [x,y]=meshgrid(1:256);
> octave:27> g=exp(-((x-128).^2+(y-128).^2)/1000);
> octave:28> kaddaxes(0)
> ans = 5
> octave:29> kimage(g)
> ans = 0
>
> For the colorbar, I don't know.
> Perhaps directly on kmatplot.
>

Bug detected:

In the above example, it seems that kmesh of octave causes a segfault of 
kmatplot. I haven't produced it on a i386 but on an alpha (debian woody 
sidded, octave2.1) so I don't know if this bug is also present on i386 ?

Bye
Laurent.