That would be my preference too in an ideal world. However that change would then need propagation to all the other bindings, which is unlikely to be feasible on the timescales of this release cycle.
On 27 February 2015 at 14:06, Jim Dishaw <j...@dishaw.org> wrote: > I vote for option 1 because it mirror the philosophy of plsfnam() and I think > it is useful for the windowed drivers. When I wrote a new Windows driver, I > thought something like this would be handy if someone wanted to embed a plot > in a window that was part of an application. > > I think the impact to the API is low and the payoff is high. Option 2 > changes when pl_cmd should be used, which needs careful thought. Also, we > would need to evaluate the commands and place a table in the documentation to > identify which ones work before and after initialization. > > > >> On Feb 27, 2015, at 7:48 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: >> >> Okay, I am really struggling with this. Jim is pretty much correct. >> >> I had thought I would be able to use pl_cmd() before calling plinit to >> store the data I needed. However this causes a segfault because the >> dispatch table is not initialised. >> >> I know this is really late in the day for this stuff, but it could be >> a game changer for the wxWidgets driver. >> >> Basically I need to have some way to pass some data into plplot so >> that it is available to the driver on initialisation or at least >> before the first call to the driver's bop function. I've come up with >> three options, feedback very welcome as I'm tearing my hair out with >> this. >> >> 1) Create a new public API function called plsDevData which can be >> called before plinit to stash a pointer to the data. >> 2) Add a check in pl_cmd for PLESC_DEVINIT op and if I find it then I >> stash the data away, then if plsc->level < 1 I return out. This has >> the advantage that pl_cmd is the current way to pass the data in, but >> has been done after plinit up to now. >> 3) Hijack blsbopH to pass the data in. This is a blatant hack and >> misuse of the function, this is not really great for readability, and >> if any user is actually making use of this function (despite its >> undocumented status) then it will mess them up or even cause segfaults >> in existing code. >> >> Like I say I am pulling my hair out over this so feedback or >> suggestions really appreciated. If I don't hear back then I will >> probably go for option 2 as the best compromise between amount of >> work, usability and affecting existing code. >> >> Phil >> >>> On 27 February 2015 at 09:09, Phil Rosenberg <p.d.rosenb...@gmail.com> >>> 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 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 >>> >>> 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 <p.d.rosenb...@gmail.com> >>>> wrote: >>>> >>>> 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 that would be the first call to plP_bop(). It >>>> feels right that at this point when the first rendering begins to >>>> clear the page that by this point the decision should be made and >>>> technically if we leave it until after this point then we have to >>>> somehow replay the begin of page call, which it turns out can't be >>>> done by simply replaying the buffer. >>>> >>>> However plP_bop() is called from c_plinit, so there is no opportunity >>>> for the user to actually pass in the wxDC. >>>> >>>> To me it would make sense to call plP_bop when pladv() is first >>>> called, i.e. at the point at which the user decides to begin the first >>>> page. This is also symmetric with other calls to plP_bop which happen >>>> at page advances. However I don't know if this is would it totally >>>> mess up other devices? I have looked as carefully as I can and there >>>> doesn't appear to be any requirement within c_plinit for plP_bop() to >>>> be called. >>>> >>>> Any thoughts anyone? >>>> >>>> >>>> On 25 February 2015 at 23:06, Andrew Ross >>>> <andrewr...@users.sourceforge.net> wrote: >>>>> On Wed, Feb 25, 2015 at 12:16:02PM +0000, 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 >>>>>>> problems on those platforms. (And if it does, a one-line change >>>>>>> should fix it). >>>>>> >>>>>> I have checked this on Centos and it works fine. I can check on Ubuntu >>>>>> this evening. >>>>> >>>>> I've checked on my Ubuntu machine and your latest patch fixes things >>>>> again for me. >>>>> >>>>>>> >>>>>>> 2. I haven't experienced xwin crashes myself. Could you give me an >>>>>>> explicit test that fails for you so I can verify this regression? >>>>>> >>>>>> I rebuilt in a new build tree on Centos and I still get this. Sorry I >>>>>> hadn't looked at the error in detail before as I was in the middle of >>>>>> something else. In both case the error is a double free or corruption. >>>>>> In x13c I get a gdb backtrace, which points me to plP_fill, in x15c I >>>>>> just get a segmentation fault message. In x13 and x15 (c++) I get a >>>>>> backtrace which again points to plP_fill. >>>>>> >>>>>> By the looks of it plP_fill has no free calls, so I expect this is >>>>>> some memory overflow or bad pointer issue. As I am using the intel >>>>>> compiler it probably arranges things in memory differently to gcc, so >>>>>> perhaps that is why you aren't seeing this. >>>>> >>>>> As another data point, I do not see this behaviour on Ubuntu 14.10. >>>>> >>>>> Andrew >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Dive into the World of Parallel Programming The Go Parallel Website, >>>> sponsored >>>> by Intel and developed in partnership with Slashdot Media, is your hub for >>>> all >>>> things parallel software development, from weekly thought leadership blogs >>>> to >>>> news, videos, case studies, tutorials and more. Take a look and join the >>>> conversation now. http://goparallel.sourceforge.net/ >>>> _______________________________________________ >>>> Plplot-devel mailing list >>>> Plplot-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
