1
0
Fork
You've already forked mit
0

Different results in REPL vs geiser-eval-definition #7

Closed
opened 2022年08月30日 02:51:11 +02:00 by karthink · 14 comments
karthink commented 2022年08月30日 02:51:11 +02:00 (Migrated from gitlab.com)
Copy link

This is a strange problem.

I'm using MIT scheme with the SCMUtils library (as detailed here).

When I type in a form that involves some procedures provided by this library in the REPL, things work fine. For example:

1 (user) => Gamma
#| Gamma |#
1 (user) => (Gamma (literal-function 'q))
#|
(lambda (t)
 ???)
|#

Gamma is a procedure defined by SCMUtils. Everything works as expected in the REPL.

When I try the same thing from a buffer using geiser-eval-definition, I get an error:

Gamma ;Press C-c C-c here
Gamma
retort-syntax
;Unbound variable: Gamma
;To continue, call RESTART with an option number:
; (RESTART 3) => Specify a value to use instead of Gamma.
; (RESTART 2) => Define Gamma to a given value.
; (RESTART 1) => Return to read-eval-print level 1.
2 error> 

As a result I'm unable to evaluate most forms from the Scheme buffer. Some functions defined by SCMUtils, like literal-function, actually do work fine when eval'd from the scheme buffer:

literal-function ;Press C-c C-c here
=> #[compiled-procedure 38 (literal-function "litfun" #x1c) #x1a #x21b49e2]

More info:

  • I'm using Emacs 28.1, Geiser version 0.25.1 (commit ecfbef1c771f3a5c34f46fb2b387b9669c661d2f)
  • I've tested this with the latest Geiser version (0.26) as well.
  • I've tried MIT Scheme versions 10.1.1 and 11.2.
  • I've confirmed that the scheme buffer in question is associated with the correct mit-scheme REPL by Geiser.
  • I tried to track the control flow of geiser-eval-definition. I don't understand the continuation that's passed to the REPL, but everything seems to work fine up to geiser-con--connection-add-request. I couldn't understand any more of it since I don't understand transaction queues (tq-enqueue).
This is a strange problem. I'm using MIT scheme with the SCMUtils library (as detailed [here](https://groups.csail.mit.edu/mac/users/gjs/6946/linux-install.htm)). When I type in a form that involves some procedures provided by this library in the REPL, things work fine. For example: ```scheme 1 (user) => Gamma #| Gamma |# 1 (user) => (Gamma (literal-function 'q)) #| (lambda (t) ???) |# ``` `Gamma` is a procedure defined by SCMUtils. Everything works as expected in the REPL. When I try the same thing from a buffer using `geiser-eval-definition`, I get an error: ```scheme Gamma ;Press C-c C-c here ``` ``` Gamma retort-syntax ;Unbound variable: Gamma ;To continue, call RESTART with an option number: ; (RESTART 3) => Specify a value to use instead of Gamma. ; (RESTART 2) => Define Gamma to a given value. ; (RESTART 1) => Return to read-eval-print level 1. 2 error> ``` As a result I'm unable to evaluate most forms from the Scheme buffer. Some functions defined by SCMUtils, like `literal-function`, actually do work fine when eval'd from the scheme buffer: ```scheme literal-function ;Press C-c C-c here ``` ``` => #[compiled-procedure 38 (literal-function "litfun" #x1c) #x1a #x21b49e2] ``` More info: - I'm using Emacs 28.1, Geiser version 0.25.1 (commit `ecfbef1c771f3a5c34f46fb2b387b9669c661d2f`) - I've tested this with the latest Geiser version (0.26) as well. - I've tried MIT Scheme versions 10.1.1 and 11.2. - I've confirmed that the scheme buffer in question is associated with the correct mit-scheme REPL by Geiser. - I tried to track the control flow of `geiser-eval-definition`. I don't understand the continuation that's passed to the REPL, but everything seems to work fine up to `geiser-con--connection-add-request`. I couldn't understand any more of it since I don't understand transaction queues (`tq-enqueue`).
karthink commented 2022年08月30日 02:51:53 +02:00 (Migrated from gitlab.com)
Copy link

