www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A little Problem translating a header file.

reply Jude Young <10equals2 gmail.com> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ok, so I've been working on ncurses.
It's pretty much complete, but one of the things that I think needs to
be worked on is the ACS vars.

The header file uses this:

extern NCURSES_EXPORT_VAR(chtype) acs_map[];

#define NCURSES_ACS(c)  (acs_map[NCURSES_CAST(unsigned char,c)])

/* VT100 symbols begin here */
#define ACS_ULCORNER    NCURSES_ACS('l') /* upper left corner */
#define ACS_LLCORNER    NCURSES_ACS('m') /* lower left corner */
#define ACS_URCORNER    NCURSES_ACS('k') /* upper right corner */
#define ACS_LRCORNER    NCURSES_ACS('j') /* lower right corner */

this way, you can simply type in, for example: addch(ACS_ULCORNER);
and it will print the appropriate character to the screen.

However, i've been struggling to come up with a way to allow this in
the D bindings.

The best that has been come up with (by Jon) is:
immutable enum ACS
{
    /* VT100 symbols begin here */
    ULCORNER      = 'l',
    LLCORNER      = 'm',
    URCORNER      = 'k',

to use it you have to type: addch(acs_map[ACS.ULCORNER]);


Is there an easy way to do this that I have been missing?
Preferably something that can be done at compile time, rather than
having to call a function manually?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOwSAjAAoJENcHIWLyQiSl7hQH/26wD4/8Y3JUu61dY2s1KBp2
M2gpy8l3d7Qh+sXYMeEnRWzpEHaamHx8G6umuNEufFhbdC6Mc61aCFgyYePDoFXO
BUBhq2H1PwP2oyuKtDvxbrLEATh3CV/gHfxIg3r5YdzTboHA3HAvKPsTpftZgvIU
2KC1r4Moh7Z//AGYEg0+0Su2Dd7Q1ekpgG9g5f/md0sNNk4IYnv71dV3RJfkY1pE
APO89Ya2jZP3eR2D1ZMtnNUvfgvhD/Zuj61depNkQ9HOY+3adVOdMosQoj1YyeiU
+dEsEco0NaLjEfU69Ntu0qBOfscjBnnI7IvLSafyrZER+W879EYZbfPt5UqlMmo=
=DbnD
-----END PGP SIGNATURE-----
Nov 14 2011
next sibling parent reply Kagamin <spam here.lot> writes:
Jude Young Wrote:


 /* VT100 symbols begin here */
 #define ACS_ULCORNER    NCURSES_ACS('l') /* upper left corner */
 #define ACS_LLCORNER    NCURSES_ACS('m') /* lower left corner */
 #define ACS_URCORNER    NCURSES_ACS('k') /* upper right corner */
 #define ACS_LRCORNER    NCURSES_ACS('j') /* lower right corner */
 
 immutable enum ACS
 {
     /* VT100 symbols begin here */
     ULCORNER      = 'l',
     LLCORNER      = 'm',
     URCORNER      = 'k',
 
 to use it you have to type: addch(acs_map[ACS.ULCORNER]);


addch_map(ubyte c)
{ addch(acs_map[c]); }

or

 immutable enum ACS
 {
     /* VT100 symbols begin here */
     ULCORNER      = NCURSES_ACS('l'),
     LLCORNER      = NCURSES_ACS('m'),
     URCORNER      = NCURSES_ACS('k'),

should be CTFE'able if acs_map is immutable and known at compile time.
Nov 14 2011
next sibling parent reply Jude Young <10equals2 gmail.com> writes:
I don't believe that acs_map is capable of being known at compile 
time...

addch_map(ubyte c)
{ addch(acs_map[c]); }
good idea, but addch is one of a dozen 'write a character to the 
screen' type functions.  It would take a couple of days to find all of 
them and make sure that they are working right.

I could make the ACS_ULCORNER stuff into functions that returned 
acs_map[whatever]...
Is it still possible to call a function without the ()'s?  Or would 
that be too much of a hack?
Nov 14 2011
parent reply Kagamin <spam here.lot> writes:
Jude Young Wrote:


 addch_map(ubyte c)
 { addch(acs_map[c]); }
 good idea, but addch is one of a dozen 'write a character to the 
 screen' type functions.  It would take a couple of days to find all of 
 them and make sure that they are working right.


struct SACS
{
  ubyte value;
  ubyte acs(){ return acs_map[value]; }
}

void addch(SACS ch)
{ addch(ch.acs); }

enum ACS_ULCORNER = SACS('k');

addch(ACS_ULCORNER);


 I could make the ACS_ULCORNER stuff into functions that returned 
 acs_map[whatever]...
 Is it still possible to call a function without the ()'s?  Or would 
 that be too much of a hack?


struct ACS
{
   static ubyte ULCORNER() { return acs_map['k']; }
}

now can call without parentheses:

addch(ACS.ULCORNER);
Nov 15 2011
next sibling parent Kagamin <spam here.lot> writes:
 struct ACS
 {
    static ubyte ULCORNER() { return acs_map['k']; }
 }
 
 now can call without parentheses:
 
 addch(ACS.ULCORNER);


ideally this function should be inlined, try to check it.
Nov 15 2011
prev sibling parent Jude Young <10equals2 gmail.com> writes:
stupid mail client.  why did you send that?
I fail.
So. close...
Nov 15 2011
prev sibling parent Jude Young <10equals2 gmail.com> writes:
Ok, the best that I have come up with is to use:
auto ACS_ULCORNER()()
{    return acs_map[cast(ubyte)'l'];    }

which you can call using addch(ACS_ULCORNER());

There is an extra set of '()' that aren't there in the C version, but I 
haven't come up with anything that would allow me to remove them...

Thanks for your help.
Nov 14 2011
prev sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
There are two bindings to NCurses already. My one, dcurses, and another one, 
ycurses. I populate acs in a module constructor. Maybe not the best idea, 
but works.
Nov 15 2011
next sibling parent reply Jude Young <10equals2 gmail.com> writes:
On Tue 15 Nov 2011 04:27:57 AM CST, Dejan Lekic wrote:

 There are two bindings to NCurses already. My one, dcurses, and another one, 
 ycurses. I populate acs in a module constructor. Maybe not the best idea, 
 but works.


I'm one of the maintainers of ycurses.
If you check curses.d in Deimos, you'll find your name in a comment. =)
Your idea for the CTFE of NCURSES_BITS really helped me out!

I should probably add your name to the AUTHORS file... damnit, knew 
there was something that I was forgetting.
The binding that is in Deimos is the result of me tearing apart both of 
the bindings and merging the best parts together.

And then rearranging the result to closer resemble the header file to 
facilitate easier review later.
And filling in the minor things that both projects overlooked.
And fixing my own bugs. ><

I need to take a closer look at your module constructor...
Nov 15 2011
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
Jude Young wrote:


 On Tue 15 Nov 2011 04:27:57 AM CST, Dejan Lekic wrote:

 There are two bindings to NCurses already. My one, dcurses, and another
 one, ycurses. I populate acs in a module constructor. Maybe not the best
 idea, but works.


 
 I'm one of the maintainers of ycurses.
 If you check curses.d in Deimos, you'll find your name in a comment. =)
 Your idea for the CTFE of NCURSES_BITS really helped me out!
 
 I should probably add your name to the AUTHORS file... damnit, knew
 there was something that I was forgetting.
 The binding that is in Deimos is the result of me tearing apart both of
 the bindings and merging the best parts together.
 
 And then rearranging the result to closer resemble the header file to
 facilitate easier review later.
 And filling in the minor things that both projects overlooked.
 And fixing my own bugs. ><
 
 I need to take a closer look at your module constructor...


It is not a big deal, can be done any time. What is more important to us 
(people who still believe in the console) is to have mature NCurses binding, 
hopefuly with support PDCurses as well (so our curses module can work on 
Windows too, inside the CMD shell.

Speaking about PDCurses, that is why i recently renamed my "curses" package 
into "tui", and inside that package i have ncurses and pdcurses (binding) 
modules.

So, my recommended structure would be:

--tui
  |-- curses.d
  |-- panel.d
  |-- ncurses
  |    |- curses.d
  |    |- panel.d
  |-- pdcurses
  |    |- curses.d
  |    |- panel.d

so, tui.curses is a module which uses different curses depending on the 
version. version(posix) will trigger the usage of ncurses.curses, while 
version(Windows) will trigger the usage of the pdcurses.curses.

I must admit I did not think too much. If I did, I would probably make 
Curses and Panel into interfaces, and write some adaptors...

No matter what, your module is still very much usable. Good work!
Nov 15 2011
parent Jude Young <10equals2 gmail.com> writes:
On Tue 15 Nov 2011 08:37:37 AM CST, Dejan Lekic wrote:

 Jude Young wrote:


 On Tue 15 Nov 2011 04:27:57 AM CST, Dejan Lekic wrote:

 There are two bindings to NCurses already. My one, dcurses, and another
 one, ycurses. I populate acs in a module constructor. Maybe not the best
 idea, but works.


 I'm one of the maintainers of ycurses.
 If you check curses.d in Deimos, you'll find your name in a comment. =)
 Your idea for the CTFE of NCURSES_BITS really helped me out!

 I should probably add your name to the AUTHORS file... damnit, knew
 there was something that I was forgetting.
 The binding that is in Deimos is the result of me tearing apart both of
 the bindings and merging the best parts together.

 And then rearranging the result to closer resemble the header file to
 facilitate easier review later.
 And filling in the minor things that both projects overlooked.
 And fixing my own bugs. ><

 I need to take a closer look at your module constructor...


 It is not a big deal, can be done any time. What is more important to us 
 (people who still believe in the console) is to have mature NCurses binding, 
 hopefuly with support PDCurses as well (so our curses module can work on 
 Windows too, inside the CMD shell.

 Speaking about PDCurses, that is why i recently renamed my "curses" package 
 into "tui", and inside that package i have ncurses and pdcurses (binding) 
 modules.

 So, my recommended structure would be:

 --tui
   |-- curses.d
   |-- panel.d
   |-- ncurses
   |    |- curses.d
   |    |- panel.d
   |-- pdcurses
   |    |- curses.d
   |    |- panel.d

 so, tui.curses is a module which uses different curses depending on the 
 version. version(posix) will trigger the usage of ncurses.curses, while 
 version(Windows) will trigger the usage of the pdcurses.curses.

 I must admit I did not think too much. If I did, I would probably make 
 Curses and Panel into interfaces, and write some adaptors...

 No matter what, your module is still very much usable. Good work!


Please, credit needs to go where it is due.
it'll get updated with my next pull request.
I'd really hate for people to think that I did all of that myself.  
Might expect too much of me! hahah.

I'll have to check that out.
I need a Windows box.. -_-
can you point me to a place to download your tui?
I can't seem to find it again..
Nov 15 2011
prev sibling parent Jude Young <10equals2 gmail.com> writes:
Your name.  Just in case you were wondering.
https://github.com/1100110/ncurses/blob/master/curses.d#L60
Nov 15 2011