Arc Forumnew | comments | leaders | submitlogin
Requesting a hallway usability test
1 point by akkartik 4595 days ago | 14 comments
I've been struggling to make the repl experience not suck in wart -- without getting into the complexities of non-blocking I/O -- and just thought up a twist on the usual prompt. I'd appreciate anybody with access to linux or a mac trying it out:

  $ git clone http://github.com/akkartik/wart
  $ cd wart
  $ git checkout e05faf25ec
  $ ./wart
Play with it for a minute and give me brief impressions? You can also call me at 512 422 0223 (US) if that's more convenient. Did it make sense or was it bewildering? Should I retreat to a more conventional prompt?

PS: Don't read the comments first, lest they give away the punchline :)



2 points by kinleyd 4595 days ago | link

    [kdd@780 wart]$ ./wart
    g++ -O3 -std=gnu++0x -Wall -Wextra -fno-strict-aliasing boot.cc -o  wart_bin
    In file included from file_list:21:0,
                 from boot.cc:75:
    029posix.cc: In function ‘Cell* compiledFn_socket()’:
    029posix.cc:47:1: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]

    which: no rlwrap in (/usr/local/bin: ... )
    ready! type in an expression, then hit enter twice. ctrl-d exits.
    (+ 22 22)

    => 44
    (prn "hello")

    hello
    => "hello"
Ran it on Arch Linux (3.6) and played around. Looks pretty good though I'm not so sure about the double enter requirement. Very superficially I'd say I prefer the empty line after the result, keeping the expression and result together and segregating each expression/result set; the absence of a prompt looks quite good:

    (+ 22 22)
    => 44

    (prn "hello")
    hello
    => "hello"

-----

2 points by Pauan 4595 days ago | link

"Looks pretty good though I'm not so sure about the double enter requirement."

It's not just wart: readable has the same issue. The problem is that you don't know if the user is finished or if they want to enter a multi-line expression. With parentheses, you always know whether the expression is completed or not, but with whitespace, you don't.

The same is true even in Python. If you type in this:

  >>> def foo(x):
  ...   return x
You have to hit enter twice. In some cases, Python is smart enough to know that the expression ended, so you only have to hit enter once:

  >>> 1 + 2
But that's because Python's grammar is more restricted in certain areas. That doesn't work with S-expressions because they're so general.

-----

2 points by kinleyd 4595 days ago | link

I realized after I'd read wart's readme that parens were optional, though I don't think that would have been enough to clue me in on the double enter requirement. :)

-----

3 points by akkartik 4595 days ago | link

Yeah, I didn't expect everyone to remember that :) I just wanted a sense of whether the no-prompt prompt was intuitive. So far it seems to be intuitive!

-----

2 points by fallintothis 4595 days ago | link

One more vote for "intuitive". Works surprisingly well.

-----

1 point by akkartik 4595 days ago | link

Thanks a lot for the comments! Pauan's right that the indent sensitivity seems to require the two newlines, and it is indeed weird that responses get grouped with the next command. I'm still looking for a better approach.

I'm interested in that warning you get. Are you on a 64-bit system? Could you type in the following into gdb and share the results?

  $ gdb -q
  (gdb) p sizeof(int)
  (gdb) p sizeof(long)
  (gdb) p sizeof(void*)
Edit: I just noticed that gdb on my machine gives different results with and without a binary. So you'll need to invoke it from the wart directory like so:

  $ gdb -q wart_bin

-----

2 points by kinleyd 4595 days ago | link

You are welcome, akkartik, and yes, I'm on a 64-bit system. Here's the info you wanted:

    [kdd@780 wart]$ gdb -q wart_bin
    Reading symbols from /home/kdd/My-Apps/wart/wart_bin...(no debugging symbols found)...done.
    (gdb) p sizeof(int)
    $1 = 4
    (gdb) p sizeof(long)
    $2 = 8
    (gdb) p sizeof(void*)
    $3 = 8

-----

1 point by akkartik 4595 days ago | link

Thanks! On my machine (gcc 4.4.3) I only get that warning for C files, not C++. Weird. What version gcc do you have?

  $ gcc --version

-----

2 points by kinleyd 4594 days ago | link

Also, it seems that error message came up only the first time I ran wart. I haven't seen it in later executions so there's probably no need for any additional concern. :)

-----

1 point by akkartik 4594 days ago | link

It comes up when building the C files. Since you haven't made any changes to the sources since there's no need to rebuild. But you can see it again if you first run:

  $ make clean

-----

2 points by kinleyd 4594 days ago | link

Ah yes, I see that now. So may be something to sweat a bit about, after all. :)

-----

2 points by kinleyd 4595 days ago | link

gcc 4.7.2

-----

2 points by jsgrahamus 4595 days ago | link

I received no error messages.

I did try factorial and got some strange answers:

  (def fact (n) (if (< n 2) 1 (* n (fact (- n 1)))))
 
  => (object function {sig, body, })
  (fact 5)
 
  => 120
  (fact 1000)

  => 0
  (fact 10)

  => 3628800
  (fact 21)

  => -4249290049419214848
This is was run on Scientific Linux 6.2 in Virtual Box on Windows 7 Home Premium (64-bit)

-----

1 point by akkartik 4595 days ago | link

Thanks a lot! Yes, wart doesn't support bignums yet. Its arithmetic is that of the underlying C, which on a 64-bit machine can handle factorial of 20, but not 21.

  fact.20

  => 2432902008176640000

-----