Geiser struggles with reloading of Typed Racket definitions #6

jaor commented 2014年01月02日 04:48:10 +01:00 (Migrated from gitlab.com)

Created by: Fuuzetsu

Create an example Racket file such as:

#lang typed/racket
(define: x : Number 7)

Save, then run-racket. In the file buffer, C-c C-k to compile the file then C-u C-c C-z to load the file into Geiser REPL. Here we can simply put x into the REPL to get back

racket@poly.rkt> x
- : Number
7

Now change the same file to look like

#lang typed/racket
(define: x : Number 7)
(define: y : Number 8)

Recompile with C-c C-k and re-enter with C-u C-c C-z. We can still ask the type of x in the REPL and get the correct answer but if we try to get the type of the newly defined y, instead of the answer I get:

stdin::917: Type Checker: untyped identifier y
 in: y
 context...:
 /usr/lib/racket/collects/typed-racket/utils/tc-utils.rkt:85:0: report-all-errors
 /usr/lib/racket/collects/typed-racket/typecheck/tc-toplevel.rkt:411:0: tc-toplevel-form
 temp53
 /usr/lib/racket/collects/typed-racket/typed-racket.rkt:62:4
 /usr/lib/racket/collects/racket/private/misc.rkt:96:20

I'm not sure what more info to provide here.
GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.8.6) of 2013年11月24日 on misaki

Linux misaki 3.12.3-gentoo #2 SMP Sat Dec 7 23:14:57 GMT 2013 i686 Intel(R) Core(TM)2 Duo CPU L7700 @ 1.80GHz GenuineIntel GNU/Linux

Welcome to Racket v5.3.6.

Racket compiled from Gentoo's Portage with following USE flags:
X threads -backtrace -cairo -doc -futures -jit -places -plot

I'd give my geiser version but I seem to be getting a curious error:
progn: Cannot open load file: geiser-version

and my C-h C-f geiser-version gives a weird description:

geiser-version is an interactive autoloaded Lisp function.
[Arg list not available until function definition is loaded.]
Echo Geiser's version.

Perhaps something is completely wrong with my set-up?

*Created by: Fuuzetsu* Create an example Racket file such as: ``` #lang typed/racket (define: x : Number 7) ``` Save, then `run-racket`. In the file buffer, `C-c C-k` to compile the file then `C-u C-c C-z` to load the file into Geiser REPL. Here we can simply put `x` into the REPL to get back ``` racket@poly.rkt> x - : Number 7 ``` Now change the same file to look like ``` #lang typed/racket (define: x : Number 7) (define: y : Number 8) ``` Recompile with `C-c C-k` and re-enter with `C-u C-c C-z`. We can still ask the type of `x` in the REPL and get the correct answer but if we try to get the type of the newly defined `y`, instead of the answer I get: ``` stdin::917: Type Checker: untyped identifier y in: y context...: /usr/lib/racket/collects/typed-racket/utils/tc-utils.rkt:85:0: report-all-errors /usr/lib/racket/collects/typed-racket/typecheck/tc-toplevel.rkt:411:0: tc-toplevel-form temp53 /usr/lib/racket/collects/typed-racket/typed-racket.rkt:62:4 /usr/lib/racket/collects/racket/private/misc.rkt:96:20 ``` I'm not sure what more info to provide here. GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 3.8.6) of 2013年11月24日 on misaki Linux misaki 3.12.3-gentoo `#2` SMP Sat Dec 7 23:14:57 GMT 2013 i686 Intel(R) Core(TM)2 Duo CPU L7700 @ 1.80GHz GenuineIntel GNU/Linux Welcome to Racket v5.3.6. Racket compiled from Gentoo's Portage with following USE flags: `X threads -backtrace -cairo -doc -futures -jit -places -plot` I'd give my geiser version but I seem to be getting a curious error: progn: `Cannot open load file: geiser-version` and my `C-h C-f geiser-version` gives a weird description: ``` geiser-version is an interactive autoloaded Lisp function. [Arg list not available until function definition is loaded.] Echo Geiser's version. ``` Perhaps something is completely wrong with my set-up?

jaor commented 2014年01月02日 05:00:39 +01:00 (Migrated from gitlab.com)

If you're running Geiser directly from a git checkout or the directory
where you extracted it, without any other kind of installation, the
error for geiser-version is normal. So your setup is most probably
fine!

Thanks for the detailed report. I'll take a look as soon as i can!

If you're running Geiser directly from a git checkout or the directory where you extracted it, without any other kind of installation, the error for geiser-version is normal. So your setup is most probably fine! Thanks for the detailed report. I'll take a look as soon as i can!

jaor commented 2014年01月02日 08:08:34 +01:00 (Migrated from gitlab.com)

Created by: Fuuzetsu

I'm indeed running Geiser from a git submodule under my emacs.d, good to know.

*Created by: Fuuzetsu* I'm indeed running Geiser from a git submodule under my emacs.d, good to know.

jaor commented 2014年01月03日 04:55:25 +01:00 (Migrated from gitlab.com)

Just a quick note to confirm i can reproduce the bug, and a funny
thing i've noticed: calling (eval 'y) in the REPL works and
evaluates to the correct value, so the variable is actually defined in
the namespace (one can also check that's the case with
namespace-mapped-symbols). So the problem seems to be in
interaction between the customized REPL handlers that Geiser
introduces and those used by typed Racket.

Just a quick note to confirm i can reproduce the bug, and a funny thing i've noticed: calling `(eval 'y)` in the REPL works and evaluates to the correct value, so the variable is actually defined in the namespace (one can also check that's the case with `namespace-mapped-symbols`). So the problem seems to be in interaction between the customized REPL handlers that Geiser introduces and those used by typed Racket.

