On 20 January 2016 at 08:47, Jerry wrote:
>
> On Jan 19, 2016, at 5:32 AM, Phil Rosenberg
> wrote:
>
> > I'm perhaps less keen on the idea of using the minimum dimension.
> > Passing unequal sized arrays is clearly and error and so I think we
> > should flag it is such is the loudest way possibl
>From a quick check of one of the Fortran exmples in gtk-fortran, I think
that the problem is that the call is too early. The call to pl_cmd needs to
come AFTER the call to plinit or plstar (it seems counter-intuitive but
that seems to be the case) -- here is the relevant bit from the gtk version
o
If I understand correctly, then this is pretty much what we do in
gtk-fortran where a script is able to parse the gtk+ (along with gdk, glib,
cairo and the other dependencies) headers to make a set of Fortran
interface definitions.
There are only a couple of significant issues that need to be cons
It is still an issue with the cvs tree, so now that I know what's going on
I'll put in a proper bug report. (And also put a warning on the AUR
packages about the incompatibilities).
James
On 8 March 2015 at 16:53, Alan W. Irwin wrote:
> On 2015-03-08 12:53- James Tappin wrote:
include/ImageMagick \
-I/usr/include/python2.7 \
-I/usr/lib/python2.7/site-packages/numpy/core/include" ..
make
but it also happens without the various other options.
James
On 5 March 2015 at 23:03, Alan W. Irwin wrote:
> On 2015-03-05 21:10- James Tappin wrote
:51-0000 James Tappin wrote:
>
> This is just a quick heads-up to say that some of the relatively recent
>> plplot changes mean that the GDL Cmake scripts fail to find the library.
>>
>> I've not had time to check out exactly what has changed and probably won't
>
This is just a quick heads-up to say that some of the relatively recent
plplot changes mean that the GDL Cmake scripts fail to find the library.
I've not had time to check out exactly what has changed and probably won't
for a few days. So if anyone knows what is likely to need doing it might be
wo
Thanks for the advice Alan. I've added a patch file to the AUR package for
plplot, and now gnudatalanguage builds OK.
James
On 17 October 2014 22:39, Alan W. Irwin wrote:
> On 2014-10-17 20:56+0100 James Tappin wrote:
>
> In plConfig.h there is a group of lines:
>>
>
In plConfig.h there is a group of lines:
#ifdef HAVE_CONFIG_H
# include
#endif
which should only get included when building plplot, but when building
other packages (notably gnudatalanguage) HAVE_CONFIG_H is defined with the
result that the build fails because plplot_config.h is not found.
I'm
It works OK here (using the Arch PKGBUILD) on a VM with Manjaro
unstable running on a real machine with Manjaro Stable:
The relevant lines of the commands are:
_svntrunk=http://svn.code.sf.net/p/plplot/code/trunk
_svnmod=plplot
svn co ${_svntrunk} ${_svnmod} --config-dir ./
Which looks to me t
On 29 December 2013 20:53, Alan W. Irwin wrote:
>
> @James: To help guide Andrew's decision, very roughly how long (days,
> months, or years?) do you estimate it will be before the
> gnudatalanguage-cvs version (with the adjustment for our C++
> plstream::wid API breakage) gets officially release
3 18:21, Alan W. Irwin wrote:
> On 2013-12-29 09:48- James Tappin wrote:
>
> Am I right in thinking that even if PL_DEPRECATED is set to ON at build
>> time, the deprecated routines such as 'plwid' are only accessible from C?
>>
>
> Not exactly. For example,
Am I right in thinking that even if PL_DEPRECATED is set to ON at build
time, the deprecated routines such as 'plwid' are only accessible from C?
Even after I had enabled PL_DEPRECATED in the build, the release version of
gnudatalanguage (gdl, 0.9.4) was unable to find the wid method and I could
n
13 matches
Mail list logo
