Click here to get back home

Curses-perl that doesn't live up to it's name?
 Home | NewsGroups | Search | About
Login Password
Register Now!
 comp.lang.perl.modules    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content
Subject Author Date
Curses-perl that doesn't live up to it's name? Fred Stone 11-10-2006
Posted by Fred Stone on November 10, 2006, 10:30 pm
Please log in for more thread options

Does there exist a Curses module for ActiveState Perl on WinXP that
actually supports PDCurses?

I am a fairly experienced Windoze and GNU/Cygwin user but new to the Perl
environment(s). I have PDCurses working in multiple environments under
Visual C++ as well as under GNU/Cygwin.

Curses-1.15 from CPAN refuses to recognize either of them. I see the
install note about how it is supposed to "sort of" work with PDCurses, but
I cannot make heads or tails of the installation process.

--
Fred Stone

--
Posted via a free Usenet account from http://www.teranews.com


Posted by Sisyphus on November 11, 2006, 2:41 am
Please log in for more thread options


> Does there exist a Curses module for ActiveState Perl on WinXP that
> actually supports PDCurses?
>
> I am a fairly experienced Windoze and GNU/Cygwin user but new to the Perl
> environment(s). I have PDCurses working in multiple environments under
> Visual C++ as well as under GNU/Cygwin.
>
> Curses-1.15 from CPAN refuses to recognize either of them. I see the
> install note about how it is supposed to "sort of" work with PDCurses, but
> I cannot make heads or tails of the installation process.
>

Curses and PDCurses are things that I know nothing about.

I'm (initially) surprised to find that there's no perl interface to
(specifically) the PDCurses library. At least, if such an interface does
exist, then, like you, I'm unable to locate it.

Seemed to me that there's a good opportunity for someone to write such an
interface - eg Win32::PDCurses.

Anyway, with nothing better to do, I downloaded the MinGW PDCurses-2.8
pre-compiled build (since I normally use the MinGW compiler).

I thought I might be able to demonstrate to you the ease with which many of
those PDCurses functions could be wrapped into perl functions using
Inline::C. Those functions that cannot be wrapped *easily* could still be
wrapped - they just take a little more thought and work. And all of those
functions (both easy, and difficult, to wrap) could also be incorporated
into a perl extension (module) with no dependency on Inline::C - if such was
deemed desirable.

So I wrote the following demo:

-------------------------
use warnings;
use Inline C => Config =>
BUILD_NOISY => 1, # verbose build
LIBS => '-LF:/pdcurses_mingw -lpdcurses',
INC => '-IF:/pdcurses_mingw';

use Inline C => <<'EOC';

#include <curses.h>

int wrap_baudrate() {
return baudrate();
}

int wrap_beep() {
return beep();
}

EOC

$ret1 = wrap_baudrate();
$ret2 = wrap_beep();
$size = get_sizeof_chtype();

print $ret1, " ", $ret2, "\n";
-------------------------

But the compilation stage fails with the following errors:

------------------------
F:/pdcurses_mingw/curses.h:1225:17: macro "instr" requires 2 arguments, but
only 1 given
F:/pdcurses_mingw/curses.h:1541:1: warning: "instr" redefined
In file included from D:/perl58_M/5.8.8/lib/CORE/perl.h:3982,
from pdcurses_pl_5fd5.xs:2:
D:/perl58_M/5.8.8/lib/CORE/embed.h:2375:1: warning: this is the location of
the previous definition
dmake: Error code 129, while making 'pdcurses_pl_5fd5.o'
------------------------

Already there's a problem.

From F:/pdcurses_mingw/curses.h we have:
1541: # define instr(str) winnstr(stdscr, str, stdscr->_maxx)

And from D:/perl58_M/5.8.8/lib/CORE/embed.h we have:
2375: #define instr(a,b) Perl_instr(aTHX_ a,b)

I wouldn't like to try and build this interface without including embed.h
... and I certainly wouldn't like to try and build it without curses.h :-)

Frankly, I don't know how to deal with this collision. It may be simple ...
or it may require that either PDCurses or Perl rename 'instr' to something
that doesn't clash.

And there may be other problems in store once that one has been overcome.

If you can think of some possible way of getting around that problem without
too much difficulty, then please let me know. I'd be interested in that -
and would be quite prepared to try it out and see where it leads.

