I think Jay is expressing an Eli-concern: we need to distribute the full source to determine whether something can be thrown away.
On Mar 12, 2012, at 3:13 PM, Robby Findler wrote: > Oh, I get it now. Thanks. > > This also seems like something that you'd want to put control over at > the package level, I guess. That is, a package can depend on another > package, but without that second package's test modules or something. > > Robby > > On Mon, Mar 12, 2012 at 2:05 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote: >> Yes: In other words, there could be a parameter that causes the macro >> expander to drop `test' submodules before it even attempts to expand >> them --- roughly like not using `-g' with `gcc'. >> >> Meanwhile, the after-the-fact pruning tool could be called `raco >> strip'. >> >> At Mon, 12 Mar 2012 15:02:58 -0400, Matthias Felleisen wrote: >>> >>> Or you make the pruning step a part of the compiler. >>> >>> >>> On Mar 12, 2012, at 3:01 PM, Robby Findler wrote: >>> >>>> Yes, I think the point that Jay's making is that the thing you'd >>>> distribute wouldn't be rkt code, but some low-level thing. Well, >>>> either that or you distribute .rkt code that doesn't actually run. >>>> >>>> Robby >>>> >>>> On Mon, Mar 12, 2012 at 1:59 PM, Matthias Felleisen >>>> <matth...@ccs.neu.edu> wrote: >>>>> >>>>> I know that. But we could consider the pruning step as part of >>>>> compilation. >>>>> >>>>> >>>>> On Mar 12, 2012, at 2:57 PM, Robby Findler wrote: >>>>> >>>>>> He's saying that there is no easy way to, without expanding the code >>>>>> (and perhaps without going one step further beyond a fully expanded >>>>>> program, but nevermind that detail), split apart the submodules that >>>>>> come from a single module. You just cannot tell, without expanding >>>>>> everything, which of the imports end up being used where (at least I >>>>>> think that's the idea). >>>>>> >>>>>> Robby >>>>>> >>>>>> On Mon, Mar 12, 2012 at 1:47 PM, Matthias Felleisen >>>>>> <matth...@ccs.neu.edu> wrote: >>>>>>> >>>>>>> Why does it not compile? Do you mean it doesn't compile to the same byte >>> codes? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mar 12, 2012, at 2:40 PM, Jay McCarthy wrote: >>>>>>> >>>>>>>> Sorry Matthias, I don't think I understand your question. >>>>>>>> >>>>>>>> At the bytecode level, it would be "easy", so we could change the >>>>>>>> distribution scripts to do that. >>>>>>>> >>>>>>>> At the source level, it's not really possible because of macros that >>>>>>>> generate code in a submodule. >>>>>>>> >>>>>>>> My personal taste is that it is bad to ship .rkt that doesn't compile, >>>>>>>> but I'd also like a future where we don't ship .rkt >>>>>>>> >>>>>>>> Jay >>>>>>>> >>>>>>>> On 3/12/12, Matthias Felleisen <matth...@ccs.neu.edu> wrote: >>>>>>>>> >>>>>>>>> On Mar 12, 2012, at 11:39 AM, Jay McCarthy wrote: >>>>>>>>> >>>>>>>>>> The current demodularizer would do that. Presumably we could make a >>>>>>>>>> tool that operated on a single module's zo and removed such >>>>>>>>>> submodules. The main problem would be that the source is >>>>>>>>>> un-compilable. >>>>>>>>> >>>>>>>>> >>>>>>>>> Meaning? Removing docs and tests shouldn't leave the functional part >>>>>>>>> in >>> bad >>>>>>>>> shape >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Jay >>>>>>>>>> >>>>>>>>>> On Mon, Mar 12, 2012 at 8:58 AM, Matthias Felleisen >>>>>>>>>> <matth...@ccs.neu.edu> wrote: >>>>>>>>>>> >>>>>>>>>>> Yes, dependencies abound if we include tests and doc in the same >>> module. >>>>>>>>>>> At the same time it is good practice to have things together. >>>>>>>>>>> >>>>>>>>>>> Can't this problem be solved with module-flattening tools? From >>>>>>>>>>> what I >>>>>>>>>>> can tell, these test and doc modules could be dropped leaving the >>> running >>>>>>>>>>> residual, which could be bundled. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Jay McCarthy <j...@cs.byu.edu> >>>>>>>>>> Assistant Professor / Brigham Young University >>>>>>>>>> http://faculty.cs.byu.edu/~jay >>>>>>>>>> >>>>>>>>>> "The glory of God is Intelligence" - D&C 93 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Jay McCarthy <j...@cs.byu.edu> >>>>>>>> Assistant Professor / Brigham Young University >>>>>>>> http://faculty.cs.byu.edu/~jay >>>>>>>> >>>>>>>> "The glory of God is Intelligence" - D&C 93 >>>>>>> >>>>>>> >>>>>>> _________________________ >>>>>>> Racket Developers list: >>>>>>> http://lists.racket-lang.org/dev >>>>> >>> >>> >>> _________________________ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev