Thank you, Matthew. The project itself is organized as a multi package, however there is no need to install it.
Debug/DigiGnome ; this subpackage is the base one of the other two. Debug/Kuzuhamon/ ; this one meets the second problem Debug/sakuyamon/ ; this one meets the first problem Debug/sakuyamon/digitama/dispatch.rkt ; it is the buggy source Debug/Kuzuhamon/digivice/land-bang.rkt ; it is the buggy source, the bug only occurs after building Debug/DigiGnome/makefile.rkt ; it builds the entire project with (compile-directory-zos) and info.rkt Debug/DigiGnome/digitama/digicore.rkt ; it is the entry module (but not the application launcher) of all Debug/DigiGnome/digitama/posix.rkt ; (module-prefab:cstruct/no-auto-update) is here. digitama means 'private', while digivice means 'bin'. to build the project, just `cd` into the target directory DigiGnome, sakuyamon, or Kuzuhamon, then run `../DigiGnome/makefile.rkt`. (module-prefab:cstruct/no-auto-update) defines a submodule which contains another submodule in it. The purpose is defining prefab structs based on c structs for both untyped and typed racket. Currently it is used in sakuyamon/digitama/posix.rkt to get the system stats. dispatch.rkt always stops the building process (and `racket`), makefile.rkt itself is all right with this minimal code base, actually it just fails following the other failures. weird. So... if there is something wrong with the compiler (makefile.rkt itself is also compiled)? without compiling, digivice/land-bang.rkt can load the games (with in Kuzuhamon/village/land-of-lisp) correctly. On Mon, Nov 30, 2015 at 8:54 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > My guess is that you're running into an incompatibility created by the > new macro system. Something like lifting code out of an expanded > `module` form and dropping it into a different one? A change related to > submodule expansion? Or something related to the top-level namespace? > It might be an unavoidable incompatibility, or it might be a bug. > > I'm unclear on what I'd need to do to replicate the problem, though. Is > there some code of yours that's available and that I could try to run? > > At Mon, 30 Nov 2015 06:53:28 +0800, WarGrey Gyoudmon Ju wrote: > > It is compiled by myself with no strange options. > > Rebuilding the project (without DrRacket) fails due to two strange > > behaviors. > > > > The first one is module-path-index-resolve: "self" index has no > resolution. > > It breaks lots of scripts, I cannot locate where it is exactly occurs. > > 1. errortrace says makefile.rkt:364:35: (namespace-mapped-symbols) > > this is my building facility written in untyped racket, the > stack > > point is parameterized with (variable-reference->namespace > > (#%variable-reference)). > > > > 2. errortrace says nothing, while `racket` puts > > module-path-index-resolve: "self" index has no resolution > > module path index: #<module-path-index:()> > > context...: > > /opt/PLTracket/collects/syntax/private/id-table.rkt:77:2: do-ref > > > > > > > /opt/PLTracket/share/pkgs/typed-racket-lib/typed-racket/rep/interning.rkt:22:13 > > : > > *Opaque > > (submod .../digitama/posix.rkt typed/ffi #%type-decl): [running body] > > > > > /opt/PLTracket/share/pkgs/typed-racket-lib/typed-racket/env/env-req.rkt:8:4: > > for-loop > > > > > /opt/PLTracket/share/pkgs/typed-racket-lib/typed-racket/tc-setup.rkt:82:0: > > tc-module/full > > > > > /opt/PLTracket/share/pkgs/typed-racket-lib/typed-racket/typed-racket.rkt:24:4 > > standard-module-name-resolver > > > > > /opt/PLTracket/share/pkgs/typed-racket-lib/typed-racket/tc-setup.rkt:82:0: > > tc-module/full > > > > > /opt/PLTracket/share/pkgs/typed-racket-lib/typed-racket/typed-racket.rkt:24:4 > > standard-module-name-resolver > > > > this is a normal module, only posix.rkt is written by me, > > but... `racket posix.rkt` is okay, in which case, ffi bindings are > written > > in the top level module, typed/ffi is its submodule, `racket` run the > > tests based on the typed one. DrRacket complains > > (current-load-relative-directory) > > is false. > > > > > > > > The second one is compiled/expanded code out of context; cannot find > > exports to restore imported renamings for module: ... > > It seems that (dynamic-require) does not work with the correct > > (current-directory) or (current-load-relative-directory). > > > > Thanks. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to racket-users+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
debug.tar.bz2
Description: BZip2 compressed data
