<div dir="ltr"><div>To emphasis some real world feed back, where there are several people developing across several sizable layered collections say C4 depends on C3, depends on modules from C2 and C1, it is hard to say with a straight face, "Ok folks, Mary refactored a bunch of the C1 modules last week, now I need each of you to load up each individual source file one-by-one in DrDr from C1, C2, C3 and C4 and hit "Check Syntax". OK, I exaggerate but ...<br>
<br></div><div>Or another view, its hard to debate a co-developer who says, "you know in Java the compiler tells me where the error is." But I know you guys, know this. :0<br><br></div><div>I'm just sequencing through the stuff I hit this weekend on the trail to publishing a package. Wait till I get to scribble @example and attempting to put together a sandbox-evaluator. :)<br>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 28, 2013 at 12:25 PM, Robby Findler <span dir="ltr"><<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">IIUC, the problem is that the source location information (for the require) is no longer present when the filesystem access happens that turns into the error.<div>
<br></div><div>It is not those particular multiple parts of the system (raco, cm, tr) but I think it is a non-trivial change, all inside the core. Also, IIUC, the change leaks out and requires a change to publicly visible parts of the infrastructure (the module name resolver). I'm not sure about that, but I think that's also an obstacle.</div>
<div><br></div><div>Robby</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Tue, May 28, 2013 at 11:15 AM, Ray Racine <span dir="ltr"><<a href="mailto:ray.racine@gmail.com" target="_blank">ray.racine@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div><div><div><div><div><div>I've created a mini-collection out on Github. <a href="https://github.com/RayRacine/tlib.git" target="_blank">https://github.com/RayRacine/tlib.git</a><br>
<br></div>Consider the single collection, c1, with 4 modules.<br>
<br></div>m1.rkt -> m1a.rkt -> m1aa.rkt<br></div>m2.rkt <br><br></div>Where m1 depends on m1a, m1a on m1aa and m2 had no dependencies.<br><br></div>--> raco link /code/tlib/c1<br>--> raco link -l<br>User links:<br>
collection: "c1" path: "/code/tlib/c1"<br>Installation links:<br><br></div><div>--> raco setup c1<br></div><div><stuff><br><br></div><div>Completes without error.<br><br>Now imagine one performs some amount of intra-collection module refactoring, module renamings, splitting and combing modules etc.<br>
<br></div><div>We simulate this activity with a single modification to the require in m1.rkt to a now non-existent module.<br><br>;;Change<br>(require <br> (only-in "m1a.rkt"<br> c1-m1a-v1))<br></div><div>
<br>;; to<br><br>(require <br> (only-in "m1x.rkt"<br> c1-m1a-v1))<br><br></div><div>Build the refactored collection.<br><br>--> raco setup c1<br>raco setup: version: 5.3.4.10 [3m]<br>raco setup: variants: 3m<br>
raco setup: main collects: /usr/local/racket/collects<br>raco setup: collects paths: <br>raco setup: /home/ray/.racket/<a href="http://5.3.4.10/collects" target="_blank">5.3.4.10/collects</a><br>raco setup: /usr/local/racket/collects<br>
raco setup: --- pre-installing collections ---<br>raco setup: --- installing foreign libraries ---<br>raco setup: --- compiling collections ---<br>raco setup: --- parallel build using 8 processes ---<br>raco setup: 7 making: /code/tlib/c1<br>
default-load-handler: cannot open module file<br> module path: #<path:/code/tlib/c1/m1x.rkt><br> path: /code/tlib/c1/m1x.rkt<br> system error: No such file or directory; errno=2<br> context...:<br> standard-module-name-resolver<br>
/usr/local/racket/collects/racket/require-transform.rkt:266:2: expand-import<br> /usr/local/racket/collects/racket/private/reqprov.rkt:375:5<br> /usr/local/racket/collects/racket/require-transform.rkt:266:2: expand-import<br>
try-next<br> /usr/local/racket/collects/racket/private/reqprov.rkt:242:2<br> success<br> /usr/local/racket/collects/typed-racket/typed-racket.rkt:53:4<br> /usr/local/racket/collects/compiler/cm.rkt:372:0: compile-zo*<br>
/usr/local/racket/collects/compiler/cm.rkt:579:26<br> /usr/local/racket/collects/compiler/cm.rkt:572:42<br> /usr/local/racket/collects/compiler/cm.rkt:537:0: maybe-compile-zo<br> /usr/local/racket/collects/compiler/cm.rkt:650:2: do-check<br>
/usr/local/racket/collects/compiler/cm.rkt:731:4<br> /usr/local/racket/collects/setup/parallel-do.rkt:420:20: loop<br><br>raco setup: --- updating info-domain tables ---<br>raco setup: --- creating launchers ---<br>
raco setup: --- installing man pages ---<br>
raco setup: --- building documentation ---<br>raco setup: --- installing collections ---<br>raco setup: --- post-installing collections ---<br>raco setup: <br>raco setup: error: during making for /code/tlib/c1<br>raco setup: default-load-handler: cannot open module file<br>
raco setup: module path: #<path:/code/tlib/c1/m1x.rkt><br>raco setup: path: /code/tlib/c1/m1x.rkt<br>raco setup: system error: No such file or directory; errno=2<br>raco setup: context...:<br>raco setup: standard-module-name-resolver<br>
raco setup: /usr/local/racket/collects/racket/require-transform.rkt:266:2: expand-import<br>raco setup: /usr/local/racket/collects/racket/private/reqprov.rkt:375:5<br>raco setup: /usr/local/racket/collects/racket/require-transform.rkt:266:2: expand-import<br>
raco setup: try-next<br>raco setup: /usr/local/racket/collects/racket/private/reqprov.rkt:242:2<br>raco setup: success<br>raco setup: /usr/local/racket/collects/typed-racket/typed-racket.rkt:53:4<br>raco setup: /usr/local/racket/collects/compiler/cm.rkt:372:0: compile-zo*<br>
raco setup: /usr/local/racket/collects/compiler/cm.rkt:579:26<br>raco setup: /usr/local/racket/collects/compiler/cm.rkt:572:42<br>raco setup: /usr/local/racket/collects/compiler/cm.rkt:537:0: maybe-compile-zo<br>
raco setup: /usr/local/racket/collects/compiler/cm.rkt:650:2: do-check<br>raco setup: /usr/local/racket/collects/compiler/cm.rkt:731:4<br>raco setup: /usr/local/racket/collects/setup/parallel-do.rkt:420:20: loop<br>
raco setup:<br><br>Assuming co-occurrence of output happens across an N processor raco build, we know that during the making of collection c1, module m1x was not found.<br><br>making: /code/tlib/c1<br>default-load-handler: cannot open module file<br>
module path: #<path:/code/tlib/c1/m1x.rkt><br> path: /code/tlib/c1/m1x.rkt<br><br></div>The critical information of whom to blame is missing. In this case, the culprit is m1.rkt, line xxx with a bogus require.<br>
<br></div>With a collection of a hundred module files or so, combined with multiple issues from the refactoring, one is in for an afternoon of recursive grepping etc.<br><div><div><div><br></div><div>Questions:<br><br></div>
<div>1) Is this currently a "deep" issue, in the sense of how module resolving and instantiation is performed, layered with Typed Racket's mode of implementation, layered with CM and Raco's build system that prevents a more informative error message?<br>
<br></div><div>Or<br></div><div><br></div><div>2) Is this just a simple a bug, in the sense of oops, just forgot to print the error message concerning the offending source module and line?<br><br></div><div>If its 2) I'll work on debugging for a fix. If 1) I'm just not going to be able to tunnel through raco -> cm -> tr -> module expansion to run this down, so I'll punt.<br>
<br><br></div><div>Thanks,<br><br><br></div><div>Ray<br></div></div></div></div>
<br></div></div>____________________<br>
Racket Users list:<br>
<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>