I thought Matthew was pointing out how we can distribute some source that works if you set a parameter properly and that same source will contain no test-based dependencies.
Boy, this conversation sure makes me wish for the ability to just gather everyone up around a whiteboard or something :( Robby On Mon, Mar 12, 2012 at 2:15 PM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > 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