Both my Cygwin and Visual C++-built perls also contain an 'embed.h' that
contains the same definition, so I would think that the same problem applies
equally to them.

Cheers,
Rob



Posted by Sisyphus on November 11, 2006, 2:57 am
Please log in for more thread options



.
.
> $size = get_sizeof_chtype();

Doh!! ... at one stage there was an Inline::C function in the script that
determined the size of the chtype type. For simplicity, I removed it from
the script when I realised the script wouldn't compile .... apparently I
forgot to remove it from the perl section of the script, too.

Cheers,
Rob



Posted by Fred Stone on November 11, 2006, 7:42 am
Please log in for more thread options



>
>> Does there exist a Curses module for ActiveState Perl on WinXP that
>> actually supports PDCurses?
>>
>> I am a fairly experienced Windoze and GNU/Cygwin user but new to the
>> Perl environment(s). I have PDCurses working in multiple environments
>> under Visual C++ as well as under GNU/Cygwin.
>>
>> Curses-1.15 from CPAN refuses to recognize either of them. I see the
>> install note about how it is supposed to "sort of" work with
>> PDCurses, but I cannot make heads or tails of the installation
>> process.
>>
>
> Curses and PDCurses are things that I know nothing about.
>
> I'm (initially) surprised to find that there's no perl interface to
> (specifically) the PDCurses library. At least, if such an interface
> does exist, then, like you, I'm unable to locate it.
>
> Seemed to me that there's a good opportunity for someone to write such
> an interface - eg Win32::PDCurses.
>
> Anyway, with nothing better to do, I downloaded the MinGW PDCurses-2.8
> pre-compiled build (since I normally use the MinGW compiler).
>
> I thought I might be able to demonstrate to you the ease with which
> many of those PDCurses functions could be wrapped into perl functions
> using Inline::C. Those functions that cannot be wrapped *easily* could
> still be wrapped - they just take a little more thought and work. And
> all of those functions (both easy, and difficult, to wrap) could also
> be incorporated into a perl extension (module) with no dependency on
> Inline::C - if such was deemed desirable.
>
> So I wrote the following demo:
>
> -------------------------
> use warnings;
> use Inline C => Config =>
> BUILD_NOISY => 1, # verbose build
> LIBS => '-LF:/pdcurses_mingw -lpdcurses',
> INC => '-IF:/pdcurses_mingw';
>
> use Inline C => <<'EOC';
>
> #include <curses.h>
>
> int wrap_baudrate() {
> return baudrate();
> }
>
> int wrap_beep() {
> return beep();
> }
>
> EOC
>
> $ret1 = wrap_baudrate();
> $ret2 = wrap_beep();
> $size = get_sizeof_chtype();
>
> print $ret1, " ", $ret2, "\n";
> -------------------------
>
> But the compilation stage fails with the following errors:
>
> ------------------------
> F:/pdcurses_mingw/curses.h:1225:17: macro "instr" requires 2
> arguments, but only 1 given
> F:/pdcurses_mingw/curses.h:1541:1: warning: "instr" redefined
> In file included from D:/perl58_M/5.8.8/lib/CORE/perl.h:3982,
> from pdcurses_pl_5fd5.xs:2:
> D:/perl58_M/5.8.8/lib/CORE/embed.h:2375:1: warning: this is the
> location of the previous definition
> dmake: Error code 129, while making 'pdcurses_pl_5fd5.o'
> ------------------------
>
> Already there's a problem.
>
> From F:/pdcurses_mingw/curses.h we have:
> 1541: # define instr(str) winnstr(stdscr, str,
> stdscr->_maxx)
>
> And from D:/perl58_M/5.8.8/lib/CORE/embed.h we have:
> 2375: #define instr(a,b) Perl_instr(aTHX_ a,b)
>
> I wouldn't like to try and build this interface without including
> embed.h ... and I certainly wouldn't like to try and build it without
> curses.h :-)
>
> Frankly, I don't know how to deal with this collision. It may be
> simple ... or it may require that either PDCurses or Perl rename
> 'instr' to something that doesn't clash.
>
> And there may be other problems in store once that one has been
> overcome.
>
> If you can think of some possible way of getting around that problem
> without too much difficulty, then please let me know. I'd be
> interested in that - and would be quite prepared to try it out and see
> where it leads.
>
> Both my Cygwin and Visual C++-built perls also contain an 'embed.h'
> that contains the same definition, so I would think that the same
> problem applies equally to them.
>

