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 return an ASCII #218 character...

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

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.

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.

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?

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

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