Curses-perl that doesn"t live up to it"s name?

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

Re: Curses-perl that doesn"t live up to it"s name?

"Fred Stone" wrote in message
news:Xns9877EE73A6A99fstone69@66.150.105.47...
> 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

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

Re: Curses-perl that doesn"t live up to it"s name?

"Sisyphus" wrote in message
news:45557fb5$0$23136$afc38c87@news.optusnet.com.au...
..
..
> $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

Re: Curses-perl that doesn"t live up to it"s name?

"Sisyphus" wrote in
news:45557fb5$0$23136$afc38c87@news.optusnet.com.au:

>
> "Fred Stone" wrote in message
> news:Xns9877EE73A6A99fstone69@66.150.105.47...
>> 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
>
> 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

Re: Curses-perl that doesn"t live up to it"s name?

"Fred Stone" wrote in message
news:Xns987857FEBF574fstone69@66.150.105.47...
> "Sisyphus" wrote in
..
..
> >
> > 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
> >
> > 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

Re: Curses-perl that doesn"t live up to it"s name?

"Sisyphus" wrote in
news:45567272$0$2917$afc38c87@news.optusnet.com.au:

>
> "Fred Stone" wrote in message
> news:Xns987857FEBF574fstone69@66.150.105.47...
>> "Sisyphus" wrote in
> .
> .
>> >
>> > 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
>> >
>> > 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.
>

You have to initialize it with initscr() first before making any other
calls.

> 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 :-)
>

I started down this path because of a couple of perl utilities for the
ToME game. One of them uses perl-Curses, which I managed to get to work
under Cygwin with their ncurses; another one uses perl-Tk, which
*doesn't* work under Cygwin but *does* under ActiveState. It's an awful
can of worms to get a couple of silly game utilities to work.

> 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.
>

I tried those suggestions and got it to *almost* compile. There is still
apparantly another name conflict with the SCREEN macro. I haven't spent
enough time on the code to really understand what's going on.

--
Fred Stone

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

Re: Curses-perl that doesn"t live up to it"s name?

On Sun, 12 Nov 2006 11:56:46 +1100, Sisyphus wrote:

> I didn't expect baudrate to return such a large number, either - looks
> more like a memory location ....

It's just INT_MAX. :-) Kind of a holdover from the days when PDCurses was
16-bit, but with the speed of today's machines, maybe it's still accurate...

Re: Curses-perl that doesn"t live up to it"s name?

On Sun, 12 Nov 2006 02:53:51 +0000, Fred Stone wrote:

> You have to initialize it with initscr() first before making any other
> calls.

Yeah... except for slk_init() and ripoffline(), which have to be called
before initscr() if you're going to use them.

beep() fails if initscr() hasn't been called because it checks a value in
the SCREEN structure pointed to by SP, which is allocated by initscr().
(It checks to see if it should flash instead of beep.)

Re: Curses-perl that doesn"t live up to it"s name?

"Fred Stone" wrote in message
news:Xns9878E846DDFF3fstone69@66.150.105.47...
..
..
>
> You have to initialize it with initscr() first before making any other
> calls.
>

Yep - calling initscr() got beep() working in both the C program and the
Inline::C script.

There's an interesting project just waiting there for someone who has plenty
of time and motivation :-)

Cheers,
Rob