I agree with Robby. Jay
On Mon, Mar 12, 2012 at 1:18 PM, Robby Findler <ro...@eecs.northwestern.edu> wrote: > 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 -- 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