jaor commented 2014年01月04日 01:35:48 +01:00 (Migrated from gitlab.com)

More fun: i can reproduce the problem using plain racket 5.3.6 (in a
terminal, no Emacs or Geiser involved here), and the following file:

------ test.rkt --------
#lang typed/racket
(define: j : Number 10)
(define: k : Number 20)
------ eof test.rkt -----

Here's a pure racket session causing essentially the same problem:

 [/home/jao/tmp]$ racket
 Welcome to Racket v5.3.6.
 > (compile-enforce-module-constants #f)
 > (require "test.rkt")
 > (eval '(define: jk : Number (+ j k)) (module->namespace '(file "test.rkt")))
 > (eval 'jk (module->namespace '(file "test.rkt")))
 20
 > (enter! "test.rkt")
 > j
 - : Number
 10
 > k
 - : Number
 10
 > jk
 stdin::214: Type Checker: untyped identifier jk
 in: jk
 >

So it seems a racket problem, similar perhaps to the one reported in
issue jaor/geiser#18. I've sent an email to the racket mailing list trying to
get some feedback.

More fun: i can reproduce the problem using plain racket 5.3.6 (in a terminal, no Emacs or Geiser involved here), and the following file: ``` ------ test.rkt -------- #lang typed/racket (define: j : Number 10) (define: k : Number 20) ------ eof test.rkt ----- ``` Here's a pure racket session causing essentially the same problem: ``` [/home/jao/tmp]$ racket Welcome to Racket v5.3.6. > (compile-enforce-module-constants #f) > (require "test.rkt") > (eval '(define: jk : Number (+ j k)) (module->namespace '(file "test.rkt"))) > (eval 'jk (module->namespace '(file "test.rkt"))) 20 > (enter! "test.rkt") > j - : Number 10 > k - : Number 10 > jk stdin::214: Type Checker: untyped identifier jk in: jk > ``` So it seems a racket problem, similar perhaps to the one reported in issue jaor/geiser#18. I've sent an email to the racket mailing list trying to get some feedback.

jaor commented 2014年01月04日 02:30:53 +01:00 (Migrated from gitlab.com)

Created by: Fuuzetsu

I see. Are you going to close this as it is not a Geiser issue?

*Created by: Fuuzetsu* I see. Are you going to close this as it is not a Geiser issue?

jaor commented 2014年01月04日 02:42:46 +01:00 (Migrated from gitlab.com)

I see. Are you going to close this as it is not a Geiser issue?

i'll wait until we get some feedback from the racket guys. geiser uses
its own version of enter!, and avoids some of its problems (for
instance, in geiser you can use ,enter inside a typed module to go
back to another module), and perhaps i'll be able to tweak my
implementation to avoid this one too (although diving for a bit in typed
racket's implementation didn't give me much of a clue :)).

> I see. Are you going to close this as it is not a Geiser issue? i'll wait until we get some feedback from the racket guys. geiser uses its own version of `enter!`, and avoids some of its problems (for instance, in geiser you can use `,enter` inside a typed module to go back to another module), and perhaps i'll be able to tweak my implementation to avoid this one too (although diving for a bit in typed racket's implementation didn't give me much of a clue :)).

