Working with the LFE REPL

46 views
Skip to first unread message

dun...@cogitat.io

unread,
Feb 9, 2013, 4:01:07 PM2/9/13
to lisp-flavo...@googlegroups.com
Hey all,

What's the best way to recover from an error in the REPL? In the Erlang shell, one can ^G, q, and start a new shell. Is there any way to recover similarly in LFE? (I've tried, but as one might expect, what's started in lfe is an erl shell).

Thanks!

d

rvirding

unread,
Feb 9, 2013, 6:32:12 PM2/9/13
to lisp-flavo...@googlegroups.com
Hi Duncan,

It is good you asked as it helped me find an upgrade to the shell that needed to be made: it crashed when trying to print out a stacktrace. This has been fixed and committed on github to the 'develop' branch which also contains a few other goodies. I will merge into the 'master' branch but there are a few changes I would like to do first. Amongst other things change to the Apache License v2.0. This should not result in any changes for users (no "copyleft") but it is better written and more precise than the BSD one I have now. When this is done I will merge.

To answer your question:

In the JCL (which you enter with ^G) you can give an argument to the 's' command saying which shell, module really, you wish to run. The default is shell. So doing "s lfe_shell" works:

rv ~/erlang/lfe$ ./lfe -pa ebin
Erlang R15B01 (erts-5.9.1) [source] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]

LFE Shell V5.9.1 (abort with ^G)
> (set a [x y z])
exception error: #(unbound_func #(x 2))

> (set a '(x y z))
(x y z)
> a
(x y z)
>
User switch command
 --> j
   1* {lfe_shell,start,[]}
 --> s lfe_shell
 --> j
   1  {lfe_shell,start,[]}
   2* {lfe_shell,start,[]}
 --> c 2
LFE Shell V5.9.1 (abort with ^G)
> a
exception error: #(unbound_symb a)

>
So there are now two shells. Is this what you meant.

Robert

Duncan McGreggor

unread,
Feb 9, 2013, 7:09:49 PM2/9/13
to lisp-flavo...@googlegroups.com
On 2/9/13 3:32 PM, rvirding wrote:
Hi Duncan,

It is good you asked as it helped me find an upgrade to the shell that needed to be made: it crashed when trying to print out a stacktrace. This has been fixed and committed on github to the 'develop' branch which also contains a few other goodies. I will merge into the 'master' branch but there are a few changes I would like to do first. Amongst other things change to the Apache License v2.0. This should not result in any changes for users (no "copyleft") but it is better written and more precise than the BSD one I have now. When this is done I will merge.

Nice :-)


To answer your question:

In the JCL (which you enter with ^G) you can give an argument to the 's' command saying which shell, module really, you wish to run. The default is shell. So doing "s lfe_shell" works:

rv ~/erlang/lfe$ ./lfe -pa ebin
Erlang R15B01 (erts-5.9.1) [source] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]

LFE Shell V5.9.1 (abort with ^G)
> (set a [x y z])
exception error: #(unbound_func #(x 2))

> (set a '(x y z))
(x y z)
> a
(x y z)
>
User switch command
 --> j
   1* {lfe_shell,start,[]}
 --> s lfe_shell
 --> j
   1  {lfe_shell,start,[]}
   2* {lfe_shell,start,[]}
 --> c 2
LFE Shell V5.9.1 (abort with ^G)
> a
exception error: #(unbound_symb a)

>
So there are now two shells. Is this what you meant.

Excellent! That's exactly what I was trying to ask for :-)

Thanks so much!

d


Robert


On Saturday, February 9, 2013 10:01:07 PM UTC+1, dun...@cogitat.io wrote:
Hey all,

What's the best way to recover from an error in the REPL? In the Erlang shell, one can ^G, q, and start a new shell. Is there any way to recover similarly in LFE? (I've tried, but as one might expect, what's started in lfe is an erl shell).

Thanks!

d
--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.
Visit this group at http://groups.google.com/group/lisp-flavoured-erlang?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Duncan McGreggor

unread,
Feb 9, 2013, 7:15:02 PM2/9/13
to lisp-flavo...@googlegroups.com
On 2/9/13 3:32 PM, rvirding wrote:
Hi Duncan,

It is good you asked as it helped me find an upgrade to the shell that needed to be made: it crashed when trying to print out a stacktrace. This has been fixed and committed on github to the 'develop' branch which also contains a few other goodies. I will merge into the 'master' branch but there are a few changes I would like to do first. Amongst other things change to the Apache License v2.0. This should not result in any changes for users (no "copyleft") but it is better written and more precise than the BSD one I have now. When this is done I will merge.

To answer your question:

In the JCL (which you enter with ^G) you can give an argument to the 's' command saying which shell, module really, you wish to run. The default is shell. So doing "s lfe_shell" works:

rv ~/erlang/lfe$ ./lfe -pa ebin
Erlang R15B01 (erts-5.9.1) [source] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]

