search

seanjensengrey / mosh-scheme

Automatically exported from code.google.com/p/mosh-scheme
Other
0 stars 0 forks source link

condition-printer unbound in concurrent example #196

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Enter a mosh REPL
2. (import (mosh concurrent))
3. (spawn (lambda (x) (display x)) 'hello '((rnrs)))

What is the expected output?

<some pid representation>
hellomosh>  (not necessarily in that order)

What do you see instead?

#<#<type:record-type-descriptorpid #f IV53 #f #f ((#f . vm) (#f . mail-box) (#t 
. links)) >#<vm  9d47e0> #<#<type:record-type-descriptormail-box #f IV3c #f #f 
((#f . condition) (#f . mutex) (#t . mails)) >#<condition-variable> #<mutex> 
(()) > () >

mosh>  Condition components:
 1. &who             who: condition-printer
 2. &message         message: "unbound identifier"
 3. &undefined

 Exception:
     error in raise: returned from non-continuable exception

 Stack trace:
    1. throw: <subr>
    2. (raise c):  baselib.scm:943
    3. (syntax-type e r):  psyntax.scm:10
    4. (syntax-type e r):  psyntax.scm:10
    5. (chi-expr e r mr):  psyntax.scm:10
    6. (chi-expr* e* r mr):  psyntax.scm:10
    7. (lambda (x x*) ...):  psyntax.scm:10
    8. apply: <subr>

What version of the product are you using? On what operating system?
0.2.6, linux amd64

Please provide any additional information below.
This doesn't happen if you provide '((rnrs) (mosh concurrent)) as the third 
argument to SPAWN.  So I guess the exception is coming from the new process 
trying to print its own description (though I don't know why it would do that). 
 condition-printer procedure is available in the REPL parent process before 
calling SPAWN.  Not really clear whether this is a manual or code issue.

Original issue reported on code.google.com by amoe...@gmail.com on 9 Mar 2011 at 6:35

GoogleCodeExporter commented 9 years ago 
This is known API design issue. Documentation should be fixed.
You should manually specify (rnrs) and (mosh) or (mosh concurrent) within a 
SPAWN.

Cc higepon.

(Related to Issue 191.)

Original comment by oku...@gmail.com on 10 Mar 2011 at 1:15

GoogleCodeExporter commented 9 years ago 
Issue 191 has been merged into this issue.

Original comment by oku...@gmail.com on 23 Apr 2011 at 7:42

GoogleCodeExporter commented 9 years ago 
Currently, any practical use-case will be required to specify

 ((rnrs) (mosh concurrent) (except (mosh) condition-printer))

as import-spec.
So, we should 1) drop condition-printer from (mosh) or 2) from (mosh 
concurrent).

Original comment by oku...@gmail.com on 23 Apr 2011 at 7:48

GoogleCodeExporter commented 9 years ago 
Could you drop the condition-printer from (mosh concurrent)?

Original comment by hige...@gmail.com on 26 Apr 2011 at 1:59

GoogleCodeExporter commented 9 years ago 
Once psyntax-mosh buildscript updated, i'll take care of further updates
(e.g. update nmosh and test suites)
because there is no safe way to update psyntax-mosh (anyone except higepon...)

Original comment by oku...@gmail.com on 26 Apr 2011 at 1:41

GoogleCodeExporter commented 9 years ago 
There is no need to update psyntax-mosh when remove condition printer from 
(mosh concurrent).

Am I overlooking something?

Original comment by hige...@gmail.com on 26 Apr 2011 at 2:08

GoogleCodeExporter commented 9 years ago 
Hmm, you meant "remove" condition-printer from (mosh concurrent), right?
(I'd take "port" (mosh concurrent)'s condition-printer into (mosh))

Original comment by oku...@gmail.com on 26 Apr 2011 at 2:28

GoogleCodeExporter commented 9 years ago 
Fixed.

https://github.com/okuoku/mosh/commit/f296d813436bf8f6554b4e1a105bd791f0bb8512

Original comment by oku...@gmail.com on 26 Apr 2011 at 3:28