On Feb 23, 2015, at 12:23 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-02-22 22:04-0500 Jim Dishaw wrote:
The ctest and cmake commands are part of what you get when you build
the CMake software package. So I presume you did have success
building CMake and that is a really
Should I use wxWidgets 2.8 or 3.0?
On Feb 23, 2015, at 10:48 AM, Jim Dishaw j...@dishaw.org wrote:
On Feb 23, 2015, at 12:23 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca
wrote:
On 2015-02-22 22:04-0500 Jim Dishaw wrote:
The ctest and cmake commands are part of what you get when you
Yep, will do. I was just setting up to do that today.
On Feb 22, 2015, at 4:37 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
@Jim: could you please try the attached patch on Mac OS X, and
especially the test mentioned in the commit message?
@Phil: could you do the same thing on
I just cloned from SF and tried to apply the patch with no success (see below).
I can say, however, that I was able to successfully build and run ctest on
MacOS X. When I run test-plplot.sh and test_diff.sh, I get a message about
missing stdout for all the examples.
bash-3.2$ git apply
On Feb 20, 2015, at 4:13 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-02-20 14:32-0500 Jim Dishaw wrote:
Hi Jim:
I have read and re-read Solutions 1 and 2 and I don't see any
difference between how you have presented them. Did you mean to say
something else for one
I've gone through the coordinate transformation and where/how it is applied in
the library. The coordinates that are stored in the plot buffer can be best
described as device virtual pixels and the definition is not necessarily
consistent across all the devices. I don't think that is a show
My plan is to have it done by Friday, perhaps sooner.
On Feb 18, 2015, at 2:04 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-02-17 22:16-0500 Jim Dishaw wrote:
On Feb 17, 2015, at 3:23 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca
wrote:
Hi Jim:
On 2015-02-17 13:11
On Feb 17, 2015, at 3:23 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
Hi Jim:
On 2015-02-17 13:11-0500 Jim Dishaw wrote:
Hopefully this patch series will work correctly. I started a new
topic branch as recommended.
IMPORTANT. Which means your patch series and my subsequent
I noticed that there is a new escape command PLESC_IMPORT_BUFFER and I am not
sure if it should be an escape command. Currently, the plot buffer only needs
to handle a small subset of the PLESC operations and all the other commands
would work while playing back the buffer.
The
Hopefully this patch series will work correctly. I started a new topic branch
as recommended.
The plot metafile read will generate an output identical to plrender.
Visually, the plot is similar to the output generated by plplot directly;
however, due to the difference in coordinates the file
On Feb 16, 2015, at 2:54 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-02-15 23:04-0500 Jim Dishaw wrote:
I think I successfully got my master updated and rebased my branch. I have
attached a patch that captures my work relative to the current master. I
really hope
and simply increment the version number written.
Phil
From: Jim Dishaw
Sent: 16/02/2015 04:07
To: plplot-devel@lists.sourceforge.net list
Subject: [Plplot-devel] plmetafile compatibility
I need to create a new metafile version because there are commands (CHANGE
STATE CHR and CHANGE
Did the patch I sent earlier work?
On Feb 15, 2015, at 7:43 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-02-15 23:07- Phil Rosenberg wrote:
Hi Alan
How do you perform the style changes and do you know if I can do the
same with Cygwin.
I just did a rebase and all my
I need to create a new metafile version because there are commands (CHANGE
STATE CHR and CHANGE STATE SYM) that are not supported by the current version
(2005) metafile. Also, the current version does not save the color alpha
channels. What other shortcomings need to fixed?
I will maintain
On Feb 15, 2015, at 10:35 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-02-15 21:15-0500 Jim Dishaw wrote:
Did the patch I sent earlier work?
The last I saw from you was the patch (actually a patch series) you
sent 3 days ago. That got into the integrated series by Phil
Grr, here is the patch. Coding with a cold is *no* fun.
plbuf_plmem.patch
Description: Binary data
On Feb 15, 2015, at 11:04 PM, Jim Dishaw j...@dishaw.org wrote:
On Feb 15, 2015, at 10:35 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca
wrote:
On 2015-02-15 21:15-0500 Jim Dishaw wrote
On Feb 14, 2015, at 3:54 PM, Phil Rosenberg p.d.rosenb...@gmail.com wrote:
I found an hour to go through all the examples this afternoon and
found a number of items that need fixing. The most important of which
was that fills weren't working.
My list of things to fix follows, along with
On Feb 13, 2015, at 3:25 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-02-13 00:04-0500 Jim Dishaw wrote:
The attached patch is a roll-up of all the changes that I have made:
- Moved the memory allocation routines from pdf_utils to plmem.c (new file)
- Bug fixes to plbuf.c
on plmeta
because it does not appear to affect the displayed output.
-Original Message-
From: Jim Dishaw j...@dishaw.org
Sent: 06/02/2015 20:16
To: Alan W. Irwin ir...@beluga.phys.uvic.ca
Cc: PLplot development list Plplot-devel@lists.sourceforge.net
Subject: Re: [Plplot-devel
There should be no problem if you increased that number. I have to ask if you
need more than 100 simultaneous plots. You can use pladv() or the
plbop()/pleop() functions to advance to a new page. If you really want a fresh
state you can do a plend1() call and then start over.
A better
Phil, please send me a patch relative to the current master and I will apply to
my branch. I will issue a new patch of my branch.
On Feb 13, 2015, at 3:01 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-02-13 17:19- Phil Rosenberg wrote:
Just to prove Alan right that Jim
On Feb 10, 2015, at 10:07 AM, Phil Rosenberg p.d.rosenb...@gmail.com wrote:
Hi Alan, Jim and all
I have had to rework some of the new wxWidgets driver to allow
plGetCursor to work. SOme obvious extra challenges presented
themselves when I realised how this function worked, such as two way
Is the minimum supported compiler the C89 specification? I would like to use
the offsetof() macro in the implementation of the revised metafile I/O
routines. My goal is to define the data file format in a variable and to
support multiple versions for backwards compatibility.
On Feb 6, 2015, at 5:25 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-02-06 15:15-0500 Jim Dishaw wrote:
On Feb 6, 2015, at 2:40 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca
wrote:
On 2015-02-06 08:36-0500 Jim Dishaw wrote:
I was able to get nearly identical outputs using
On Feb 6, 2015, at 2:40 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-02-06 08:36-0500 Jim Dishaw wrote:
I was able to get nearly identical outputs using psc with a replot
of the plot buffer. The only differences were the time stamp in the
header and an additional pen color
I was able to get nearly identical outputs using psc with a replot of the plot
buffer. The only differences were the time stamp in the header and an
additional pen color command that doesn't affect anything.
I'm trying to figure out how to eliminate the extra pen color command, but I'm
not
the data size is
fixed or zero. This means that we will always be able to skip an
unknown command. This would then just require a plwarn call to
indicate an unknown command.
Phil
On 29 January 2015 at 03:33, Jim Dishaw j...@dishaw.org wrote:
I guess it would help if I would attach the patch
I guess it would help if I would attach the patch!
plbuf_bugfix.patch
Description: Binary data
On Jan 28, 2015, at 9:59 PM, Jim Dishaw j...@dishaw.org wrote:
While working on the plot metafile, I fixed a segfault issue that Phil was
having with his wxWidgets work. I made a patch
While working on the plot metafile, I fixed a segfault issue that Phil was
having with his wxWidgets work. I made a patch that fixes this issue. I don't
know about the need to push this to patch to master. The only jarring behavior
is a plexit() call that I put in plbuf_control() to catch
I test the code by using the xwin driver and resize the plot window.
But I think a better way would be to write a test program that makes a plot and
then calls plRemakePlot. I will put something together.
Phil's wxWidgets work is also a good test case.
On Jan 28, 2015, at 11:23 PM, Alan W.
I have attached a patch for the plmem.c change. This was part of a larger
patch that I sent to Phil for testing, but I saw your email about wanting to
get things tested sooner than later.
plmem.patch
Description: Binary data
Also, I will try to test plplot on the Mac and let you know if
it then feel free as Alan said. :-)
Phil
On 26 January 2015 at 01:35, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-01-25 14:59-0500 Jim Dishaw wrote:
On Jan 25, 2015, at 1:26 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca
wrote:
On 2015-01-24 22:34-0500 Jim Dishaw wrote
On Jan 25, 2015, at 1:26 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-01-24 22:34-0500 Jim Dishaw wrote:
Also, I would like to rewrite plAlloc2dGrid to use only one alloc
because the multiple alloc algorithm that is currently used is
unnecessary, slower, and on some OSes
The memory leak appears to be a malloc that is used to handle unicode
characters. I don't think that malloc is required and I will fix the code to
take it out.
On Jan 23, 2015, at 5:50 AM, Phil Rosenberg p.d.rosenb...@gmail.com wrote:
Hi Laurent
The wxWidgets driver is currently undergoing
On Jan 24, 2015, at 11:51 AM, Phil Rosenberg p.d.rosenb...@gmail.com wrote:
Your recent commits to this topic did solve the memory management
issue at exit that was reported by valgrind. However, there appear to
still be lots of sources of allocated memory that need to be freed on exit.
I
Question 1:
Do we want the ability to read plmeta files to be always available in the
library or be available only when the plmeta driver is built?
Question 2:
Do we want the ability to create a plmeta file when a different driver is
selected?
For example, the user want to use a GUI driver
I was digging into the memory leak that occurs in plbuf, specifically in
rdbuf_text(). An array is allocated to store the unicode characters that were
stored in the buffer so that it can be replayed (e.g. during a resize event).
There are several ways to fix this problem.
1) Add a free() at
In the src/pdfutils.c file (pdf = portable data files) there exists functions
that allocate, free, and find the min/max for 2d matrices. The functions do
not read or write any data files and these functions are used in
src/plot3d.c
src/plvect.c
src/plimage.c
src/pllegend.c
src/plgradient.c
On Jan 14, 2015, at 11:32 AM, Phil Rosenberg p.d.rosenb...@gmail.com wrote:
This slightly breaks the chain, but Jim just sent me a patch for adding
colourmaps to the buffer. These include a call to plP_state at the end just
as in plscmap#. My question is, what should a drivers respons
I wanted to summarize the requirements for the changes that we have been
discussing
1) Fix plmeta
2) Fix plbuf so that colormaps (e.g. plscmap0) are saved
3) Change the data type for coordinates in plbuf to PLINTERNAL (which will be
set to short for the time being)
4) Implement plot buffer
, at 10:37 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2015-01-13 22:00-0500 Jim Dishaw wrote:
5) Implement command line switches for plot buffer output (-mfo) and input
(-mfi)
8) Fix plrender
@Jim: Thanks for that summary which leads me to a question for both you
and Phil:
Just
With the the changes to plbuf that need to be made to implement these features,
should the old code that was left in (the ifdef BUFFERED_FILE blocks) be
removed? The only time it is useful is on low memory machines that have the
ability to perform file I/O.
I'm not clear on the need to
When the buffer needs to reallocate, it grows by a multiple of a fixed amount
(plbuf_buffer_grow). The multiple is computed such that the growth is large
enough to meet the demand.
plbuf_buffer_grow = 128KB (set in plbuf_bop)
growth_multiplier = (top_of_buffer + needed_space - size_of_buffer)
much more
difficult or not very platform independent or both. For now don't worry about
it. I will mull things over and see what I can think of as the best way to do
this.
Phil
On 9 January 2015 at 14:42, Jim Dishaw j...@dishaw.org wrote:
I believe those BUFFERED_FILE blocks are from
I believe those BUFFERED_FILE blocks are from the patches I submitted years ago
that implemented the memory buffer.
Prior to that patch, Plplot used a temporary file to buffer plot commands
(using a plplot internal command set). Those temporary files would often get
left behind on abnormal
I have been using a module that acts as a shim between the software I write and
PLplot. I wrote it when I migrated from using ArrayView on Digital's Fortran
compiler to the Intel and GNU compilers. I don't know if it would be useful,
but I'm willing to share with interested parties in case
Unless the memory calls have changed, the raw pointers was something I
implemented 5+ years ago when I submitted a patch to transition away from
temporary files.
The design goal I had in mind was speed, to keep the implementation portable,
and to make the memory buffers agnostic to the data.
Werner Smekal [EMAIL PROTECTED] writes:
Hi Alan,
We need a volunteer to step forward to change example 21 in C so that it
uses a simple random number generator that is internal to the example
(perhaps something extremely simple but reasonably effective if you pick a
good seed such as the
I have put a binary version of the plplot library that has my new MS
windows driver (mswin) at http://dishaw.org/plplot/. Once I finish a
couple of details, I will work on getting patches into the SVN tree.
Any feedback or comments are welcome.
Werner Smekal [EMAIL PROTECTED] writes:
We could gather this infos in the wiki and create therefore an
abstract reference driver. In the future it would be easier to write
drivers, since there is a reference.
What do you think about that? Apart from that you may think this is a
good idea
Arjen Markus [EMAIL PROTECTED] writes:
Hello,
Stefan Menzel reported a bug (plplot-Bugs-1973336) regarding plotting
a single pixel. This is a special case in plpoin (where the value of
the argument code is -1).
The wingcc driver does not plot anything, whereas the GD driver does
(at least
After a long absence on Plplot development, I decided to cleanup my
patches and get them worked back into the main trunk. Some of these
patches were submitted previously, however, they didn't seem to make it
into the trunk.
First, the fortran 95 bindings are still a bit goofed up when using
Arjen Markus [EMAIL PROTECTED] writes:
Jim Dishaw wrote:
Second, I have a better way of generating the plflt.inc file that avoids
building an executable and uses the C preprocessor instead. My CMake
edit is a crude and could be refined. Anyone care to help out?
Certainly, let me see
Hiroyasu Yasuda [EMAIL PROTECTED] writes:
On 2007/11/01, at 12:37, Jim Dishaw wrote:
I sometimes tried to run camke with below options in another fresh
build tree, but a make install command wrote the files in buildplplot/
install. How to specify install folder ?
-DCMAKE_INSTALL_PREFIX
I tried to create an account to edit the wiki and failed miserably. I
might try again later, but I could not get past the CAPTCHA--I guess I
am not human...
-jd
-
This SF.net email is sponsored by: Splunk Inc.
Still
Hiroyasu Yasuda [EMAIL PROTECTED] writes:
When I built plplot on Cygwin at the first time, make install command
was automatically installed plplot files which doesn't work to /usr/
local/bin. So there are plplot folders in that location even now. How
to install new working plplot files
Alan W. Irwin [EMAIL PROTECTED] writes:
I have changed the suffix of dynamic drivers to .dll in the Cygwin case for
revision 7989. Could you please finish the experiment with this revision?
That is set LD_LIBRARY_PATH, do the complete build again, then finish with
the installed examples build
Alan W. Irwin [EMAIL PROTECTED] writes:
Hiroyasu, I am hoping that you, Arjen, and Jim all do the requested test 2
for svn trunk with complete error report since if a problem exists it may
depend on what version of dynamic loading libraries each of you have
Did my email make it to the list
Alan W. Irwin [EMAIL PROTECTED] writes:
On 2007-10-24 21:39-0400 Jim Dishaw wrote:
Jim Dishaw [EMAIL PROTECTED] writes:
Alan W. Irwin [EMAIL PROTECTED] writes:
Jim, please correct me if you have a different experience, but my
belief is the environment variable approach is going to set
Alan W. Irwin [EMAIL PROTECTED] writes:
On 2007-10-25 19:53-0400 Jim Dishaw wrote:
When I build with svn revision 7974 and have BUILD_SHARED_LIBS=ON and
ENABLE_DYNDRIVERS=OFF I get the following error during make
[ 0%] Building C object lib/csa/CMakeFiles/csirocsa.dir/csa.o
/usr/bin
Alan W. Irwin [EMAIL PROTECTED] writes:
Hi Jim,
This post covers one final topic generated by your e-mail.
On 2007-10-25 19:53-0400 Jim Dishaw wrote:
$ cmake -DBUILD_SHARED_LIBS=ON -DENABLE_DYNDRIVERS=OFF
-DCMAKE_VERBOSE_MAKEFILE=ON -DDEFAULT_NO_DEVICES=ON -DPLD_ps
Alan W. Irwin [EMAIL PROTECTED] writes:
Hi Jim:
I suspect the fix is pretty straightforward, but to make further progress
with this on the CMake list, you will need to put together a simple complete
CMake example to illustrate the problem. Such an example has already been
prepared at
Alan W. Irwin [EMAIL PROTECTED] writes:
On 2007-10-21 21:49-0400 Jim Dishaw wrote:
The problem is that CMake sees the Intel Visual Fortran installation and
sets the compiler flag /DIVF and that causes the GNU compiler to
fail.
Jim, please correct me if you have a different experience
Hiroyasu YASUDA [EMAIL PROTECTED] writes:
On 2007/10/18, at 5:27, Alan W. Irwin wrote:
On 2007-10-17 08:01-0400 Jim Dishaw wrote:
I think part of the problem is pointed out by the /DIVF message.
The cmake program thinks that your Fortran compiler is Intel Visual
Fortran
Alan W. Irwin [EMAIL PROTECTED] writes:
One downside of OpenDisc appears to be they do not yet distribute PLplot for
windows. :-( Could one of our windows developers please contact them about
this omission?
Having successfully completed my dissertation defense, I have started
back up my
Alan W. Irwin [EMAIL PROTECTED] writes:
My own feeling is we should do at least one more development release,
5.7.4, ... and a new windows device driver (Jim Dishaw).
I defintely concur about having one more developmental release. I will
not have the windows driver release quality until
Alan W. Irwin [EMAIL PROTECTED] writes:
However, your general comments on interactive PLplot struck a nerve with me.
In my opinion where PLplot does very poorly on the interactive front is the
severely limited interactive GUI devices that have been implemented so far.
I agree, but I think it
Attached is a patch for fixing Fortran 95 support for Intel Fortran.
This patch applies changes that was previously applied to the f77
bindings.
On a related topic, to make the library more flexible on the Windows
platform, the /Zl option (no default library) should be specified
instead of /MD or
In my attempt to get Fortran built correctly using the Intel compiler I
noticed a problem with the compiler flag string.
I used the following cmake command
C:\cygwin\opt\cmake-2.4.5-win32-x86\bin\cmake ^
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=Debug ^
-DCMAKE_INSTALL_PREFIX=\opt\test
Attached is a patch that gets plplot building correctly with the Intel
Fortran compiler. It still doesn't link correctly because of the
mismatch in runtime libraries. I'm not enough of a cmake guru to track
that down. Maybe some can read my previous message about win32
libraries and suggest a
Has anyone had success in building the shared library version on win32
using Visual Studio (or any compiler)--I encounter two problems. The
first problem occurs if I do not build the static version first
(-DBUILD_SHARED_LIBS=OFF)
/out:..\..\dll\plplotf77d.dll /dll /STACK:1000 /machine:I386
I noticed that the Bug tracker has some outdated entries, who is
responsible for maintaining the bug database?
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
Werner Smekal [EMAIL PROTECTED] writes:
A windows script would be easy to write with windows commands apart from
the tar stuff - zip should be used on the windows platform and than we
would need a zip program also :) (which we would get via
gnuwin32.sf.net). Anyway, Jim was already able
Alan W. Irwin [EMAIL PROTECTED] writes:
On 2006-12-15 09:56+0100 Werner Smekal wrote:
There are two issues here (and a third one below):
(1) Working out the current bugs in the package target. I suggest you first
do that with your MinGW platform since that is obviously an important
Andrew,
I was just about to write a patch for freeing plbuf_buffer and I saw
that you had beaten me to the punch. The question that I have is
whether plP_tidy is the best place. I note that plP_tidy is called by
c_plend1() and plGetFam(). The plGetFam() function gets called by the
driver bop
Andrew Ross [EMAIL PROTECTED] writes:
I've just fixed a bug in plbuf.c to do with memory allocation which
caused example 20 to crash with a segmentation fault. There was also
an associated memory leak. Looking back at various old versions I have
compiled up here this bug must have been
101 - 176 of 176 matches
Mail list logo
