the plot area
>
> HDC hdc;// Plot window device context
>
> HPEN pen;// Current pen used for drawing
>
> ...
Thanks,
Greg
On Sun, Dec 31, 2017 at 5:14 AM, Jim Dishaw wrote:
> I think that is a Windows vs Windows 8. I will look a
Hi guys,
Because my main PC (win 7) is busted I am working with a backup system
which is windows 8.1 pro 32-bits
and I was interested in deploying the new wingdi for GDL on windows.
Although no errors were anticipated from the
cmake processing (required setting PLD_wingdi=ON) the build came up
So I found a reference to the discussion about the unicode patching in wx:
https://groups.google.com/forum/#!topic/wx-dev/MTYzgOqLdfU
And here is discussion on including the replacement file in MSYS2:
https://github.com/Alexpux/MINGW-packages/pull/727
On Thu, Dec 15, 2016 at 2:40 PM, Greg Jung
On Tue, Dec 13, 2016 at 2:13 AM, Laurent Berger <
laurent.ber...@univ-lemans.fr> wrote:
> Thanks Greg,
>
> with your patch linking problem is solved. Can you post an answer in this
> question https://forums.wxwidgets.org/viewtopic.php?f=19&t=42882&p=
> 174262#p174262
>
>
>
https://github.com/mayna
I recognize one aspect of your problems in that winundef.h is imperfectly
written and will fail in the case
of using the unicode wxwidgets without explicitly already being unicode
through-and-through - which is what winundef tries to do. Attached is a
fixed version of that file from wx-3.0/wx/msw/
You may need to revise your list of mirrors, 3.4.1 is found on sourceforge
but you may have installed msys when the mirrors were pointed at a
temporary location. I believe repo.msys2.org/mingw/ is preferred these days
but downloads ... sourceforge should be the same:
greg@linux-gc09:/c/msys64/etc
Hi Arjen,
On Tue, Mar 22, 2016 at 11:37 AM, Arjen Markus
wrote:
> Hi Alan,
>
>
>
> (priority 1) I tried to install CMake for MinGW-w64/MSYS2, but that failed:
>
> -According to the package manager there is a version 3.3.1, but
> on installing it naively (via pacman –S cmake), I got CMak
I am comparing what is done in windows using the wincairo driver and
the normal wingdi/wingcc methods, the diagonal line from Cairo looks
quite straight but the gdi-drawn line is jagged.
[image: Inline image 1]
The top-stacked plot uses wincairo while the bottom plot uses the wingdi
(which is wing
kely to be
compliant,
the most tested and consistent. The minority case uses are where issues
are more likely to arise.
On Sun, Feb 7, 2016 at 3:41 AM, Alan W. Irwin
wrote:
> On 2016-02-06 23:09-0800 Greg Jung wrote:
>
> I'd like to make a pitch for maintaining a lower general cmake
I'd like to make a pitch for maintaining a lower general cmake minimum
until
more compelling bug fixes or features are introduced.
I have over 6 platforms standardized on cmake 3.3.2.
Maybe the new version requirement should be restricted to those platforms
where they are needed? And an update m
GDL has had a problem in its use of the wingcc driver in that,
plotting additions to a basic PLOT call do not stick to the plot
when it is moved or resized. I've found that when I stick another
eop() call after each of these plot calls, the problem is "solved"
for this driver https://sourceforge.
and deal with background
> clearing itself and draw the images at the same time.
>
> Phil
> --
> From: Greg Jung
> Sent: 03/02/2016 01:31
> To: Phil Rosenberg
> Cc: Alan W. Irwin ; Jim Dishaw ;
> plplot-devel@lists.sourceforge.net
> Subj
Experimental re-build:
Keeping with 5.11.1, and re-inserting the ::c_plcear() which is in the
winstream::Clear() routine, called at the window creation (new
gdlsindtream, etc.)
actually does not clear the GDL image but instead put up a blank
background, and the painted
image was again revealed w
Hi Phil,
> Greg, can I ask what the specific call order to plplot is and how do
> you end up making use of the buffer in the first place?
I can't identify where the plot buffer is used, I thought it
was used routinely now in 5.11.
> For example do
> you plot with gcc then the error occurs durin
Hi all,
I've been having difficulties under windows with plplot 5.11+
when used with GDL (gnudatalanguage). When I run a test
that exercises 2-d bitmaps and line plots together (test_tv.pro),
I got wrong behavior. I discovered the offense did not happen
for plplot created in December 2014 -
I know that one, it came up for me when building a new shared library
and one of the target_link_libraries() calls included "PRIVATE" as a keyword
(i.e., exactly what it said). I took out the "PRIVATE " and it worked.
What that all means, I don't know! the result worked out for linux.
http://sour
Hi all,
I've been using a static build of the plplot library to build GDL,
in order to have a stable and somewhat unique set of parameters:
> cmake -DCMAKE_INSTALL_PREFIX=/d/bld/plplot/linux/cmake-static \
>
> -DENABLE_DYNDRIVERS=OFF -DDEFAULT_NO_CAIRO_DEVICES=ON
>> -DDEFAULT_NO_QT_DEVICES=ON \
> It didn't seem to want to left me build a pdf device.
To get pdf device you will need the libharu library
https://github.com/libharu/libharu/archive/RELEASE_2_3_0.zip
which should build without issue.
On Fri, Nov 27, 2015 at 8:57 AM, Peter Williams
wrote:
> Hi Alan & Arjen
>
> Thanks for your
>
> This looks a lot like this issue in a different project:
> https://github.com/Homebrew/homebrew/issues/41464
>
> Which seems to be that sip generates for qt5 but the build uses qt4.
> Unfortunately I have not seen a solution and I also can't find anything
> on the PyQt list about this problem.
Im working on MSYS2 which brings in all of the latest-and-greatest,
ground-breaking compatibility-crushing versions, of which python is of
course the worst offender.
I'm trying to get the PyQT4 binding to work in MSYS2. All of the
prerequisites
are ready and I've patched the plplot/cmake scriptin
Subject: [PATCH] Change window behavior to maintain keyboard focus at the
console window. When window is created, there is no expected keyboard input
and so no need to be a foregrouind window, but we do want it to show
completely so "BringWindowToTop" replaces "SetForeGroundWindow".
Otherwise
Does that C:/msys64 prefix contain both the 32-bit MinGW-w64/MSYS2 and
64-bit MinGW-w64/MSYS2 that can be installed with the MSYS2 pacman
installer? And assuming the answer is yes, is there a different
extension to that prefix for the 32-bit case versus the 64-bit case,
and is 32-bit and 64-bit Mi
I've re-checked my plplot tree with cygwin which completed the
comprehensive test earlier,
it does not have an issue with the build.
On Tue, Jul 14, 2015 at 10:07 PM, Alan W. Irwin
wrote:
> On 2015-07-14 18:30-0700 Greg Jung wrote:
>
> I'm working on it, from my point of v
er
if ( getcwd( builddir, PLPLOT_MAX_PATH ) == NULL )
^
Generating x19.tcl
[ 39%] Generating x20.tcl
src/CMakeFiles/plplot.dir/build.make:223: recipe for target
'src/CMakeFiles/plplot.dir/plcore.c.obj' failed
On Wed, Jul 15, 2015 at 2:24 PM, Greg Jung wr
Here is the "trully vanilla" results. No additional library paths are
involved (not even /mingw32/lib).
To get the mingw32/lib in in a clean fashion I suggest the following lines
in the if(MINGW) ... endif():
# We need the path to the MinGW/Borland compiler in order to find
# the import libraries
th only a few
module replacements.
On Tue, Jul 14, 2015 at 5:25 PM, Alan W. Irwin
wrote:
> On 2015-07-14 15:45-0700 Greg Jung wrote:
>
> From the ..env_out:
>>>
>>
>> PATH=/d/cmake3.2.2/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/c/ProgramData/Oracle/Java/javapath:/d
>From the ..env_out:
PATH=/d/cmake3.2.2/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/c/ProgramData/Oracle/Java/javapath:/d/CAF/bin:/c/GTK/bin:/c/tcl/bin:/c/windows/system32
and:
-- Check for working C compiler: C:/msys64/usr/bin/gcc.exe -- works
You are running this with the MSYS environment which
I have been using the calls
-SetWindowLong( aStream->hwnd, GWL_USERDATA, (long) pls );
+SetWindowLongPtr( aStream->hwnd, GWLP_USERDATA, (LONG_PTR) pls );
in both 32- and 64-bit compiled wincairo application for months, as well as
in wingcc. They work. AFAICT there's
no reason to maintain
The recent addition to struct wingcc_dev:
PLGraphicsIn gin;
Serves no purpose (other than to break backwards compatibility)
and shouldn't be propagated. It was only thrown in there because xwin.c has
something similar.
I would like to try wingdi.c but dont have a baseline file to run a patch
ag
Alan,
Since these strings that are kept in files, that need to be
associated with each possible driver,
do not change over the years, why maintain a separate location? Why
not just compile those strings
into the body of plplot.obj? The increase of data size will probably
be balanced by the dec
ly_ of the name of the
> produced import library. (I made a mistake not too long with that LIBRARY
> statement, hence I know that it works this way).
>
>
>
> Of course this only works on platforms where a .def file is required, MinGW
> and Win32.
>
>
>
> Rega
Hi guys,
I have one specific plplot question then I will give a lot of
background info that I'm fairly certain would come up in the ensuing
Q/A for the issue. The foreground is, I'm building GDL on mingw32,
GDL wants to (optionally) bring in a number of libraries to
accomplish added functional
afaict these environment variables are essential for plots:
PLPLOT_DRV_DIR=/usr/local/lib/plplot5.10.0/drivers
PLPLOT_HOME=/usr/local/share/plplot5.10.0/
DRV_DIR for dynamic loading, to get the driver_info files (.dll files
are to be pick
up in PATH) and PLPLOT_HOME for support files:
greg@Homerw
reg@linux-gc09:/home/bld/qhull> ls /usr/local/include
converter.h libqhull libqhullcpp plplot shapefil.h udunits2.h
greg@linux-gc09:/home/bld/qhull> vi /home/plplot-5.11/cmake/modules/*shap*
greg@linux-gc09:/home/bld/qhull> which java
/usr/bin/java
On Fri, Apr 3, 2015 at 12:26 PM, Alan W. Ir
26 PM, Alan W. Irwin
wrote:
> On 2015-04-02 22:57-0700 Greg Jung wrote:
>
>>
>> In each setup there are naturally missing pieces.
>>>
>>> From my perspective,I need only libplplot.dll, libplplotcxx.dll,
>>
>> wingcc, svg, ps, null, Z, X, and maybe cairo d
In Cygwin, I do use the cygwin cmake; but it isn't distributed by
cygwin, I built it from source. At one point I tried the windows
cmake from cygwin and it failed miserably.
On Fri, Apr 3, 2015 at 12:20 PM, Alan W. Irwin
wrote:
> On 2015-04-02 22:57-0700 Greg Jung wrote:
>
>&g
This is a long-standing cygwin warning, "CMake no longer defines WIN32
on Cygwin!"
for those rip-van-winkles coming back to cygwin and somehow wanting
WIN32 to be defined.
I am very familar with the possible quirks that can arise with Cmake;
if there is a systemic failure
it generally blows up in y
Here is tarball og the output directory from recent fully-completed
Suse-13.2 test.
I did terminate interactive testing at the end, by killing windows,
the strip chart was going very slow. But the wx Viewers looked great.
On Tue, Mar 31, 2015 at 9:31 AM, Alan W. Irwin
wrote:
> On 2015-03-31
Mingw/msys:
Because I have cmake modified to look in /usr/local
and such for libraries and such (not a good idea, I know now), I added
the option --cmake_command to the script and used
--cmake_command=/d/path-to-cmake/bin/cmake.exe and the make completed
ok but the ctest
hung at example/c/x00c;
I've been loading a revived dell-PIV XP with msys2,mingw32 - very full
set of pre-made and up-to-date libraries (including plplot-5.10.0 with
every bell and whistle). So it occasioned that I loaded the latest Cmake
3.1-rlx and I had
trouble building plplot with cairo-pango, relative to what I ha
I used a recent git tarball to generate a plplot library to build gdl;
the plstream components tr1, tr2 are gone now! I don't know what they are
or
how to use them, just that they were used in our contour-plotting, as in:
{GDL}/plotting_contour.cpp:
actStream->shade( map, xEl, yE
Alan,
I have three mingw32 installation in my computer, not by choice: as I
worked with
one I would hit a snag that was possibly solved with a new configuration.
The third installation, made by recipe found here,
http://ingar.satgnu.net/devenv/mingw32/gtk.html
included an updated compiler from
, a dwarf2- 4.8.1 toolchain. They have different STDC++
libraries which nevertheless hav the same name, and that's where my trouble
came from: the examples compiled with SJLJ
but I had a dwarf2 libstdc++-6.dll waiting in my windows path,
On Wed, Oct 29, 2014 at 1:28 PM, Alan W. Irwin
wrote:
tem-dependent. Though I can sympathize with you.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
> *From:* Greg Jung [mailto:gvj...@gmail.com]
> *Sent:* Saturday, October 25, 2014 12:45 AM
> *To:* phil rosenberg
> *Cc:* Arjen Markus; Alan W. Irwin; plplot-
That stackoverflow page has a clearer explanation than I've seen, that is
is dwarf2 exception in compiler .vs. sjlf in linker (?) or some-such, and
the quote:
*I fixed that. What I've had wrong was in toolchain as a compiler I've had
i686-pc-mingw32-gcc-4.6.0.exe but as a linker: mingw32-g++.exe.
I've been making plplot libraries with MING-MSYS, 32-bit compile on a
64-bit Win7, and testing the resulting examples directory, the "C" and
"F95" examples run well but the C++ examples don't, unifornly giving me
the refusal box,
"the procedure entry point __gxx_personality_sj0 could not be lo
14 at 11:55 AM, Alan W. Irwin
wrote:
> On 2014-10-07 07:56-0700 Greg Jung wrote:
>
> Hi guys,
>> I have been working on the _WIN32 incarnation of gnudatalanguage (GDL),
>> the overall project is in pretty good shape internally - it has most
>> aspects of IDL pre-
Hi guys,
I have been working on the _WIN32 incarnation of gnudatalanguage (GDL),
the overall project is in pretty good shape internally - it has most
aspects of IDL pre-2000 implemented. For plotting it uses plplot; hence
I've got a few lines to wingcc.c that should be useful, and one aspect of
postponed my staring because of my day job, so no harm there.)
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
> *From:* Greg Jung [mailto:gvj...@gmail.com]
> *Sent:* Friday, July 11, 2014 11:02 AM
> *To:* Arjen Markus; plplot-devel@lists.sourceforge.net
> *Subje
on my system.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
> *From:* Greg Jung [mailto:gvj...@gmail.com]
> *Sent:* Friday, July 11, 2014 8:13 AM
> *To:* plplot-devel@lists.sourceforge.net
> *Subject:* [Plplot-devel] CMake 2.8, with plplot using CYGWI
I've been successful building plplot using mingw/msys and, armed with the
cmake familiarity
I've acquired I went back to seehow far I can get with CYGWIN.
My hardware: Intel 64-bit dual-core, 6GB memory. (no virtualization)
C/D/E/F drives. E: holds a WinXP 32-bit, C holds Win7 home premium
Cygwin(
51 matches
Mail list logo
