Idea: Let call-method generate a runtime error when run in DrRacket about whalesong HOT 8 CLOSED

Bug. Whenever link: module mismatches happen, that's a bug. It should have been a runtime error.

Does it still happen if you redo a 'raco make' on the whalesong source files?

from whalesong.

I tried the following:

• looked for Whalesong folders in the PLaneT cache
  (there were none due to the development link)
• changed folder to Whalesong source folder
• deleted all contents from compiled folders
  rm -rf compiled/
  rm -rf * / compiled/
  rm -rf * / * / compiled/
  etc
  • ran the setup Whalesong script in stxmat-excises:
    sh scripts/setup-whalesong.sh
    raco setup -P dyoo whalesong.plt 2 1
  • ran stxmat-exercises.rkt in DrRacket and got the error again
    Note that running the Whalesong compiler on the same file works fine.

So although a "link: module mismatch ..." error normally means old
bytecode is lying around, I am a bit suspicious of the macro
declare-implementation which is used to export call-method in js/main.rkt.

Note:
My source files starts as follows:

#lang at-exp planet dyoo/whalesong
(require (planet dyoo/whalesong/js))
... source that contains call-method ...

Now, if I change this to

#lang at-exp planet dyoo/whalesong
(require (planet dyoo/whalesong/js/racket-impl))

then the program runs as expected in DrRacket.
This suggests that declare-implemenation could be the culprit.

from whalesong.

I will look at this. The thing is that I can't reproduce the error: when I try using call-method in DrRacket, it errors out predictably with the intended runtime error, rather than the weird "link: module mismatch" business. I'll check out your project and try duplicating the error from there.

from whalesong.

This program generates the error for me.

#lang at-exp planet dyoo/whalesong
(require (planet dyoo/whalesong/js))
(call-method "foo")

The error message:
link: module mismatch, probably from old bytecode whose dependencies have changed: variable not provided (directly or indirectly) from module: "/Users/soegaard/Dropbox/GitHub/stxmat-exercises/whalesong/current/js/main.rkt" accessed from module: 'anonymous-module at source phase level: 0 in: call-method

The output from "planet show" is:

Normally-installed packages:
dyoo closure-compile.plt 1 2
dyoo version-case.plt 1 9

Development links:
dyoo whalesong.plt 2 1
--> /Users/soegaard/Dropbox/GitHub/stxmat-exercises/whalesong/current

from whalesong.

On Thu, Aug 25, 2011 at 3:34 PM, soegaard
[email protected]
wrote:

This program generates the error for me.

#lang at-exp planet dyoo/whalesong
(require (planet dyoo/whalesong/js))
(call-method "foo")

Something strange must be happening at the development link level,
then. Either that or the version of Whalesong on github now is not
what you've got.

When I try to replicate the bug, I do get the right error message:

fermi ~ $ cat foo.rkt
cat foo.rkt
#lang at-exp planet dyoo/whalesong
(require (planet dyoo/whalesong/js))
(call-method "foo")

fermi ~ $ racket foo.rkt
racket foo.rkt
procedure call-method: expects at least 2 arguments, given 1: "foo"

=== context ===
/gpfs/main/home/dyoo/foo.rkt: [running body]

fermi ~ $ planet show
planet show
Normally-installed packages:
dyoo browser-evaluate.plt 1 0
dyoo closure-compile.plt 1 2
dyoo version-case.plt 1 9

Development links:
dyoo whalesong.plt 1 3
--> /gpfs/main/home/dyoo/work/whalesong

from whalesong.

A new piece to the puzzle.
I can now turn the error on and off!

• In DrRacket choose the menu "Language" and the menu item "Choose Language".
• Click the button "Show Details"
• Toggle the setting "Populate 'compiled' directories (for faster loading)

If the setting is on, I get the error.
If the setting is off, I don't get the error.

from whalesong.

On Thu, Aug 25, 2011 at 5:04 PM, soegaard
[email protected]
wrote:

A new piece to the puzzle.
I can now turn the error on and off!

• In DrRacket choose the menu "Language" and the menu item "Choose Language".
• Click the button "Show Details"
• Toggle the setting "Populate 'compiled' directories (for faster loading)

If the setting is on, I get the error.
If the setting is off, I don't get the error.

Ah. Ok. Try leaving "populate compiled directories" on, but turn off
debugging support. I suspect that what is happening now is DrRacket's,
which itself does some funky stuff with bytecode loading.

from whalesong.

With "Populate" and no debug, the program works as intended.

from whalesong.