jaor commented 2014年01月09日 00:58:42 +01:00 (Migrated from gitlab.com)

Mateusz, i just got a hint from Sam in the mailing list and i think i've
fixed the problem with a patch i just pushed. At the very least, it
seems to be working for me! Let me know if it's also working for you.

Mateusz, i just got a hint from Sam in the mailing list and i think i've fixed the problem with a patch i just pushed. At the very least, it seems to be working for me! Let me know if it's also working for you.

jaor commented 2014年01月10日 09:47:43 +01:00 (Migrated from gitlab.com)

Created by: Fuuzetsu

It seems that the problem still persists without any change. Do I need a HEAD version of Racket? It sounded to me like you worked around the problem but I might have misinterpreted it.

Using geiser jaor/geiser@f9b2ed8607

*Created by: Fuuzetsu* It seems that the problem still persists without any change. Do I need a HEAD version of Racket? It sounded to me like you worked around the problem but I might have misinterpreted it. Using geiser jaor/geiser@f9b2ed86077a79718b083e49f752cf01457e1459

jaor commented 2014年01月10日 09:57:34 +01:00 (Migrated from gitlab.com)

Created by: Fuuzetsu

Actually, trying it again, it seems that my geiser is just completely broken now, C-c C-k in a file gives me

Compiling /tmp/foo.rkt ...
Error: struct:exn:fail:syntax
stdin::43: geiser-load: Invalid module path
 at: #("/tmp/foo.rkt" 1 5 (face flx-highlight-face))
 in: geiser-load

If I try to use C-u C-c C-z I get

racket@> ,enter #("/tmp/foo.rkt" 1 5 (face flx-highlight-face))
stdin::165: enter: Invalid module path
 at: #("/tmp/foo.rkt" 1 5 (face flx-highlight-face))
 in: enter
 context...:
 /home/shana/.emacs.d/site-lisp/geiser/scheme/racket/geiser/user.rkt:54:0: enter!
 /usr/lib/racket/collects/racket/private/misc.rkt:87:7

It seems that text properties aren't being stripped anymore.

I can ,enter manually but the same issue as reported persists.

*Created by: Fuuzetsu* Actually, trying it again, it seems that my geiser is just completely broken now, `C-c C-k` in a file gives me ``` Compiling /tmp/foo.rkt ... Error: struct:exn:fail:syntax stdin::43: geiser-load: Invalid module path at: #("/tmp/foo.rkt" 1 5 (face flx-highlight-face)) in: geiser-load ``` If I try to use `C-u C-c C-z` I get ``` racket@> ,enter #("/tmp/foo.rkt" 1 5 (face flx-highlight-face)) stdin::165: enter: Invalid module path at: #("/tmp/foo.rkt" 1 5 (face flx-highlight-face)) in: enter context...: /home/shana/.emacs.d/site-lisp/geiser/scheme/racket/geiser/user.rkt:54:0: enter! /usr/lib/racket/collects/racket/private/misc.rkt:87:7 ``` It seems that text properties aren't being stripped anymore. I can `,enter` manually but the same issue as reported persists.

jaor commented 2014年01月10日 14:17:02 +01:00 (Migrated from gitlab.com)

That's strange: i haven't changed anything related to text properties or
even the elisp side... it was a fix in the racket side, and should work
with vanilla 5.3.6. It does for me.

Does the same problem happen with jaor/geiser@826a054761? Could you try with a fresh
emacs -q?

That's strange: i haven't changed anything related to text properties or even the elisp side... it was a fix in the racket side, and should work with vanilla 5.3.6. It does for me. Does the same problem happen with jaor/geiser@826a054761d0f12f243883a001b2392279580a7f? Could you try with a fresh emacs -q?

jaor commented 2014年01月11日 00:23:42 +01:00 (Migrated from gitlab.com)

Created by: Fuuzetsu

Ah, I updated a bunch of other submodules in my ~/.emacs.d so it's probably one of my themes screwing up again. I ran with emacs -q and the problem is still there

