[racket] Compiling A Collection - Module Resolving Blame

Yes, agreed. It isn't a good situation.

There are a lot of things resting on just one man's shoulders around here,
however, so if anyone has the energy to try to take this on and sort out
what's needed, that would be wonderful.

Robby


On Tue, May 28, 2013 at 12:24 PM, Ray Racine <ray.racine at gmail.com> wrote:

> 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 ...
>
> 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
>
> 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. :)
>
>
>
> On Tue, May 28, 2013 at 12:25 PM, Robby Findler <
> robby at eecs.northwestern.edu> wrote:
>
>> 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.
>>
>> 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.
>>
>> Robby
>>
>>
>>
>> On Tue, May 28, 2013 at 11:15 AM, Ray Racine <ray.racine at gmail.com>wrote:
>>
>>> I've created a mini-collection out on Github.
>>> https://github.com/RayRacine/tlib.git
>>>
>>> Consider the single collection, c1, with 4 modules.
>>>
>>> m1.rkt -> m1a.rkt -> m1aa.rkt
>>> m2.rkt
>>>
>>> Where m1 depends on m1a, m1a on m1aa and m2 had no dependencies.
>>>
>>> --> raco link /code/tlib/c1
>>> --> raco link -l
>>> User links:
>>>  collection: "c1"  path: "/code/tlib/c1"
>>> Installation links:
>>>
>>> --> raco setup c1
>>> <stuff>
>>>
>>> Completes without error.
>>>
>>> Now imagine one performs some amount of intra-collection module
>>> refactoring, module renamings, splitting and combing modules etc.
>>>
>>> We simulate this activity with a single modification to the require in
>>> m1.rkt to a now non-existent module.
>>>
>>> ;;Change
>>> (require
>>>  (only-in "m1a.rkt"
>>>        c1-m1a-v1))
>>>
>>> ;; to
>>>
>>> (require
>>>  (only-in "m1x.rkt"
>>>        c1-m1a-v1))
>>>
>>> Build the refactored collection.
>>>
>>> --> raco setup c1
>>> raco setup: version: 5.3.4.10 [3m]
>>> raco setup: variants: 3m
>>> raco setup: main collects: /usr/local/racket/collects
>>> raco setup: collects paths:
>>> raco setup:   /home/ray/.racket/5.3.4.10/collects
>>> raco setup:   /usr/local/racket/collects
>>> raco setup: --- pre-installing collections ---
>>> raco setup: --- installing foreign libraries ---
>>> raco setup: --- compiling collections ---
>>> raco setup: --- parallel build using 8 processes ---
>>> raco setup: 7 making: /code/tlib/c1
>>> default-load-handler: cannot open module file
>>>   module path: #<path:/code/tlib/c1/m1x.rkt>
>>>   path: /code/tlib/c1/m1x.rkt
>>>   system error: No such file or directory; errno=2
>>>   context...:
>>>    standard-module-name-resolver
>>>    /usr/local/racket/collects/racket/require-transform.rkt:266:2:
>>> expand-import
>>>    /usr/local/racket/collects/racket/private/reqprov.rkt:375:5
>>>    /usr/local/racket/collects/racket/require-transform.rkt:266:2:
>>> expand-import
>>>    try-next
>>>    /usr/local/racket/collects/racket/private/reqprov.rkt:242:2
>>>    success
>>>    /usr/local/racket/collects/typed-racket/typed-racket.rkt:53:4
>>>    /usr/local/racket/collects/compiler/cm.rkt:372:0: compile-zo*
>>>    /usr/local/racket/collects/compiler/cm.rkt:579:26
>>>    /usr/local/racket/collects/compiler/cm.rkt:572:42
>>>    /usr/local/racket/collects/compiler/cm.rkt:537:0: maybe-compile-zo
>>>    /usr/local/racket/collects/compiler/cm.rkt:650:2: do-check
>>>    /usr/local/racket/collects/compiler/cm.rkt:731:4
>>>    /usr/local/racket/collects/setup/parallel-do.rkt:420:20: loop
>>>
>>> raco setup: --- updating info-domain tables ---
>>> raco setup: --- creating launchers ---
>>> raco setup: --- installing man pages ---
>>> raco setup: --- building documentation ---
>>> raco setup: --- installing collections ---
>>> raco setup: --- post-installing collections ---
>>> raco setup:
>>> raco setup: error: during making for /code/tlib/c1
>>> raco setup:   default-load-handler: cannot open module file
>>> raco setup:     module path: #<path:/code/tlib/c1/m1x.rkt>
>>> raco setup:     path: /code/tlib/c1/m1x.rkt
>>> raco setup:     system error: No such file or directory; errno=2
>>> raco setup:     context...:
>>> raco setup:      standard-module-name-resolver
>>> raco setup:
>>> /usr/local/racket/collects/racket/require-transform.rkt:266:2: expand-import
>>> raco setup:
>>> /usr/local/racket/collects/racket/private/reqprov.rkt:375:5
>>> raco setup:
>>> /usr/local/racket/collects/racket/require-transform.rkt:266:2: expand-import
>>> raco setup:      try-next
>>> raco setup:
>>> /usr/local/racket/collects/racket/private/reqprov.rkt:242:2
>>> raco setup:      success
>>> raco setup:
>>> /usr/local/racket/collects/typed-racket/typed-racket.rkt:53:4
>>> raco setup:      /usr/local/racket/collects/compiler/cm.rkt:372:0:
>>> compile-zo*
>>> raco setup:      /usr/local/racket/collects/compiler/cm.rkt:579:26
>>> raco setup:      /usr/local/racket/collects/compiler/cm.rkt:572:42
>>> raco setup:      /usr/local/racket/collects/compiler/cm.rkt:537:0:
>>> maybe-compile-zo
>>> raco setup:      /usr/local/racket/collects/compiler/cm.rkt:650:2:
>>> do-check
>>> raco setup:      /usr/local/racket/collects/compiler/cm.rkt:731:4
>>> raco setup:
>>> /usr/local/racket/collects/setup/parallel-do.rkt:420:20: loop
>>> raco setup:
>>>
>>> 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.
>>>
>>> making: /code/tlib/c1
>>> default-load-handler: cannot open module file
>>>   module path: #<path:/code/tlib/c1/m1x.rkt>
>>>   path: /code/tlib/c1/m1x.rkt
>>>
>>> The critical information of whom to blame is missing.  In this case, the
>>> culprit is m1.rkt, line xxx with a bogus require.
>>>
>>> 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.
>>>
>>> Questions:
>>>
>>> 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?
>>>
>>> Or
>>>
>>> 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?
>>>
>>> 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.
>>>
>>>
>>> Thanks,
>>>
>>>
>>> Ray
>>>
>>> ____________________
>>>   Racket Users list:
>>>   http://lists.racket-lang.org/users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130528/e5de75c3/attachment-0001.html>