On Mon, Apr 27, 2009 at 10:00:38PM -0500, Geoffrey Furnish wrote: > Andrew Ross writes: > > Testing has shown that this is a result of a bug in gfortran versions <= > > 4.1 when both the fortran exit command and the instrinsic exit subroutine > > are used in the same program. I have committed a simple work-around in > > example 20 which should fix compilation for you. Could you check this? > > And the whole build completed without incident. > > So, it looks fixed. Thanks Andrew, for the Fortran tweak, and Alan for the > other config and doc updates.
Geoff, this is good to hear. I've also implemented building the tk examples when BUILD_TEST is enabled which should make testing them easier. I've been using HAVE_PTHREAD=ON for a long time with the xwin driver with no problems. It has certainly been enabled in the debian packages as well with no reported bugs. Based on this I am relatively sure that this bit is ok. The problem is that there is some extra code for handling user supplied windows which is currently only exercised by plframe. I suspect the error is there. Based on this I would like to propose that we disable HAVE_PTHREAD for plframe, but not more generally. We could do this by ensuring that -drvopt usepthread=0 is set in the plframe code. This would mean users don't have to choose between losing very useful functionality with xwin and potentially having a bug in the tk code. I think this is particularly important as the xwin driver is I imagine much more widely used that the tk code. Does this sound acceptable to everyone? > The git business does not have to be as long as shown above. A git master > repo would allow developers to pick up with the "git fetch". The preceding > material is relevant only for developers who are: > > A) trying to track the master svn repo with git-svn, but who do *NOT* want to > work directly in their svn gateway git repo, but instead > > B) want to push the revisions&branches obtained from svn into a "native git" > repo, and simulate that being the master, and > > C) doing their actual work in a git working repo cloned from their "simulated > master git repo". > > I've been making slow but steady progress on figuring out how to set up work > flows that ceneter around a developer having an "svn gateway repo" > (maintained with git-svn). From there you can either work in that repo, or > in some other git repo. There are reasons why people might choose either or > both of those options. > > I haven't yet published a world-accessible git collaboration hub for PLplot, > but am working towards that, and will let people know when it's ready. And > I'm working on documenting how to do practice some work-flow scenarios that > make some sense to me. > > More on all that as it crystalizes. > > Good luck all with the release. I'm probably not going to be good for much > in the next few days due to other committments. Good to hear git is working out. When you are happy perhaps you could let us have details for the wiki? Andrew ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