changed the description

changed the description
jaor commented 2022年08月30日 02:57:54 +02:00 (Migrated from gitlab.com)
Copy link

moved from geiser#53

moved from geiser#53
jaor commented 2022年08月30日 02:59:05 +02:00 (Migrated from gitlab.com)
Copy link

Moved to geiser-mit, as this looks with all probability as a bug in how code is evaluated specifically for MIT Scheme, and it's in this code where that happens.

Moved to geiser-mit, as this looks with all probability as a bug in how code is evaluated specifically for MIT Scheme, and it's in this code where that happens.
jaor commented 2022年08月30日 03:01:00 +02:00 (Migrated from gitlab.com)
Copy link

The contents of the geiser messages buffer after C-u M-x geiser-show-logs might give a bit more info...

The contents of the geiser messages buffer after C-u M-x geiser-show-logs might give a bit more info...
karthink commented 2022年08月30日 03:30:45 +02:00 (Migrated from gitlab.com)
Copy link

I tried C-u M-x geiser-show-logs and then evaluating Gamma again twice, this is the result:

INFO: REQUEST: <38>: (geiser:eval '#f 'Gamma)
INFO: <38>: processed
INFO: REQUEST: <39>: (geiser:eval '#f 'Gamma)
INFO: <39>: processed
I tried `C-u M-x geiser-show-logs` and then evaluating `Gamma` again twice, this is the result: ``` INFO: REQUEST: <38>: (geiser:eval '#f 'Gamma) INFO: <38>: processed INFO: REQUEST: <39>: (geiser:eval '#f 'Gamma) INFO: <39>: processed ```
jaor commented 2022年08月30日 03:43:15 +02:00 (Migrated from gitlab.com)
Copy link

hmmm, are you sure you pressed the C-u? these logs don't have all the
detail (the responses to the request aren't there...)... what's the
value of geiser-log-verbose-p? can you set it to t manually and retry?

or maybe the REPL was already in error or something?

hmmm, are you sure you pressed the C-u? these logs don't have all the detail (the responses to the request aren't there...)... what's the value of geiser-log-verbose-p? can you set it to t manually and retry? or maybe the REPL was already in error or something?
karthink commented 2022年08月30日 05:01:33 +02:00 (Migrated from gitlab.com)
Copy link
  • I killed the repl and the geiser messages buffer.
  • geiser-log-verbose-p is set to t.
  • I made sure to call geiser-show-logs with the prefix-arg.
  • I started a fresh REPL
  • Typed in "Gamma" and hit C-c C-c. This is the output:

