I say deprecate the old build system for Windows and go to CBS.
Maintaining the extra code is a distraction--we can fold the useful
features of the win3 driver into wingcc. We should preserve the win3
driver name because it makes more sense then wingcc.
If there is interest, we can make a binary
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
"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 imp
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 f
"Alan W. Irwin" <[EMAIL PROTECTED]> writes:
> Werner, if a windows equivalent of the above procedure works, then I suggest
> you put it into a script for convenience (until make package is fixed), and
> that should conveniently take care of the fundamental issue of how to make a
> binary release o
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 ab
Werner Smekal <[EMAIL PROTECTED]> writes:
> * gd library - used for the gd driver (png, jpeg, gif output)
> * freetype library - used for nice font rendering in some drivers (e.g.
> wingcc)
> * qhull library - not sure actually, but I think it is used for
> interpolation in grids, so they look m
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 chan
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 /d
Arjen Markus <[EMAIL PROTECTED]> writes:
> Windows/MSVC 6.0+CVF:
> - Building the library is no problem
> - Building the Fortran examples fails - because of a conflict with
> MSVCRTD.DLL
> (conflicting versions of the runtime libraries - a well-known and
> quite annoying
> problem)
>
Someth
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 fi
"Raul Perez-alejo Neyra" <[EMAIL PROTECTED]> writes:
> thanks to allan for forwarding my message to this mailing list,
> unfortunately we still have problems with the plplot mem driver. We
> want plplot to compose a graphic in memory and then pass it to another
> vector graphic library (cairo). I
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
Arjen Markus <[EMAIL PROTECTED]> writes:
> Jim Dishaw wrote:
>
> we will apply the patch asap, but could you explain a bit about the various
> versions of the libraries you are able to build with the change in compiler
> options? (Intel Fortran is relatively new to me - at
Hazen Babcock <[EMAIL PROTECTED]> writes:
> Jim's work on providing Windows/Intel Fortran binaries reminds me to
> ask about Windows binaries in general. There was talk about creating
> them for each new release and placing them on SourceForge. What is
> the status of this? How about providi
I'm in the midst of a major rewrite of the wingcc driver where I'm
porting the changes I made to the win3 driver into wingcc and fixing
some oddities. The goal is to have a much better windows driver for
those of us who need it and aren't using wxwidgets.
I'm trying to decide if I should submit t
"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 thi
"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 window
"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
Hiroyasu YASUDA <[EMAIL PROTECTED]> writes:
> On 2007/10/17, at 0:04, Alan W. Irwin wrote:
>
>> On 2007-10-16 19:04+0900 Hiroyasu YASUDA wrote:
>>
>>> Dear All:
>>>
>>> I'm trying to install Plplot 5.7.4 on Cygwin, which is the newest of
>>> cygwin on WIndows Xp, according to the Configure PLplot
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 cm
Hiroyasu Yasuda <[EMAIL PROTECTED]> writes:
> On 2007/10/18, at 21:15, Jim Dishaw wrote:
>
>> Hiroyasu YASUDA <[EMAIL PROTECTED]> writes:
>>
>> That message indicates that the fortran library was not built. What
>> files are located in the bindings/f7
"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
>> fai
Jim Dishaw <[EMAIL PROTECTED]> writes:
> "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 compi
"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 l
"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 yo
"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
"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_M
"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
"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 example
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 grepping
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 fi
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 s
Werner Smekal <[EMAIL PROTECTED]> writes:
> I made the decision to copy the whole (actually the part of the buffer
> which contains information) buffer to a new memory buffer. Reason is,
> that there is no obligation to close the stream right after you saved
> the file. If the programmer decide
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
Intel
Arjen Markus writes:
> Jim Dishaw wrote:
>
>>Third, CMake does not provide an option for omitting the default
>>library information when building with MSVC. This is an issue if you
>>want to build a runtime independent library. A runtime independent
>>library is ha
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
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
>
Arjen Markus <[EMAIL PROTECTED]> writes:
> Perhaps we can do this even simpler:
> Use CMake itself to write this file. Whether we use single or double
> precision is controlled via a CMake variable/option, PL_DOUBLE.
> So we can use this to write the one or two lines we need to write.
>
I have at
"Arjen Markus" <[EMAIL PROTECTED]> writes:
>> Arjen Markus <[EMAIL PROTECTED]> writes:
>>
>>> Perhaps we can do this even simpler:
>>> Use CMake itself to write this file. Whether we use single or double
>>> precision is controlled via a CMake variable/option, PL_DOUBLE.
>>> So we can use this to
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
>
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.
---
I just noticed that Absoft is distributing PLplot with the MacOS version
of their compiler--pretty cool.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open
I have been going back and forth on what the default behavior should be
when the pause flag is set (plspause). The options:
1) The advance command has to be given in the specific window that is
displaying the plot where plspause was set.
2) The advance command can be given in any window belongin
I placed an updated binary version of my new MS windows binary at
http://dishaw.org/plplot/
The driver now permits:
- Query the cursor position
- Export the current plot to a file
- Print the current plot (though the size is wrong)
I plan to implement an X11 version once I finish ironing the
impl
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 s
I have tried to find a way to build PLplot on the windows platform
without overriding the CMAKE_C_FLAGS and CMAKE_Fortran_FLAGS with little
success.
Background
When MSVC, IVF and CVF compile (and maybe other windows compilers) code
they insert into the object file the default library information.
Should we consider removing dead code. The one example I van point to
is the removal of the code that used temporary files to buffer the
internal primitives. We implemented a memory based system several
years ago and no one has complained yet. If a file is desired I think
using mmap() wo
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.
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 the
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 ter
gt; of (transport via a network port, or shared memory) are either 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 Januar
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) /
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 prefix
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 ou
10:37 PM, "Alan W. Irwin" 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 que
> On Jan 14, 2015, at 11:32 AM, Phil Rosenberg 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 be to such a
> cha
On Jan 24, 2015, at 11:51 AM, Phil Rosenberg 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 suspect these are
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 wrote:
> Hi Laurent
> The wxWidgets driver is currently undergoing a redesign in preparat
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 t
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 an
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
./bi
On Jan 25, 2015, at 1:26 PM, "Alan W. Irwin" 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, a
likely to be deriving contours and the
> drawing by the drivers and particularly blitting to screen.
>
> Anyway after all this if you still want to go ahead and you are happy
> to check the existing code for bad frees and mallocs that might break
> it then feel free as Alan sai
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 ther
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 wrote:
> 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
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 unr
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.
e so that we include
> the size of the data for every command, even when 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
>
>&g
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 sur
On Feb 6, 2015, at 2:40 PM, "Alan W. Irwin" 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 pe
On Feb 6, 2015, at 5:25 PM, "Alan W. Irwin" wrote:
> On 2015-02-06 15:15-0500 Jim Dishaw wrote:
>
>> On Feb 6, 2015, at 2:40 PM, "Alan W. Irwin"
>> wrote:
>>
>>> On 2015-02-06 08:36-0500 Jim Dishaw wrote:
>>>
>>>>
On Feb 10, 2015, at 10:07 AM, Phil Rosenberg 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
> communication via
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.
--
ut this bug hunt on hold while I work on plmeta
because it does not appear to affect the displayed output.
>>
>> -Original Message-
>> From: "Jim Dishaw"
>> Sent: 06/02/2015 20:16
>> To: "Alan W. Irwin"
>> Cc: "PLplot dev
On Feb 13, 2015, at 3:25 AM, "Alan W. Irwin" 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)
>
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 wrote:
>
>> On 2015-02-13 17:19- Phil Rosenberg wrote:
>>
>> Just to prove Alan right that Jim and I are close t
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 solution
> On Feb 14, 2015, at 3:54 PM, Phil Rosenberg 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 my guess as to wh
Did the patch I sent earlier work?
> On Feb 15, 2015, at 7:43 PM, Alan W. Irwin 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 changes confl
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 bac
On Feb 15, 2015, at 10:35 PM, "Alan W. Irwin" 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
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 wrote:
>
> On Feb 15, 2015, at 10:35 PM, "Alan W. Irwin"
> wrote:
>
>> On 2015-02-15 21:15-0500 Jim Dishaw wrote:
On Feb 16, 2015, at 2:54 AM, "Alan W. Irwin" 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
>
refuse to read it. Then you are free to make whatever changes you need
> 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 compatibilit
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
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 PLESC_IMPORT_
On Feb 17, 2015, at 3:23 PM, "Alan W. Irwin" 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 seri
My plan is to have it done by Friday, perhaps sooner.
> On Feb 18, 2015, at 2:04 AM, Alan W. Irwin wrote:
>
>> On 2015-02-17 22:16-0500 Jim Dishaw wrote:
>>
>>
>>> On Feb 17, 2015, at 3:23 PM, "Alan W. Irwin"
>>> wrote:
>>>
&g
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 s
On Feb 20, 2015, at 4:13 PM, "Alan W. Irwin" 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
>
Yep, will do. I was just setting up to do that today.
> On Feb 22, 2015, at 4:37 PM, Alan W. Irwin 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 CentOS and Ubuntu?
>
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 --
-abort".
On Feb 23, 2015, at 12:23 AM, "Alan W. Irwin" wrote:
> On 2015-02-22 22:04-0500 Jim Dishaw wrote:
>
>> I just cloned from SF and tried to apply the patch with no success
> (see below [where the "git apply" command was used rather than the
>
On Feb 23, 2015, at 12:23 AM, "Alan W. Irwin" 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 tha
Should I use wxWidgets 2.8 or 3.0?
On Feb 23, 2015, at 10:48 AM, Jim Dishaw wrote:
>
> On Feb 23, 2015, at 12:23 AM, "Alan W. Irwin"
> wrote:
>
>> On 2015-02-22 22:04-0500 Jim Dishaw wrote:
>>
>> The ctest and cmake commands are part of what you
On Feb 23, 2015, at 2:50 PM, "Alan W. Irwin" wrote:
>
> Also, I am going to try again to attach the patch to this e-mail, but
> this time in compressed form just in case some software in the mail
> train between us is changing the bits in a pure text attachment. That,
> of course, should not happ
On Feb 24, 2015, at 12:55 PM, Phil Rosenberg wrote:
> Hi Alan et al
>
> Inline text changes probably requires an overhaul of the text
> parsing/buffering so it too intrusive to do now.
> The other two issues may well be internal to the driver, if I get time
> I will look at them, but I'm not
On Feb 24, 2015, at 1:20 AM, "Alan W. Irwin" wrote:
>
>
>>
>> I tested with wxWidgets 3.0 from MacPorts.
>>
>> CMake string:
>>
>> PATH=${PATH}:/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/bin
>> cmake -DCMAKE_INSTALL_PREFIX=/opt/nuclear -DBUILD_TEST=ON ../plplo
1 - 100 of 234 matches
Mail list logo
