Incorrect mapping of ncurses C string-retrieval functions to Scheme procedures

[Neil Santos]

There's a bunch of ncurses functions that aren't properly mapped to Scheme-y equivalents. All of the ones I've stumbled upon related to retrieving input strings. To wit:

• (getnstr STRING)
• (getstr STRING)
• (mvgetnstr INT INT STRING INT)
• (mvgetstr INT INT STRING)
• (mvwgetnstr WINDOW INT INT STRING INT)
• (mvwgetstr WINDOW INT INT STRING)
• (wgetnstr WINDOW STRING INT)

The bug is that, as with their C counterparts, the Scheme procedures expect a STRING argument. The C functions expect to be able to use said argument as a pointer to the retrieved string.

The Scheme mappings should instead return the retrieved string.

[Jim Ursetto]

I'm pretty sure those Scheme procedures take a pointer argument.

However I can't verify because I am getting a bus error trying to compile ncurses with latest Chicken master. (!)

[felix winkelmann]

Replying to zbigniew:

I'm pretty sure those Scheme procedures take a pointer argument.

Yes, they are declared as receiving a pointer.

However I can't verify because I am getting a bus error trying to compile ncurses with latest Chicken master. (!)

What platform?

[Jim Ursetto]

Felix: offending commit is

• 2b2fab2 drop previous safe toplevel assigns if assigned multiple times

Reverting corrects the bus error when compiling ncurses egg.
Platform macosx

[Jim Ursetto]

nsantos: Works for me. Are you contending the interface does not work (it does) or that it's not particularly Scheme-like (a valid point)? See below.

#;> (initscr)
#;> (define s (make-string 10))
#;> (getnstr s 10)
abcdef
#;> s
"abcdef\x00 "

[Neil Santos]

Replying to zbigniew:

nsantos: Works for me. Are you contending the interface does not work (it does) or that it's not particularly Scheme-like (a valid point)?

Yes on the latter, although it's mostly a nice-to-have at this point. This is the ncurses error I'm getting, preceded by code I'm trying to get to work.

(define (input-loop entry-window mailbox)
  (make-thread
   (lambda ()
     (let loop ((input ""))
       (mvwgetstr entry-window 0 0 input)
       (mailbox-send! mailbox input)
       (loop "")))))

The error being,

Warning (#<thread: thread929>): : curses error
Call history:

  <eval>          [input-loop] ((##core#letrec ((loop (##core#loop-lambda (input) (mvwgetstr entry-window 0 0 input) (mailbox-send!......
  <eval>          [input-loop] (mvwgetstr entry-window 0 0 input) <-- Warning (#<thread: thread927>): : <condition> (uncaught-exception)

Error: uncaught exception: #<condition: (uncaught-exception)>

[felix winkelmann]

Replying to zbigniew:

Felix: offending commit is

• 2b2fab2 drop previous safe toplevel assigns if assigned multiple times

Reverting corrects the bus error when compiling ncurses egg.
Platform macosx

This actually appears to be a compiler bug. I'm working on it.

[felix winkelmann]

Replying to felix:

Replying to zbigniew:

Felix: offending commit is

• 2b2fab2 drop previous safe toplevel assigns if assigned multiple times

Reverting corrects the bus error when compiling ncurses egg.
Platform macosx

This actually appears to be a compiler bug. I'm working on it.

(of course it's a compiler bug - I mean it is caused by an incorrect entry in an internal table, not so much by the optimization introduced by the commit you mentioned)

[felix winkelmann]

Replying to felix:

Replying to felix:

Replying to zbigniew:

Felix: offending commit is

• 2b2fab2 drop previous safe toplevel assigns if assigned multiple times

Reverting corrects the bus error when compiling ncurses egg.
Platform macosx

This actually appears to be a compiler bug. I'm working on it.

(of course it's a compiler bug - I mean it is caused by an incorrect entry in an internal table, not so much by the optimization introduced by the commit you mentioned)

Jim, I have committed a change to master. Can you give ncurses a try? I don't have access to a UNIX machine right now.

[Neil Santos]

Replying to nsantos:

Warning (#<thread: thread929>): : curses error
Call history:

Ah! Found it! I call (nodelay) on the target window after it gets drawn; when I removed that, it worked.

There's still the matter of the not-very-Scheme-y feel of the calls, but I supposed I should open a new ticket for that? Feel free to close this ticket when you guys are through working out that bug zbigniew pointed out.

Thanks!

[Jim Ursetto]

Replying to felix:

Jim, I have committed a change to master. Can you give ncurses a try? I don't have access to a UNIX machine right now.

Works in c08efe2b8, BUT looks like you accidentally reverted it in 21a4cae97, possibly along with some changes to the mingw makefiles. Probably working tree was in a bad state. See attached for example.

[felix winkelmann]

Replying to zbigniew:

Replying to felix:

Jim, I have committed a change to master. Can you give ncurses a try? I don't have access to a UNIX machine right now.

Works in c08efe2b8, BUT looks like you accidentally reverted it in 21a4cae97, possibly along with some changes to the mingw makefiles. Probably working tree was in a bad state. See attached for example.

Argh. Thanks for telling me. I've repaired it (I think).

[Jim Ursetto]

Yep, it is fixed now. Thanks!

nsantos: I am closing this ticket since it kind of got offtopic. Feel free to open another one with your concerns on the API. However, I do not think it is being actively maintained, so you may want to ask someone for help on the list.

[(none)]

Milestone 4.4.0 deleted