Summary

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

Metadata

Attachments

Description

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.

Changes and comments

[2010-01-12 07:42:41 UTC] zbigniew wrote:

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. (!)

[2010-01-12 08:31:20 UTC] felix wrote:

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?

[2010-01-12 08:44:08 UTC] zbigniew wrote:

Felix: offending commit is

[2010-01-12 08:50:40 UTC] zbigniew wrote:

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 "

[2010-01-12 09:05:59 UTC] nsantos wrote:

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

[2010-01-12 09:09:33 UTC] felix wrote:

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.

[2010-01-12 09:10:44 UTC] felix wrote:

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)

[2010-01-12 12:43:15 UTC] felix wrote:

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.

[2010-01-12 15:53:44 UTC] nsantos wrote:

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!

[2010-01-12 19:49:43 UTC] zbigniew wrote:

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.

[2010-01-12 19:51:39 UTC] zbigniew attached reverted-realname-fix.txt (description=#f)

[2010-01-13 07:27:03 UTC] felix wrote:

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

[2010-01-13 08:38:20 UTC] zbigniew changed status from new to closed

[2010-01-13 08:38:20 UTC] zbigniew set resolution to fixed

[2010-01-13 08:38:20 UTC] zbigniew wrote:

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.

[2010-03-11 10:33:12 UTC] Milestone 4.4.0 deleted