racket@foo.rkt> y
stdin::413: Type Checker: untyped identifier y
 in: y
 context...:
 /usr/lib/racket/collects/typed-racket/utils/tc-utils.rkt:85:0: report-all-errors
 /usr/lib/racket/collects/typed-racket/typecheck/tc-toplevel.rkt:411:0: tc-toplevel-form
 temp53
 /usr/lib/racket/collects/typed-racket/typed-racket.rkt:62:4
 /usr/lib/racket/collects/racket/private/misc.rkt:96:20
racket@foo.rkt> 

racket-failure

*Created by: Fuuzetsu* Ah, I updated a bunch of other submodules in my ~/.emacs.d so it's probably one of my themes screwing up again. I ran with emacs -q and the problem is still there ``` racket@foo.rkt> y stdin::413: Type Checker: untyped identifier y in: y context...: /usr/lib/racket/collects/typed-racket/utils/tc-utils.rkt:85:0: report-all-errors /usr/lib/racket/collects/typed-racket/typecheck/tc-toplevel.rkt:411:0: tc-toplevel-form temp53 /usr/lib/racket/collects/typed-racket/typed-racket.rkt:62:4 /usr/lib/racket/collects/racket/private/misc.rkt:96:20 racket@foo.rkt> ``` 

jaor commented 2014年01月11日 00:46:07 +01:00 (Migrated from gitlab.com)

Could you please tell me again what steps are you following to get that
error? I repeat one and again those we have above in this thread, and
things work fine... are you doing exactly the same?

Could you please tell me again what steps are you following to get that error? I repeat one and again those we have above in this thread, and things work fine... are you doing exactly the same?

jaor commented 2014年01月11日 02:06:09 +01:00 (Migrated from gitlab.com)

Created by: Fuuzetsu

I'm doing the same thing as I did at my opening post. See screenshot for my exact setup. I run emacs -q, go to scratch to set up my paths (pictured), open /tmp/foo.rkt and write the definition for x, then run-racket, C-c C-k, C-u C-c C-z, try out x in the REPL and it works. I then append definition for y to /tmp/foo.rkt, C-x C-s, C-c C-k, C-u C-c C-z, try out y in the REPL and it fails.

Just to make 100% sure that I did not mis-understand you, I do not need to update my Racket installation in any way, right? As you mention few posts above, I can reproduce the problem in my terminal with the racket binary so I'd imagine that's inherently broken, unless you're working around that yourself.

emacs -q setup

*Created by: Fuuzetsu* I'm doing the same thing as I did at my opening post. See screenshot for my exact setup. I run `emacs -q`, go to scratch to set up my paths (pictured), open `/tmp/foo.rkt` and write the definition for `x`, then `run-racket`, `C-c C-k`, `C-u C-c C-z`, try out `x` in the REPL and it works. I then append definition for `y` to `/tmp/foo.rkt`, `C-x C-s`, `C-c C-k`, `C-u C-c C-z`, try out `y` in the REPL and it fails. Just to make 100% sure that I did not mis-understand you, I do _not_ need to update my Racket installation in any way, right? As you mention few posts above, I can reproduce the problem in my terminal with the `racket` binary so I'd imagine that's inherently broken, unless you're working around that yourself. 

jaor commented 2014年01月11日 02:35:06 +01:00 (Migrated from gitlab.com)

ah, i see now what we do differently. after modifying y, instead of C-c
C-k, i do C-c C-e at the end of the definition, and then C-c C-z to go
to the REPL, and y is defined just fine. it's the second C-c C-k that
seems to not work... i'll investigate, thanks for your patience!

we shouldn't need to modify racket in any way. and it's not really
racket who's broken, but my example: evaluations in a language such as
typed/racket cannot be performed with a call to eval like the one i
used, and that's by design: see
http://lists.racket-lang.org/users/archive/2014-January/060993.html for
the whole story.

---