LFE Shell V5.9.1 (abort with ^G)
> (set a [x y z])
exception error: #(unbound_func #(x 2))
Hrm, interesting. I see that I'm not getting the same behaviour you are... any time I do something that's not legal, I don't get an exception; my shell process terminates.

For example, entering the same (bad) command above, produces this in my REPL:

*** ERROR: Shell process terminated! (^G to start new job) ***

=ERROR REPORT==== 9-Feb-2013::16:09:12 ===
                                          Error in process <0.30.0> with exit value: {function_clause,[{lfe_lib,'-format_stacktrace/3-fun-0-',[{lfe_shell,server_loop,2,[{file,"src/lfe_shell.erl"},{line,70}]},#Fun<lfe_shell.2.62954474>],[{file,"src/lfe_lib.erl"},{line,417}]},{lists,dropwhile,2,[{file,"lists.erl"},{line,1320}]},{lfe_lib,format_stacktrace...

This is why I asked about starting a new shell, since I thought that the REPL was just in a fragile state ;-)

I'm running off of the develop branch (46c38b35e656080e9ee552493399025e5eda2b11, Thu Dec 13 15:10:40 2012 -0800).

d

> (set a '(x y z))
(x y z)
> a
(x y z)
>
User switch command
 --> j
   1* {lfe_shell,start,[]}
 --> s lfe_shell
 --> j
   1  {lfe_shell,start,[]}
   2* {lfe_shell,start,[]}
 --> c 2
LFE Shell V5.9.1 (abort with ^G)
> a
exception error: #(unbound_symb a)

>
So there are now two shells. Is this what you meant.

Robert


On Saturday, February 9, 2013 10:01:07 PM UTC+1, dun...@cogitat.io wrote:
Hey all,

What's the best way to recover from an error in the REPL? In the Erlang shell, one can ^G, q, and start a new shell. Is there any way to recover similarly in LFE? (I've tried, but as one might expect, what's started in lfe is an erl shell).

Thanks!

d
--

Duncan McGreggor

unread,
Feb 9, 2013, 7:31:35 PM2/9/13
to lisp-flavo...@googlegroups.com
On 2/9/13 4:15 PM, Duncan McGreggor wrote:
On 2/9/13 3:32 PM, rvirding wrote:
Hi Duncan,

It is good you asked as it helped me find an upgrade to the shell that needed to be made: it crashed when trying to print out a stacktrace. This has been fixed and committed on github to the 'develop' branch which also contains a few other goodies. I will merge into the 'master' branch but there are a few changes I would like to do first. Amongst other things change to the Apache License v2.0. This should not result in any changes for users (no "copyleft") but it is better written and more precise than the BSD one I have now. When this is done I will merge.

To answer your question:

In the JCL (which you enter with ^G) you can give an argument to the 's' command saying which shell, module really, you wish to run. The default is shell. So doing "s lfe_shell" works:

rv ~/erlang/lfe$ ./lfe -pa ebin
Erlang R15B01 (erts-5.9.1) [source] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]

LFE Shell V5.9.1 (abort with ^G)
> (set a [x y z])
exception error: #(unbound_func #(x 2))
Hrm, interesting. I see that I'm not getting the same behaviour you are... any time I do something that's not legal, I don't get an exception; my shell process terminates.

For example, entering the same (bad) command above, produces this in my REPL:

*** ERROR: Shell process terminated! (^G to start new job) ***

=ERROR REPORT==== 9-Feb-2013::16:09:12 ===
                                          Error in process <0.30.0> with exit value: {function_clause,[{lfe_lib,'-format_stacktrace/3-fun-0-',[{lfe_shell,server_loop,2,[{file,"src/lfe_shell.erl"},{line,70}]},#Fun<lfe_shell.2.62954474>],[{file,"src/lfe_lib.erl"},{line,417}]},{lists,dropwhile,2,[{file,"lists.erl"},{line,1320}]},{lfe_lib,format_stacktrace...

This is why I asked about starting a new shell, since I thought that the REPL was just in a fragile state ;-)

I'm running off of the develop branch (46c38b35e656080e9ee552493399025e5eda2b11, Thu Dec 13 15:10:40 2012 -0800).

d
One more bit of data that might be useful: I'm on a 64-bit machine and slightly different version numbers.

Erlang R15B03 (erts-5.9.3.1) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false] [dtrace]

Not sure if this could be a bug due to a missed edge case...

d

rvirding

unread,
Feb 9, 2013, 7:31:51 PM2/9/13
to lisp-flavo...@googlegroups.com

On Sunday, February 10, 2013 1:15:02 AM UTC+1, Duncan McGreggor wrote:
Hrm, interesting. I see that I'm not getting the same behaviour you are... any time I do something that's not legal, I don't get an exception; my shell process terminates.

For example, entering the same (bad) command above, produces this in my REPL:

*** ERROR: Shell process terminated! (^G to start new job) ***

=ERROR REPORT==== 9-Feb-2013::16:09:12 ===
                                          Error in process <0.30.0> with exit value: {function_clause,[{lfe_lib,'-format_stacktrace/3-fun-0-',[{lfe_shell,server_loop,2,[{file,"src/lfe_shell.erl"},{line,70}]},#Fun<lfe_shell.2.62954474>],[{file,"src/lfe_lib.erl"},{line,417}]},{lists,dropwhile,2,[{file,"lists.erl"},{line,1320}]},{lfe_lib,format_stacktrace...

This is why I asked about starting a new shell, since I thought that the REPL was just in a fragile state ;-)

I'm running off of the develop branch (46c38b35e656080e9ee552493399025e5eda2b11, Thu Dec 13 15:10:40 2012 -0800).
 

Ok, then I slightly misinterpreted your question. The behaviour you are getting here is the one I found and just fixed on the develop branch, a192d497a8bc7a440bdcdc05982f92629685ead9, from Sat Feb 09, 2012. So you will need to pull again from develop.

It wasn't the shell per se that was fragile but the functions printing out the stacktrace. Which should now be fixed. Sorry about that.

Robert

Duncan McGreggor

unread,
Feb 9, 2013, 7:50:25 PM2/9/13
to lisp-flavo...@googlegroups.com
On 2/9/13 4:31 PM, rvirding wrote:

On Sunday, February 10, 2013 1:15:02 AM UTC+1, Duncan McGreggor wrote:
Hrm, interesting. I see that I'm not getting the same behaviour you are... any time I do something that's not legal, I don't get an exception; my shell process terminates.

For example, entering the same (bad) command above, produces this in my REPL:

*** ERROR: Shell process terminated! (^G to start new job) ***

=ERROR REPORT==== 9-Feb-2013::16:09:12 ===
                                          Error in process <0.30.0> with exit value: {function_clause,[{lfe_lib,'-format_stacktrace/3-fun-0-',[{lfe_shell,server_loop,2,[{file,"src/lfe_shell.erl"},{line,70}]},#Fun<lfe_shell.2.62954474>],[{file,"src/lfe_lib.erl"},{line,417}]},{lists,dropwhile,2,[{file,"lists.erl"},{line,1320}]},{lfe_lib,format_stacktrace...

This is why I asked about starting a new shell, since I thought that the REPL was just in a fragile state ;-)

I'm running off of the develop branch (46c38b35e656080e9ee552493399025e5eda2b11, Thu Dec 13 15:10:40 2012 -0800).
 

Ok, then I slightly misinterpreted your question. The behaviour you are getting here is the one I found and just fixed on the develop branch, a192d497a8bc7a440bdcdc05982f92629685ead9, from Sat Feb 09, 2012. So you will need to pull again from develop.
Perfect! It's working like a dream now -- so much more convenient that quitting and restarting or creating a new shell from the JCL ;-)

It wasn't the shell per se that was fragile but the functions printing out the stacktrace. Which should now be fixed. Sorry about that.
No worries! Thanks for such an amazingly quick fix :-)

d


Robert

Reply all
Reply to author
Forward
0 new messages