www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Need help with acs_map[] from CURSES

reply Dejan Lekic <dejan.lekic gmail.com> writes:
Hi everybody,
I am working on a binding to CURSES, but recently I have encountered a problem
I cannot solve.

Part of D code relevant to the problem is at
http://paste.dprogramming.com/dpp01ati.php .

For C declaration of acs_map[] refer to Your /usr/include/curses.h (or
ncurses.h) .

In short, acs_map[] is an external C variable which is filled with PROPER data
by CURSES at runtime, depending on the type of terminal we are currently
running our application in.

So, sometimes acs_map['l'] would return a simple '+', but sometimes it will


Internaly, acs_map[] has 128 elements.

The D code mentioned above produces bunch of "Error: non-constant expression
acs_map[108u]" errors.

Any help is apriciated. Apart from this I haven's encountered any other big
problem, so I hope soon we will have a good binding to CURSES. :)

Kind regards

Dejan
Mar 07 2007
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Dejan Lekic wrote:

 I am working on a binding to CURSES, but recently I have encountered a problem
I cannot solve.



 acs_map[] is an external C variable which is filled with PROPER data by CURSES
__at runtime__


and you have

  const chtype ACS_ULCORNER       = acs_map['l']
  const chtype ACS_LLCORNER       = acs_map['m']
  ...

All of which try to figure out the values of the array at compile time.

Maybe you can use a function to defer the lookup into runtime and hope
that the compiler inlines it? Something like

  chtype acs_map_f(int i)() {
          return acs_map[i];
  }

  alias acs_map_f!('l') ACS_ULCORNER;


 Any help is apriciated. Apart from this I haven's encountered any other big
problem, so I hope soon we will have a good binding to CURSES. :)


Interesting. The ncurses header files are a terrible mess (a
preprocessor macro minefield/hell). I have been using the version of D
bindings that somebody sent here a few years ago since I haven't had any
need for newer features. It would be nice to have an updated version,
though. Please publish your version when it's ready.
Mar 07 2007
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Mr. Mäkelä, thanks for Your help.

After discussion on irc://irc.freenode.org/D channel with couple of my
irc-friends we came to the similar conclusion. Either to do something as You
said, or to write some sort of initCurses() method which will update those
"macros". They would have default values first, and after initCurses() they
would change into what current terminal is capable of...

Well, everything else by acs_map part is done in this binding, and panel is
finished too.

There are many other issues, but I will come to it later.

For an instance, I would like to have support for PDCurses as well. The problem
is that PDCurses' window structure is different than NCurses, and there are
numerous differences between these two. Yes, some functions defined by CURSES
standard ARE in both, so I am planning to have a version "NCurses" set if we
are using NCurses, or not, if we are using PDCurses. Furthermore, NCurses has
forms and menus libraries, which are VERY convenient...
After all, I would be VERY happy if someone ports Windows-part of PDCurses into
NCurses. That would eliminate the need for PDCurses completely. (Yes, I know I
can use NCurses on Windows too - but I remind You it works only if compiled on
Cygwin. I haven't seen any other way to build it in MSYS for an instance.)

Best regards

Dejan


 Dejan Lekic wrote:

 I am working on a binding to CURSES, but recently I have encountered a problem
I cannot solve.


 

 acs_map[] is an external C variable which is filled with PROPER data by CURSES
__at runtime__


 
 and you have
 
   const chtype ACS_ULCORNER       = acs_map['l']
   const chtype ACS_LLCORNER       = acs_map['m']
   ...
 
 All of which try to figure out the values of the array at compile time.
 
 Maybe you can use a function to defer the lookup into runtime and hope
 that the compiler inlines it? Something like
 
   chtype acs_map_f(int i)() {
           return acs_map[i];
   }
 
   alias acs_map_f!('l') ACS_ULCORNER;
 

 Any help is apriciated. Apart from this I haven's encountered any other big
problem, so I hope soon we will have a good binding to CURSES. :)


 
 Interesting. The ncurses header files are a terrible mess (a
 preprocessor macro minefield/hell). I have been using the version of D
 bindings that somebody sent here a few years ago since I haven't had any
 need for newer features. It would be nice to have an updated version,
 though. Please publish your version when it's ready.
Mar 08 2007
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Dejan Lekic wrote:

 Mr. Mäkelä, thanks for Your help.


You can call me by my first name if you wish - and pipe through s/Y/y/
also ;)


 After discussion on irc://irc.freenode.org/D channel with couple of
 my irc-friends we came to the similar conclusion. Either to do
 something as You said, or to write some sort of initCurses() method
 which will update those "macros".


Probably that second solution could be better in the long run. I just
posted a quick solution so that one can search the NG archives and does
not need to ask again.

Thx for advertising the channel. I didn't know there was some much
people there.


 They would have default values
 first, and after initCurses() they would change into what current
 terminal is capable of...


BTW, how do you differentiate between Unicode capable and incapable
terminals?
Mar 08 2007
next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
 You can call me by my first name if you wish - and pipe through s/Y/y/
 also ;)


I will not - "You" (with capital "Y") is part of my culture. :)
Mar 08 2007
prev sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
 BTW, how do you differentiate between Unicode capable and incapable
 terminals?


To be honest I had no time to think about this - I am linking against ncursesw
anyway, so it should not be a huge problem on the long run.

Cheers!
Mar 08 2007