On 2015-02-23 13:18-0800 Alan W. Irwin wrote:
> On 2015-02-23 10:48-0500 Jim Dishaw wrote:
>> The tests appear to run correctly; however, there were several
> compiler warnings (Apple LLVM version 5.0) that I have not seen with
> gcc (version 4.7.2). I have attached the test_diff_psc.out.
>
> Tha
gt;>> wrote:
> >>> Hi Jim
> >>> There is already a way to do it via pl_cmd. It's just a question of when
> >>> it
> >>> needs to be done. I will look to see if it is possible to do before plinit
> >>> and store the wxDC bu
>>> needs to be done. I will look to see if it is possible to do before plinit
>>> and store the wxDC buffer until plinit is called.
>>>
>>> Phil
>>>
>>> From: Jim Dishaw
>>> Sent: 27/02/2015
Phil
>> ________
>> From: Jim Dishaw
>> Sent: 27/02/2015 01:27
>> To: Phil Rosenberg
>> Cc: Alan W. Irwin; PLplot development list
>> Subject: Re: [Plplot-devel] Redesigned wxWidgets Driver
>>
>> Have you considered a function an
; and store the wxDC buffer until plinit is called.
>
> Phil
>
> From: Jim Dishaw
> Sent: 27/02/2015 01:27
> To: Phil Rosenberg
> Cc: Alan W. Irwin; PLplot development list
> Subject: Re: [Plplot-devel] Redesigned wxWidgets Driver
>
>
/2015 01:27
To: "Phil Rosenberg"
Cc: "Alan W. Irwin" ; "PLplot development list"
Subject: Re: [Plplot-devel] Redesigned wxWidgets Driver
Have you considered a function analogous to plsfnam() that can be used to pass
the wxDC? It could be useful for other drivers and no
Have you considered a function analogous to plsfnam() that can be used to pass
the wxDC? It could be useful for other drivers and not specific to wxWidgets.
> On Feb 26, 2015, at 3:30 PM, Phil Rosenberg wrote:
>
> Hi All
> I have hit a bit of a snag with the wxWidgets driver and would like s
That's the answer I needed. I shall have to find another way then.
Cheers Alan
-Original Message-
From: "Alan W. Irwin"
Sent: 26/02/2015 22:08
To: "Phil Rosenberg"
Cc: "PLplot development list"
Subject: Re: [Plplot-devel] Redesigned wxWidgets
Hi Phil:
I am pretty tired right now (too little sleep) so I may just be
missing something obvious below, but since I currently don't
completely understand what you ware saying, I thought I had better
inject some questions and comments below in context to give
you a chance to clarify what you mean
Hi All
I have hit a bit of a snag with the wxWidgets driver and would like some advice.
At some point the driver has to make a decision as to whether the user
is going to pass the driver a wxDC to draw on, or whether the driver
has to execute wxPLViewer to do the drawing.
An ideal point to do tha
On Wed, Feb 25, 2015 at 12:16:02PM +, Phil Rosenberg wrote:
> Hi Alan
> >
> > It appears there are two remaining release-critical issues.
> >
> > 1. You should do one last check of Ubuntu and CentOS to make sure my
> > recent drop of explicit linking to the rt library does not cause
> > problem
Would you send the backtrace and line number where the error occurs.
I wonder if filling in a curved area is overflowing the control point array?
I'm grasping at straws.
> On Feb 25, 2015, at 8:40 AM, Phil Rosenberg wrote:
>
> Hi Jim
> I doubt there are very many control points example 13
On 2015-02-25 09:57-0500 Jim Dishaw wrote:
> Would you send the backtrace and line number where the error occurs.
>
> I wonder if filling in a curved area is overflowing the control point array?
> I'm grasping at straws.
To Phil and Jim:
@Both:
I tried extensive resizing for both examples 13
Hi Jim
I doubt there are very many control points example 13 is just a simple
pie chart. The crash is immediate, not on a redraw. I wondered if it
could be related to overflowing some buffer when writing to the
plbuffer as this writing occurs during plP_fill - it only happens when
a hatching is us
I think you need to use the -g flag to get symbolic information.
> On Feb 25, 2015, at 11:06 AM, Phil Rosenberg wrote:
>
> Hi Jim
> Here is the backtrace. I had thought that setting CMAKE_C_FLAGS to -d
> would give line numbers, but apparently it doesn't, so the backtrace
> just has addresses
Hi Jim
Here is the backtrace. I had thought that setting CMAKE_C_FLAGS to -d
would give line numbers, but apparently it doesn't, so the backtrace
just has addresses
*** glibc detected *** examples/c++/x13: double free or corruption
(!prev): 0x01fcb720 ***
=== Backtrace: =
/lib6
Is it crashing on the initial draw or after a resize? If it is the latter, it
might be something that the plot buffer does.
There are some mallocs that happen prior to plP_fill if there are a large
number of control points in the fill. Do you know how many there are when it
crashes?
> On Fe
On 2015-02-24 20:20- Phil Rosenberg wrote:
> Hi Alan
> Both example 13 and 15 give some very odd behaviour with xwin on my
centos machine. 13 crashes with a very large error message, 15 hangs
with only a small section rendered.
Hi Phil:
I have run
examples/c/x13c -dev xwin
examples/c/x15c
berg"
Cc: "Jim Dishaw" ; "PLplot development list"
Subject: Re: [Plplot-devel] Redesigned wxWidgets Driver
On 2015-02-24 17:55- Phil Rosenberg wrote:
> Hi Alan et al
> I have updated the bug report on SF. A number of the issues are now
> fixed. I'm not
Hi Alan
>
> It appears there are two remaining release-critical issues.
>
> 1. You should do one last check of Ubuntu and CentOS to make sure my
> recent drop of explicit linking to the rt library does not cause
> problems on those platforms. (And if it does, a one-line change
> should fix it).
I
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?
>
I was looking at the patch and I wonder if the approach is a bit fragile.
There was a similar issue when plplot used tem
On Feb 24, 2015, at 12:58 PM, Phil Rosenberg wrote:
>> librt is not available on Mac OS X nor is it in MacPorts. Which function
>> are we pulling in from librt?
>
> I think (and I might be misremembering) that this is required either
> for the memory map or for the named mutexes. If this libr
Hi Alan et al
I have updated the bug report on SF. A number of the issues are now
fixed. I'm not sure I will have time nor if I should start fixing any
more of these before the release deadline. The ones that concern me
most are:
super/subscript problems
Aspect ratio issues
hatchings
inline text c
th a very large error message, 15 hangs with only a
> small section rendered.
>
> Phil
> From: Alan W. Irwin
> Sent: 24/02/2015 19:51
> To: Phil Rosenberg
> Cc: Jim Dishaw; PLplot development list
> Subject: Re: [Plplot-devel] Redesigned wxWidgets Driver
>
>
On 2015-02-24 10:20-0500 Jim Dishaw wrote:
>> I am virtually positive that [commit] will solve the above linking issue,
>> but let
>> me know how it goes, and if that linking works how much further you get.
>
> I updated from the git repository and now got the following error:
>
> Linking CXX exe
> librt is not available on Mac OS X nor is it in MacPorts. Which function are
> we pulling in from librt?
I think (and I might be misremembering) that this is required either
for the memory map or for the named mutexes. If this library is not
available then we are going to need an os specific s
On Feb 24, 2015, at 4:35 AM, Phil Rosenberg wrote:
>> I am a bit concerned by your use of the clang compiler which as far as
>> I know has never been used before for building or testing PLplot on
>> any platform.
>
> Alan - I seem to remember reading that clang has replaced gcc as the
> comp
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
On 2015-02-24 13:35-0500 Jim Dishaw wrote:
>
> On Feb 24, 2015, at 12:58 PM, Phil Rosenberg wrote:
>
>>> librt is not available on Mac OS X nor is it in MacPorts. Which function
>>> are we pulling in from librt?
>>
>> I think (and I might be misremembering) that this is required either
>> for t
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
> I am a bit concerned by your use of the clang compiler which as far as
> I know has never been used before for building or testing PLplot on
> any platform.
Alan - I seem to remember reading that clang has replaced gcc as the
compiler used by XCode on mac, it is therefore probably the default
(o
On 2015-02-24 17:55- Phil Rosenberg wrote:
> Hi Alan et al
> I have updated the bug report on SF. A number of the issues are now
> fixed. I'm not sure I will have time nor if I should start fixing any
> more of these before the release deadline. The ones that concern me
> most are:
>
> super/s
On 2015-02-23 23:18-0500 Jim Dishaw wrote:
> 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
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 2015-02-23 21:51- Phil Rosenberg wrote:
> Hi Alan and Jim
> I just tested the patch on my Centos machine and got the following build error
>
> make[3]: *** No rule to make target `/usr/lib64/libltdl.so', needed by
> `src/libplplot.so.12.0.1'. Stop.
>
> make[2]: *** [src/CMakeFiles/plplot.di
Hi Alan and Jim
I just tested the patch on my Centos machine and got the following build error
make[3]: *** No rule to make target `/usr/lib64/libltdl.so', needed by
`src/libplplot.so.12.0.1'. Stop.
make[2]: *** [src/CMakeFiles/plplot.dir/all] Error 2
make[1]: *** [utils/CMakeFiles/wxPLViewer.d
On 2015-02-23 10:48-0500 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 get when you build
>> the CMake software package. So I presume you did have success
>> bu
On 2015-02-23 10:37-0500 Jim Dishaw wrote:
I had the same problem with "git am" (which uses "git apply" from what I understand). I did a "git
fetch" and "git merge" before "git am"
bash-3.2$ git am --whitespace=warn ../mbox
Applying: Redesigned wxWidgets Driver
/Volumes/home/Users/jim/Devel
uot; ; "Phil Rosenberg"
Cc: "PLplot development list"
Subject: Re: [Plplot-devel] Redesigned wxWidgets Driver
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:
&g
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 get when you build
>> the CMake software pack
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 that is a really good result.
>
> Wha
I had the same problem with "git am" (which uses "git apply" from what I
understand). I did a "git fetch" and "git merge" before "git am"
bash-3.2$ git am --whitespace=warn ../mbox
Applying: Redesigned wxWidgets Driver
/Volumes/home/Users/jim/Development/plplot/plplot-plplot/.git/rebase-apply
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
correct "git am"]).
Hi Jim:
I prepared this (one-patch) patch series with "git format-patch". I am
pretty sure you sh
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 --
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?
>
@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?
More below in context.
On 2015-02-22 10:39- Phil Rosenberg wrote:
Hi Alan
Great detective work!!!
In response to yo
>> why does plplotMemoryMapAA and
>> plplotMemoryMapVDXVDZXFQI always appear to succeed and
>> plplotMemoryMapQQ always appear to fail?
>>
Forgot to answer this - my response though is that I have no idea!
--
Hi Alan
Great detective work!!!
In response to your question, why do we need a random name? If there
is already an instance of wxPLViewer running or if there is another
example running and we try to create another instance we will try to
generate another region of shared memory with the same name,
On 2015-02-21 21:25- Phil Rosenberg wrote:
> Hi Alan
> I have fixed the valgrind warning. It turned out to be nothing much
> just checking characters after the \0 in a string, but before the end
> of the memory allocation and replacing them with random letters if
> they were ?. It saw all char
Hi Alan
I have fixed the valgrind warning. It turned out to be nothing much
just checking characters after the \0 in a string, but before the end
of the memory allocation and replacing them with random letters if
they were ?. It saw all characters after the \0 as uninitialized. See
my latest commit
Cheers Alan
Thanks for the check for multiple instances.
I have done a similar thing already on Trello so I have a list of
items. I will knock them off as I go on the bug report too.
Phil
On 21 February 2015 at 19:40, Alan W. Irwin wrote:
> Hi Phil:
>
> I have just opened https://sourceforge.ne
Hi Phil:
I have just opened https://sourceforge.net/p/plplot/bugs/151/ to keep
track of the various issues (either due to plbuf or wxwidgets)
that show up by exercising the various standard examples with -dev
wxwidgets. I have tried to merge all issues that have been mentioned
on list that my exp
On 2015-02-21 18:06- Phil Rosenberg wrote:
> Hi Alan
> Thanks for that. I tested under Windows and Linux and saw no issues, but I
> guess that was fluke.
> Out of interest is it possible you have more than one instance of
wxPLViewer running at once? I wonder if the memory maps could be
clash
Phil
-Original Message-
From: "Alan W. Irwin"
Sent: 21/02/2015 17:45
To: "Phil Rosenberg"
Cc: "PLplot development list"
Subject: Re: [Plplot-devel] Redesigned wxWidgets Driver
Hi Phil:
I am testing current master tip (c3fed1f, "Undid changes&quo
Hi Phil:
I am testing current master tip (c3fed1f, "Undid changes"), but
that recent commit from you has not fixed the intermittent memory
issue. To illustrate, here is a run of repeat attempts for standard
example 1, where the first 3 are fine, but the last one failed:
software@raven> examp
On 2015-02-14 13:28-0800 Alan W. Irwin wrote:
> [] I also noticed A "no such file" message
> when I attempt to move to beyond the first page of the example 20
> plot, but that now occurs for all devices so I am pretty sure this is
> a master branch regression and nothing to do with wxwidgets/
On 2015-02-14 22:50- Phil Rosenberg wrote:
> Let me know which (pgup/pgdn or enter) you prefer.
Replace with enter for now (and add the exit functionality when enter
is struck with no pages left) to be consistent with all the rest of
our devices and what was done for the old wxwidgets device.
Hi Phil:
On 2015-02-14 13:28-0800 Alan W. Irwin wrote:
> IMPORTANT... I strongly encourage you to go ahead and push
> this whole integrated series of commits to master.
Glad to see you did this.
> * Examples 8, 11, 16, 19 (last page),
> 20 (at least first page), 21 (second page), 24, 25, 27 (so
On 2015-02-14 13:44-0800 Alan W. Irwin wrote:
> Once that push happens, you should simply create a new topic branch
> from the master tip, and then make your further changes beyond what
> you sent us already.
@Jim: If you have not subscribed already to the git feed then you
should do so now (by l
Done - I've pushed the changes
So Jim as Alan said, feel free to pull from the repo. I guess you
should then be able to rebase your working branch onto that.
I will work to fix the bugs over the next week or so.
> then the highest priority for me would be the page navigation fix
Here you have a
On 2015-02-14 16:10-0500 Jim Dishaw wrote:
> Sure. First I need to figure out if I should rebase my branch to
yours or if I should use your branch and patch. Any suggestions?
It hasn't happened yet, but I have given Phil the strong encouragement
to push his integrated patch series (which contains
On 2015-02-14 20:54- 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 whether it
> is
> The attached patch should include all our commits and the conflict
> fix. Jim and Alan and anyone else interested in testing this can you
> please do the following steps
> git checkout master
> git fetch
> git merge origin master --ff-only
> git branch wxAndBufTestMaster
> git checkout wxAndBufTe
> 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
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 whether it
is a wxWidgets driver issue or a buffer issue - this is jus
On 2015-02-14 10:16-0800 Alan W. Irwin wrote:
> On 2015-02-14 14:52- Phil Rosenberg wrote:
>
>> Hi Alan
>> I think our emails crossed - or at least I didn't see yours before I
>> sent mine. However I think what I said in my last email still stands.
>> If we all use the merged patch as a basis
On 2015-02-14 14:52- Phil Rosenberg wrote:
> Hi Alan
> I think our emails crossed - or at least I didn't see yours before I
> sent mine. However I think what I said in my last email still stands.
> If we all use the merged patch as a basis for future work on this
> topic then we can all be hap
Hi Alan
I think our emails crossed - or at least I didn't see yours before I
sent mine. However I think what I said in my last email still stands.
If we all use the merged patch as a basis for future work on this
topic then we can all be happy, and when I commit some or all of this
patch to master
On 2015-02-14 08:27- Phil Rosenberg wrote:
> Hi Alan and Jim
>
> I tried applying the patches on my system and they failed too. In fact
> my patch wouldn't apply at all, even on a clean branch. It had
> whitespace errors and a commit that changed the case of a filename,
> which confused git on
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
On 2015-02-13 17:19- Phil Rosenberg wrote:
> Just to prove Alan right that Jim and I are close to tied in terms of
> getting our changes made I have attached a patch containing the new
> wxWidgets driver.
> I have done quick tests only on Windows Centos and Ubuntu, although I
> made a few chan
Okay, I have fixed the linkage error in wxPLViewer, so please ignore
my last patch. I am now getting some runtime problems with dlls, but
at least I am making progress.
Phil
On 12 February 2015 at 15:59, Phil Rosenberg wrote:
> Hi All
> This patch contains the new wxWidgets driver so far. This i
> Or are you referring to the fact there is no such core routine at the
> moment to set plsc->LocateEH, and more importantly nobody including me
> has volunteered to write such a user-supplied locate mode handler so
> therefore this is all hypothetical?
Exactly
>
> I do agree it is all hypothetic
On 2015-02-12 09:42- Phil Rosenberg wrote:
> Hi Alan
> Thanks for the comments.
>
> Just one more question re LocateEH. There appears to currently be no
way for this callback to be set by the user, or have I missed
something?
There is a pointer to a user locate mode handler in the PLStream
s
ot;
Cc: "Jim Dishaw" ; "plplot-devel@lists.sourceforge.net"
Subject: RE: [Plplot-devel] Redesigned wxWidgets Driver
On 2015-02-11 21:31- Phil Rosenberg wrote:
> @Alan
> The wxWidgets driver is nearly done now.
That is excellent news.
> The last part is just
pu
On 2015-02-11 21:31- Phil Rosenberg wrote:
> @Alan
> The wxWidgets driver is nearly done now.
That is excellent news.
> The last part is just
putting posix named semaphores in where I have used windows named
mutexes. So I have a few questions
> 1) Do you want another patch to try before I
2/2015 17:17
To: "Phil Rosenberg"
Cc: "Alan W. Irwin" ;
"plplot-devel@lists.sourceforge.net"
Subject: Re: [Plplot-devel] Redesigned wxWidgets Driver
On Feb 10, 2015, at 10:07 AM, Phil Rosenberg wrote:
> Hi Alan, Jim and all
>
> I have had to rework s
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
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 shared memory and synchronisation of this resource
via mutexes, th
Hi Alan and Jim
Just a further note:
>One extremely interesting result was for example 4 which segfaulted
>when GUI->File->exit was executed despite no memory management issue
>reported by valgrind.
This occurs due to some sort of buffer corruption. I haven't looked
into the details yet, however,
>I haven't tried
>
>export CC=gcc
>export CXX=g++
>
>in a while, but they used to always "just work" for me
To be honest it wouldn't surprise me if it is linked to how the intel
compiler is installed on my system. I can probably remove it as we
have a distributed system and the applications are in
On 2015-01-24 16:51- Phil Rosenberg wrote:
> Hi Alan
> I'm replying to this without my code in front of me, but I wanted to
> keep you informed.
>
>> you can use the CC and CXX environment variables
>> _before_ you invoke cmake in an empty build directory, e.g.,
>>
>> export CC="gcc -g"
>> exp
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
Hi Alan
I'm replying to this without my code in front of me, but I wanted to
keep you informed.
>you can use the CC and CXX environment variables
>_before_ you invoke cmake in an empty build directory, e.g.,
>
>export CC="gcc -g"
>export CXX="g++ -g"
I tried that without the -g but it had no effec
On 2015-01-23 10:41- Phil Rosenberg wrote:
Hi Alan
Thanks for your tests, they are very useful. I have made some further
changes and attached a new patch. As I know you like interleaved
posting so much I will try to go through point by point ;-)
Thanks for that kindness. :-)
Just as
Hi Phil:
I took some further steps to test your rewritten wxwidgets device code.
1. I epa_built wxwidgets 3.0.0 on Linux. After one epa_build issue
was fixed (the URL for the ragel source code tarball had been
changed), that build went smoothly (although it took ~45 minutes to
complete).
2. I t
best to answer them.
Again, thank you all for the work!
Best regards,Joost KuckartzPhD Candidate, The University of Melbourne, Australia
> Date: Thu, 22 Jan 2015 13:45:18 -0800
> From: ir...@beluga.phys.uvic.ca
> To: p.d.rosenb...@gmail.com
> CC: plplot-devel@lists.sourceforge.net
> Subject
On 2015-01-21 22:05- Phil Rosenberg wrote:
> Forgot to mention
> As you can imagine this has been rather a large project with many
> commits. I have had to make commits on my windows machine then pull
> them to my Linux machine, debug, push back, more debugging, etc. for
> this reason there ar
On 2015-01-21 22:01- Phil Rosenberg wrote:
>> I suggest you create a patch with git format-patch and send it to this
list via an attachment
Attached, any feedback, good or bad is very welcome.
Hi Phil:
Here is what I did from the git perspective (for anyone else
who wants to try your wor
Forgot to mention
As you can imagine this has been rather a large project with many
commits. I have had to make commits on my windows machine then pull
them to my Linux machine, debug, push back, more debugging, etc. for
this reason there are certainly some commits that will not build,
particularly
On 2015-01-20 10:59- Phil Rosenberg wrote:
> Hi All
> The basic redesigned wxWidgets driver with wxWidgets display being
> performed in a separate process is nearly ready. I am aware that we
> currently do not have the file/shared memory interface ready yet, so I
> have just implemented a rath
Hi All
The basic redesigned wxWidgets driver with wxWidgets display being
performed in a separate process is nearly ready. I am aware that we
currently do not have the file/shared memory interface ready yet, so I
have just implemented a rather quick minimal shared memory routine
that shares the buf
92 matches
Mail list logo