In my C++ programs I wrap curses.h into objects so that the old C
structures become private to those objects.

And I think that's approximately what the Curses-1.15 installation
Makefile.pl is doing, though the automated process is not at all
transparent to a perl n00b like me. He's doing some weird hack to
generate compiler calls to detect each of the routines in curses.h and
then generates C macros to interface them, and then *that* gets compiled
to make the Curses.pm module.

At least that's the theory.

--
Fred Stone

--
Posted via a free Usenet account from http://www.teranews.com


Posted by Sisyphus on November 11, 2006, 7:56 pm
Please log in for more thread options



.
.
> >
> > So I wrote the following demo:
> >
> > -------------------------
> > use warnings;
> > use Inline C => Config =>
> > BUILD_NOISY => 1, # verbose build
> > LIBS => '-LF:/pdcurses_mingw -lpdcurses',
> > INC => '-IF:/pdcurses_mingw';
> >
> > use Inline C => <<'EOC';
> >
> > #include <curses.h>
> >
> > int wrap_baudrate() {
> > return baudrate();
> > }
> >
> > int wrap_beep() {
> > return beep();
> > }

int get_sizeof_chtype() {
return sizeof(chtype);
}

> >
> > EOC
> >
> > $ret1 = wrap_baudrate();
> > $ret2 = wrap_beep();
> > $size = get_sizeof_chtype();
> >
> > print $ret1, " ", $ret2, "\n";
> > -------------------------
.
.
> >
>
> In my C++ programs I wrap curses.h into objects so that the old C
> structures become private to those objects.
>
> And I think that's approximately what the Curses-1.15 installation
> Makefile.pl is doing, though the automated process is not at all
> transparent to a perl n00b like me. He's doing some weird hack to
> generate compiler calls to detect each of the routines in curses.h and
> then generates C macros to interface them, and then *that* gets compiled
> to make the Curses.pm module.
>

But both perl.h (and hence embed.h) and curses.h are being included in perl
Curses, so perl Curses must be doing something to resolve the 'instr'
conflict. Indeed, I find in perl curses.c the following:

-------------------------
/* c-config.h above includes Ncurses header files that define macro
'instr'. Unfortunately, perl.h (below) also defines 'instr'.
Fortunately, we don't need the Curses version -- we use
winstr(stdscr, ...) instead. So we undef instr here to avoid a compiler
warning about the redeclaration.
*/
------------------------

(Aside: I note that they refer to the redeclaration as a "warning" only.
With Visual Studio perhaps that all it is - in which case it's not such a
big deal anyway. But with MinGW it's a fatal error.)

So, for the purpose of the proof-of-concept of the above script, I
commented out the 'int instr(char *)' and '#define instr ...' lines in
curses.h and ran again.

With those changes in place, the Inline::C wrappers I tested produce the
same results as running a C program - ie the sizeof chtype is reported as 4,
baudrate() returns 2147483647, and beep() segfaults when called. Either
there's something wrong with the pre-compiled library, or one simply can't
just call beep() indiscriminately as I did. I didn't expect baudrate to
return such a large number, either - looks more like a memory location ....
like I said, I know nothing about PDCurses.

I think that if *I* wanted a perl interface to PDCurses, I would probably be
writing a Win32::PDCurses module, that wraps the individual PDCurses
functions, instead of trying to get perl Curses to work with it .... but
that's possibly just me :-)

There are quite a few Win32 users who would like to see a workable curses
module for Win32 - so Win32::PDCurses would probably be a useful addition to
CPAN.

Did you see the (minimal) PDCurses notes at the bottom of the perl Curses
'INSTALL' file ? Didn't mean much to me - though, having taken a look at
c-MSWin32.visualc.h in the Curses-1.15 source, they start to make better
sense.

Cheers,
Rob




Our other projects:

Art Dolls, Fairies and Mermaids - Sunnyfaces.net

Roy's Linux, Programming and Search Engines messages

1-Script XML SitemapXML Sitemap