INFO: REQUEST: <1>: (geiser:eval '#f '(geiser:completions "Gam"))
INFO: RETORT: ((result "()") (output . ""))
INFO: <1>: processed
INFO: REQUEST: <2>: (geiser:eval '#f '(geiser:completions "Gamma"))
INFO: RETORT: ((result "()") (output . ""))
INFO: <2>: processed
INFO: REQUEST: <3>: (geiser:eval '#f '(geiser:module-completions "Gamma"))
INFO: REQUEST: <4>: (geiser:eval '#f '(geiser:autodoc '(Gamma)))
INFO: RETORT: ((result "()") (output . ""))
INFO: <3>: processed
INFO: <4>: processed
INFO: REQUEST: <5>: (geiser:eval '#f '(geiser:autodoc '(Gamma)))
INFO: <5>: processed
INFO: REQUEST: <6>: (geiser:eval '#f 'Gamma)
INFO: <6>: processed

I then killed everything, restarted the repl and typed in literal-function, which I know is eval'd correctly from the buffer. This is the new log output:

INFO: REQUEST: <1>: (geiser:eval '#f '(geiser:completions "literal"))
INFO: REQUEST: <2>: (geiser:eval '#f '(geiser:autodoc '(literal)))
INFO: RETORT: ((result "(\"literal-apply\" \"literal-column-matrix\" \"literal-down\" \"literal-function\" \"literal-function?\" \"literal-matrix\" \"literal-number\" \"literal-number?\" \"literal-real?\" \"literal-row-matrix\" \"literal-up\" \"literal-vector\")") (output . ""))
INFO: <1>: processed
INFO: <2>: processed
INFO: REQUEST: <3>: (geiser:eval '#f '(geiser:completions "literal"))
INFO: RETORT: ((result "(\"literal-apply\" \"literal-column-matrix\" \"literal-down\" \"literal-function\" \"literal-function?\" \"literal-matrix\" \"literal-number\" \"literal-number?\" \"literal-real?\" \"literal-row-matrix\" \"literal-up\" \"literal-vector\")") (output . ""))
INFO: <3>: processed
INFO: REQUEST: <4>: (geiser:eval '#f '(geiser:completions "literal"))
INFO: RETORT: ((result "(\"literal-apply\" \"literal-column-matrix\" \"literal-down\" \"literal-function\" \"literal-function?\" \"literal-matrix\" \"literal-number\" \"literal-number?\" \"literal-real?\" \"literal-row-matrix\" \"literal-up\" \"literal-vector\")") (output . ""))
INFO: <4>: processed
INFO: REQUEST: <5>: (geiser:eval '#f '(geiser:completions "literal"))
INFO: RETORT: ((result "(\"literal-apply\" \"literal-column-matrix\" \"literal-down\" \"literal-function\" \"literal-function?\" \"literal-matrix\" \"literal-number\" \"literal-number?\" \"literal-real?\" \"literal-row-matrix\" \"literal-up\" \"literal-vector\")") (output . ""))
INFO: <5>: processed
INFO: REQUEST: <6>: (geiser:eval '#f '(geiser:autodoc '(literal-function)))
INFO: <6>: processed
INFO: REQUEST: <7>: (geiser:eval '#f 'literal-function
)
INFO: <7>: processed
INFO: REQUEST: <8>: (geiser:eval '#f '(geiser:autodoc '(literal-function)))
INFO: <8>: processed

I still don't see the responses to the request, not sure what I should be looking for.

- I killed the repl and the geiser messages buffer. - `geiser-log-verbose-p` is set to `t`. - I made sure to call `geiser-show-logs` with the prefix-arg. - I started a fresh REPL - Typed in "Gamma" and hit `C-c C-c`. This is the output: ``` INFO: REQUEST: <1>: (geiser:eval '#f '(geiser:completions "Gam")) INFO: RETORT: ((result "()") (output . "")) INFO: <1>: processed INFO: REQUEST: <2>: (geiser:eval '#f '(geiser:completions "Gamma")) INFO: RETORT: ((result "()") (output . "")) INFO: <2>: processed INFO: REQUEST: <3>: (geiser:eval '#f '(geiser:module-completions "Gamma")) INFO: REQUEST: <4>: (geiser:eval '#f '(geiser:autodoc '(Gamma))) INFO: RETORT: ((result "()") (output . "")) INFO: <3>: processed INFO: <4>: processed INFO: REQUEST: <5>: (geiser:eval '#f '(geiser:autodoc '(Gamma))) INFO: <5>: processed INFO: REQUEST: <6>: (geiser:eval '#f 'Gamma) INFO: <6>: processed ``` I then killed everything, restarted the repl and typed in `literal-function`, which I know is eval'd correctly from the buffer. This is the new log output: ``` INFO: REQUEST: <1>: (geiser:eval '#f '(geiser:completions "literal")) INFO: REQUEST: <2>: (geiser:eval '#f '(geiser:autodoc '(literal))) INFO: RETORT: ((result "(\"literal-apply\" \"literal-column-matrix\" \"literal-down\" \"literal-function\" \"literal-function?\" \"literal-matrix\" \"literal-number\" \"literal-number?\" \"literal-real?\" \"literal-row-matrix\" \"literal-up\" \"literal-vector\")") (output . "")) INFO: <1>: processed INFO: <2>: processed INFO: REQUEST: <3>: (geiser:eval '#f '(geiser:completions "literal")) INFO: RETORT: ((result "(\"literal-apply\" \"literal-column-matrix\" \"literal-down\" \"literal-function\" \"literal-function?\" \"literal-matrix\" \"literal-number\" \"literal-number?\" \"literal-real?\" \"literal-row-matrix\" \"literal-up\" \"literal-vector\")") (output . "")) INFO: <3>: processed INFO: REQUEST: <4>: (geiser:eval '#f '(geiser:completions "literal")) INFO: RETORT: ((result "(\"literal-apply\" \"literal-column-matrix\" \"literal-down\" \"literal-function\" \"literal-function?\" \"literal-matrix\" \"literal-number\" \"literal-number?\" \"literal-real?\" \"literal-row-matrix\" \"literal-up\" \"literal-vector\")") (output . "")) INFO: <4>: processed INFO: REQUEST: <5>: (geiser:eval '#f '(geiser:completions "literal")) INFO: RETORT: ((result "(\"literal-apply\" \"literal-column-matrix\" \"literal-down\" \"literal-function\" \"literal-function?\" \"literal-matrix\" \"literal-number\" \"literal-number?\" \"literal-real?\" \"literal-row-matrix\" \"literal-up\" \"literal-vector\")") (output . "")) INFO: <5>: processed INFO: REQUEST: <6>: (geiser:eval '#f '(geiser:autodoc '(literal-function))) INFO: <6>: processed INFO: REQUEST: <7>: (geiser:eval '#f 'literal-function ) INFO: <7>: processed INFO: REQUEST: <8>: (geiser:eval '#f '(geiser:autodoc '(literal-function))) INFO: <8>: processed ``` I still don't see the responses to the request, not sure what I should be looking for.
jaor commented 2022年08月30日 05:08:18 +02:00 (Migrated from gitlab.com)
Copy link

I still don't see the responses to the request, not sure what I should
be looking for.

so what's probably happening is that the evaluation function in scheme
is signalling an error, putting the underlying MIT REPL in debug mode
and not returning anything to the scheme side. unfortunately, i don't
know how the scheme side of geiser-mit is implemented...

...

On Tue, Aug 30 2022, karthink (@karthink) wrote:

> I still don't see the responses to the request, not sure what I should > be looking for. so what's probably happening is that the evaluation function in scheme is signalling an error, putting the underlying MIT REPL in debug mode and not returning anything to the scheme side. unfortunately, i don't know how the scheme side of geiser-mit is implemented... <details><summary>...</summary> On Tue, Aug 30 2022, karthink (@karthink) wrote: </details>
karthink commented 2022年08月30日 21:42:10 +02:00 (Migrated from gitlab.com)
Copy link

unfortunately, i don't know how the scheme side of geiser-mit is implemented...

I assume this refers to the scheme code in src/geiser/? I took a look but couldn't find anything that stands out.

I tested many more procedures besides Gamma today, and observed the same result: they work in the REPL, they're not recognized when eval-ing a buffer.

> unfortunately, i don't know how the scheme side of geiser-mit is implemented... I assume this refers to the scheme code in `src/geiser/`? I took a look but couldn't find anything that stands out. I tested many more procedures besides `Gamma` today, and observed the same result: they work in the REPL, they're not recognized when eval-ing a buffer.
jaor commented 2022年08月30日 21:50:35 +02:00 (Migrated from gitlab.com)
Copy link

karthink commented on a discussion: https://gitlab.com/emacs-geiser/mit/-/issues/7#note_1082938816

unfortunately, i don't know how the scheme side of geiser-mit is implemented...

I assume this refers to the scheme code in src/geiser/? I took a
look but couldn't find anything that stands out.

yes. that's the code responsible for the evaluation and formatting of
the result that must go back to emacs, as an alist ((result ..) (output ..) ..), like the ones shown in the log when things works. when this
fails, we don't see any response in the log... (that result alist should
be printed by the scheme process to its stdout).

I tested many more procedures besides Gamma today, and observed the
same result: they work in the REPL, they're not recognized when
eval-ing a buffer.

i don't have a working scmutils to try at the moment. i am guessing
that the printer of the library is somehow interfering...

jao

...

On Tue, Aug 30 2022, karthink (@karthink) wrote:

A book must be an axe for the frozen sea inside of us.
-Franz Kafka (1883-1924)

> karthink commented on a discussion: https://gitlab.com/emacs-geiser/mit/-/issues/7#note_1082938816 > >> unfortunately, i don't know how the scheme side of geiser-mit is implemented... > > I assume this refers to the scheme code in `src/geiser/`? I took a > look but couldn't find anything that stands out. yes. that's the code responsible for the evaluation and formatting of the result that must go back to emacs, as an alist `((result ..) (output ..) ..)`, like the ones shown in the log when things works. when this fails, we don't see any response in the log... (that result alist should be printed by the scheme process to its stdout). > I tested many more procedures besides `Gamma` today, and observed the > same result: they work in the REPL, they're not recognized when > eval-ing a buffer. i don't have a working scmutils to try at the moment. i am guessing that the printer of the library is somehow interfering... jao <details><summary>...</summary> On Tue, Aug 30 2022, karthink (@karthink) wrote: -- A book must be an axe for the frozen sea inside of us. -Franz Kafka (1883-1924) </details>
fedeinthemix commented 2024年09月08日 12:30:16 +02:00 (Migrated from gitlab.com)
Copy link

Same problem here. It seems that geiser-mit uses the wrong environment when evaluating expressions.

@jaor you can easily load "scmutils" by donwloading the it here picking scmutils-20230902.tar.gz. You unpack in any directory, where you'll find a file called mechanics.com. You can just load it in mit-scheme by passing --band mechanics.com (use the full path). Since gieser-mit doesn't provide a mean to pass custom arguments, I just created a very simple shell script prepending --band ... and set geiser-mit-binary.

It'd be great to get this working.

You can test with (+ 'a 'a). It should give (* 2 'a). Instead I get an error saying that the INTEGER addition doesn't accept the object 'a.

Thanks for your great geiser package!

Same problem here. It seems that `geiser-mit` uses the wrong environment when evaluating expressions. @jaor you can easily load "scmutils" by donwloading the it [here](https://groups.csail.mit.edu/mac/users/gjs/6946/mechanics-system-installation/native-code/) picking `scmutils-20230902.tar.gz`. You unpack in any directory, where you'll find a file called `mechanics.com`. You can just load it in `mit-scheme` by passing `--band mechanics.com` (use the full path). Since `gieser-mit` doesn't provide a mean to pass custom arguments, I just created a very simple shell script prepending `--band ...` and set `geiser-mit-binary`. It'd be great to get this working. You can test with `(+ 'a 'a)`. It should give `(* 2 'a)`. Instead I get an error saying that the INTEGER addition doesn't accept the object 'a. Thanks for your great `geiser` package!
fedeinthemix commented 2024年09月08日 21:29:49 +02:00 (Migrated from gitlab.com)
Copy link

I believe that the error is in emacs.scm

(define (geiser:eval module form . rest)
 rest
 (let* ((output (open-output-string))
 (environment (package/environment (find-package (if module
 module
 '(user))
 #t)))

When working on a plain scheme file (not a package), module is #f, but scmutils runs in an environment called user-generic-environment. Checking in the REPL

1 (user) => (ge '(user))
;package: (user)#| #[environment 60] |#
1 (user) => (+ 'a 'a)
;The object a, passed as the first argument to integer-add, is not the correct type.
;To continue, call RESTART with an option number:
; (RESTART 2) => Specify an argument to use in its place.
; (RESTART 1) => Return to read-eval-print level 1.
2 error> (restart 1)
;Abort!
1 (user) => (ge user-initial-environment)
;package: (user)#| #[environment 60] |#
1 (user) => (+ 'a 'a)
;The object a, passed as the first argument to integer-add, is not the correct type.
;To continue, call RESTART with an option number:
; (RESTART 2) => Specify an argument to use in its place.
; (RESTART 1) => Return to read-eval-print level 1.
2 error> (restart 1)
;Abort!
1 (user) => (ge user-generic-environment)
#| #[environment 12] |#
1 (user) => (+ 'a 'a)
#|
(* 2 a)
|#
1 (user) => 

The current REPL environment can be found with

1 (user) => (nearest-repl/environment)
#| #[environment 12] |#
I believe that the error is in `emacs.scm` ```scheme (define (geiser:eval module form . rest) rest (let* ((output (open-output-string)) (environment (package/environment (find-package (if module module '(user)) #t))) ``` When working on a plain scheme file (not a package), `module` is `#f`, but `scmutils` runs in an environment called `user-generic-environment`. Checking in the REPL ```scheme 1 (user) => (ge '(user)) ;package: (user)#| #[environment 60] |# 1 (user) => (+ 'a 'a) ;The object a, passed as the first argument to integer-add, is not the correct type. ;To continue, call RESTART with an option number: ; (RESTART 2) => Specify an argument to use in its place. ; (RESTART 1) => Return to read-eval-print level 1. 2 error> (restart 1) ;Abort! 1 (user) => (ge user-initial-environment) ;package: (user)#| #[environment 60] |# 1 (user) => (+ 'a 'a) ;The object a, passed as the first argument to integer-add, is not the correct type. ;To continue, call RESTART with an option number: ; (RESTART 2) => Specify an argument to use in its place. ; (RESTART 1) => Return to read-eval-print level 1. 2 error> (restart 1) ;Abort! 1 (user) => (ge user-generic-environment) #| #[environment 12] |# 1 (user) => (+ 'a 'a) #| (* 2 a) |# 1 (user) => ``` The current REPL environment can be found with ```scheme 1 (user) => (nearest-repl/environment) #| #[environment 12] |# ```
fedeinthemix commented 2024年09月09日 08:29:33 +02:00 (Migrated from gitlab.com)
Copy link

I confirm that changing the snippet indicated above in emacs.scm as follows fixes the problem

(define (geiser:eval module form . rest)
 rest
 (let* ((output (open-output-string))
 (environment (if module 
 (package/environment (find-package module #t))
 (nearest-repl/environment)))

Simple test: Expression run in a geiser-mit buffer

(define res (+ 'a 'a))

and value of res in REPL

1 (user) => res
#|
(* 2 a)
|#
1 (user) => 
I confirm that changing the snippet indicated above in `emacs.scm` as follows fixes the problem ```scheme (define (geiser:eval module form . rest) rest (let* ((output (open-output-string)) (environment (if module (package/environment (find-package module #t)) (nearest-repl/environment))) ``` Simple test: Expression run in a `geiser-mit` buffer ```scheme (define res (+ 'a 'a)) ``` and value of `res` in REPL ```scheme 1 (user) => res #| (* 2 a) |# 1 (user) => ```
fedeinthemix commented 2024年09月09日 14:08:51 +02:00 (Migrated from gitlab.com)
Copy link

mentioned in merge request !13

mentioned in merge request !13
jaor (Migrated from gitlab.com) closed this issue 2024年09月09日 21:48:50 +02:00
Sign in to join this conversation.
No Branch/Tag specified
master
0.15
0.14
0.13
0.12
0.11.2
0.11.1
0.11
0.10
0.9
0.8.1
0.8
0.7
0.6
0.5
0.4
0.3
0.2.2
0.2.1
0.2
0.1.4
0.1.3
0.1.2
0.1.1
0.1
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
geiser/mit#7
Reference in a new issue
geiser/mit
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?