as an aside (this is not causing the problem), your way of loading
geiser is not entirely correct if what you have in the geiser directory
is a direct checkout of the git repo and you didn't run any make
command. instead of modifying manually the load-path and (require 'geiser) you should use:

 (setq site-lisp-dir <as-in-your-screenshot>)
 (setq geiser-mode-elisp-dir <as-in-your-screenshot>)
 (load-file (expand-file-name "geiser.el" geiser-mode-elisp-dir))

as i said, i this won't make a difference in this case, but just to be
sure we're on the same page.

ah, i see now what we do differently. after modifying y, instead of C-c C-k, i do C-c C-e at the end of the definition, and then C-c C-z to go to the REPL, and y is defined just fine. it's the second C-c C-k that seems to not work... i'll investigate, thanks for your patience! we shouldn't need to modify racket in any way. and it's not really racket who's broken, but my example: evaluations in a language such as typed/racket cannot be performed with a call to `eval` like the one i used, and that's by design: see http://lists.racket-lang.org/users/archive/2014-January/060993.html for the whole story. --- as an aside (this is not causing the problem), your way of loading geiser is not entirely correct if what you have in the geiser directory is a direct checkout of the git repo and you didn't run any make command. instead of modifying manually the load-path and `(require 'geiser)` you should use: ``` elisp (setq site-lisp-dir <as-in-your-screenshot>) (setq geiser-mode-elisp-dir <as-in-your-screenshot>) (load-file (expand-file-name "geiser.el" geiser-mode-elisp-dir)) ``` as i said, i this won't make a difference in this case, but just to be sure we're on the same page.

jaor commented 2014年01月18日 05:18:56 +01:00 (Migrated from gitlab.com)

@Fuuzetsu i've just pushed a patch that seems to fix the remaining problems with C-c C-k... please let me know if it works for you when you have a chance. thanks!

@Fuuzetsu i've just pushed a patch that seems to fix the remaining problems with C-c C-k... please let me know if it works for you when you have a chance. thanks!

jaor commented 2017年02月10日 16:34:09 +01:00 (Migrated from gitlab.com)

Created by: fosskers

This (or something like it) may have risen from the grave. In exploring some typed Racket (and Geiser too, which is great), I've found that adding new definitions to a module isn't picked up properly somehow. For example:

#lang typed/racket
(: foo Integer)
(define foo 5)

^ this in my module followed by a fresh C-c C-a will make foo callable as expected in a Geiser repl. If I add another definition:

(: biff Integer)
(define biff 10)

and recompile, I'm given this:

racket@typed-racket.rkt> biff
stdin::1168: Type Checker: missing type for identifier; 
 consider adding a type annotation with `:'
 identifier: biff
 in: biff
 context...:
 /usr/share/racket/pkgs/typed-racket-lib/typed-racket/types/tc-error.rkt:30:0: tc-error/expr/fields16
 /usr/share/racket/collects/syntax/private/id-table.rkt:77:2: do-ref
 /usr/share/racket/pkgs/typed-racket-lib/typed-racket/env/global-env.rkt:64:0: lookup-type
 /usr/share/racket/collects/syntax/private/id-table.rkt:77:2: do-ref
 /usr/share/racket/pkgs/typed-racket-lib/typed-racket/typecheck/tc-expr-unit.rkt:42:0: tc-id
 temp101
 /usr/share/racket/pkgs/typed-racket-lib/typed-racket/typecheck/tc-expr-unit.rkt:326:0: tc-expr
 /usr/share/racket/pkgs/typed-racket-lib/typed-racket/typecheck/tc-toplevel.rkt:577:0: tc-toplevel-form
 temp19
 /usr/share/racket/collects/racket/private/misc.rkt:88:7

which is the same error that occurs if you try to call any other symbol that isn't defined. This occurs for both static values and functions, and the only way to get around it is to completely kill the Geiser REPL and reload it.

I'm on Racket 6.8, Emacs 25.1, and Geiser 0.9 (melpa-stable).

*Created by: fosskers* This (or something like it) may have risen from the grave. In exploring some typed Racket (and Geiser too, which is great), I've found that adding new definitions to a module isn't picked up properly somehow. For example: ```racket #lang typed/racket (: foo Integer) (define foo 5) ``` ^ this in my module followed by a fresh `C-c C-a` will make `foo` callable as expected in a Geiser repl. If I add another definition: ```racket (: biff Integer) (define biff 10) ``` and recompile, I'm given this: ``` racket@typed-racket.rkt> biff stdin::1168: Type Checker: missing type for identifier; consider adding a type annotation with `:' identifier: biff in: biff context...: /usr/share/racket/pkgs/typed-racket-lib/typed-racket/types/tc-error.rkt:30:0: tc-error/expr/fields16 /usr/share/racket/collects/syntax/private/id-table.rkt:77:2: do-ref /usr/share/racket/pkgs/typed-racket-lib/typed-racket/env/global-env.rkt:64:0: lookup-type /usr/share/racket/collects/syntax/private/id-table.rkt:77:2: do-ref /usr/share/racket/pkgs/typed-racket-lib/typed-racket/typecheck/tc-expr-unit.rkt:42:0: tc-id temp101 /usr/share/racket/pkgs/typed-racket-lib/typed-racket/typecheck/tc-expr-unit.rkt:326:0: tc-expr /usr/share/racket/pkgs/typed-racket-lib/typed-racket/typecheck/tc-toplevel.rkt:577:0: tc-toplevel-form temp19 /usr/share/racket/collects/racket/private/misc.rkt:88:7 ``` which is the same error that occurs if you try to call any other symbol that isn't defined. This occurs for both static values and functions, and the only way to get around it is to completely kill the Geiser REPL and reload it. I'm on Racket 6.8, Emacs 25.1, and Geiser 0.9 (melpa-stable).

jaor commented 2017年02月10日 18:45:39 +01:00 (Migrated from gitlab.com)

Created by: Fuuzetsu

I know I'm 3 years late but feel free to close the ticket without waiting for my confirmation... I won't be able to check any time soon.

*Created by: Fuuzetsu* I know I'm 3 years late but feel free to close the ticket without waiting for my confirmation... I won't be able to check any time soon.

jaor commented 2017年03月04日 00:29:23 +01:00 (Migrated from gitlab.com)

Created by: fosskers

Any word on this?

*Created by: fosskers* Any word on this?

jaor commented 2017年03月12日 00:12:55 +01:00 (Migrated from gitlab.com)

Created by: deep19

I'm facing the exact same issue. ,enter not reloading the file properly. Removing a definition from the file works and the definition is no longer in the namespace. But adding a new definition doesn't add it to the namespace after C-c C-a. C-c M-e is also working fine.

*Created by: deep19* I'm facing the exact same issue. ,enter not reloading the file properly. Removing a definition from the file works and the definition is no longer in the namespace. But adding a new definition doesn't add it to the namespace after C-c C-a. C-c M-e is also working fine.

jaor commented 2017年03月20日 04:22:26 +01:00 (Migrated from gitlab.com)

Created by: fosskers

The answer for me was to switch to racket-mode.

*Created by: fosskers* The answer for me was to switch to `racket-mode`.

jaor commented 2017年03月20日 17:27:43 +01:00 (Migrated from gitlab.com)

On Sun, Mar 19 2017, Colin Woodbury wrote:

The answer for me was to switch to racket-mode.

and, fwiw, i think it's a good answer. racket's internals are more
amenable to the "run every time" paradigm of racket-mode (and
dr. racket), and it's hard to keep racket working with geiser's model
when one leaves #lang racket.

(i am by now almost sure that it'd be better if we dropped racket
altogether from geiser, but i'm not sure how many racket geiserati are
out there and wouldn't want to leave them in cold either).

On Sun, Mar 19 2017, Colin Woodbury wrote: > The answer for me was to switch to racket-mode. and, fwiw, i think it's a good answer. racket's internals are more amenable to the "run every time" paradigm of racket-mode (and dr. racket), and it's hard to keep racket working with geiser's model when one leaves #lang racket. (i am by now almost sure that it'd be better if we dropped racket altogether from geiser, but i'm not sure how many racket geiserati are out there and wouldn't want to leave them in cold either).

jaor commented 2017年03月20日 18:31:51 +01:00 (Migrated from gitlab.com)

Created by: fosskers

A note on Geiser's website would be helpful. That's where I taught it to myself, and was happy about seeing the "Racket too!" messages everywhere.

*Created by: fosskers* A note on Geiser's website would be helpful. That's where I taught it to myself, and was happy about seeing the "Racket too!" messages everywhere.

jaor commented 2017年03月20日 19:03:46 +01:00 (Migrated from gitlab.com)

sorry, not sure i understand: a note on what exactly? typed racket not
being supported in geiser?

sorry, not sure i understand: a note on what exactly? typed racket not being supported in geiser?

jaor commented 2017年03月20日 19:16:33 +01:00 (Migrated from gitlab.com)

Created by: fosskers

Yes, forgive me, that's what I meant. i.e. "If you're using Typed Racket, please consider racket-mode instead."

*Created by: fosskers* Yes, forgive me, that's what I meant. i.e. "If you're using Typed Racket, please consider `racket-mode` instead."

jaor commented 2017年08月31日 02:04:38 +02:00 (Migrated from gitlab.com)

Created by: iitalics

FWIW, wrapping expressions to eval with #%top-interaction (e.g. (#%top-interaction . (define: jk : Number (+ j k)))) fixes this.

*Created by: iitalics* FWIW, wrapping expressions to `eval` with `#%top-interaction` (e.g. `(#%top-interaction . (define: jk : Number (+ j k)))`) fixes this.

jaor commented 2017年08月31日 02:56:21 +02:00 (Migrated from gitlab.com)

@iitalics sorry for being dense, but what do you mean exactly? the problem is when recompiling a file, adding new definitions and then evaluating them in the repl: at what stage are you wrapping?

@iitalics sorry for being dense, but what do you mean exactly? the problem is when recompiling a file, adding new definitions and then evaluating them in the repl: at what stage are you wrapping?

jaor commented 2017年08月31日 03:09:45 +02:00 (Migrated from gitlab.com)

Created by: iitalics

The expression passed to eval should be wrapped. In the Racket REPL (from the command line or racket-mode), expressions are implicitly wrapped with #%top-interaction which slightly alters some behavior, e.g. allows you to define something more than once (disallowed when loading entire modules, which are implicitly wrapped with #%module-begin).

It seems that the code example with js and ks doesn't actually type the identifier jk unless you use #%top-interaction, for whatever reason.

$ cat test.rkt
#lang typed/racket
(define: j : Number 10)
(define: k : Number 20)
$ racket
Welcome to Racket v6.10.
> (require "test.rkt")
> (eval '(#%top-interaction . (define: jk : Number (+ j k))) (module->namespace '(file "test.rkt")))
> (enter! "test.rkt")
"test.rkt"> jk
- : Number
30
"test.rkt"> ^D

*Created by: iitalics* The expression passed to `eval` should be wrapped. In the Racket REPL (from the command line or racket-mode), expressions are implicitly wrapped with `#%top-interaction` which slightly alters some behavior, e.g. allows you to `define` something more than once (disallowed when loading entire modules, which are implicitly wrapped with `#%module-begin`). It seems that the code example with `j`s and `k`s doesn't actually type the identifier `jk` unless you use `#%top-interaction`, for whatever reason. ```racket $ cat test.rkt #lang typed/racket (define: j : Number 10) (define: k : Number 20) $ racket Welcome to Racket v6.10. > (require "test.rkt") > (eval '(#%top-interaction . (define: jk : Number (+ j k))) (module->namespace '(file "test.rkt"))) > (enter! "test.rkt") "test.rkt"> jk - : Number 30 "test.rkt"> ^D ```

jaor commented 2017年08月31日 03:32:53 +02:00 (Migrated from gitlab.com)

@iitalics we are already using #%top-interaction when evaluating expressions in racket, and, as a matter of fact, your example works just fine in Geiser without having to add it explicitly (we do that under the covers). the problem is when we evaluate the full module in a single step (geiser is a bit atypical here, because it tries to allow re-definitions even of exported identifiers when re-requiring modules)... it's in those "wholesale" re-evaluations of full modules that we are encountering problems.

looking at it now, these re-evaluations amount to a dynamic-require of the module, not an explicit evaluation. something naive like wrapping the call to dynamic-require in a top-interaction eval is not working, but maybe something else along these lines is needed.

@iitalics we are already using `#%top-interaction` when evaluating expressions in racket, and, as a matter of fact, your example works just fine in Geiser without having to add it explicitly (we do that under the covers). the problem is when we evaluate the full module in a single step (geiser is a bit atypical here, because it tries to allow re-definitions even of exported identifiers when re-requiring modules)... it's in those "wholesale" re-evaluations of full modules that we are encountering problems. looking at it now, these re-evaluations amount to a dynamic-require of the module, not an explicit evaluation. something naive like wrapping the call to dynamic-require in a top-interaction eval is not working, but maybe something else along these lines is needed.

jaor commented 2020年07月20日 07:01:17 +02:00 (Migrated from gitlab.com)

changed the description

changed the description

jaor commented 2020年07月20日 07:01:19 +02:00 (Migrated from gitlab.com)

moved from jaor/geiser#24

moved from jaor/geiser#24