Re: [racket-dev] okay to require rackunit in modules required at startup?
On Jun 28, 2011, at 11:19 PM, Robby Findler wrote: Yes, please do separate the stepper tests out into another file. Got it, done. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] okay to require rackunit in modules required at startup?
I think Eli is saying that it would create a bad dependency where badness isn't something that is easy to say precisely what it is, but the rough idea is that there is a hierarchy of modules (ie a grouping of modules into levels of a tree) and dependencies should go one direction. Making drracket require rackunit would cross this hierarchy with a link in the wrong direction (I think). In general, we're not careful enough with the way we've organized the tree so things are a bit of a rat's nest. Part of the problem is that we don't have good tools to help us clean things up, but the larger problem is that we've just been growing for N years without spending much time cleaning up this particular aspect of things. Robby On Wed, Jun 29, 2011 at 2:18 PM, John Clements cleme...@brinckerhoff.org wrote: On Jun 28, 2011, at 10:52 PM, Eli Barzilay wrote: An hour and a half ago, John Clements wrote: In certain places, I know that we're trying to be careful to minimize 'require's that occur as part of DrRacket startup. Is 'rackunit' something we're trying to avoid? Specifically, I have old unit tests in collects/stepper/private/shared.rkt that I'd like to revive as rackunit tests. Adding this is a bad idea -- but size is not the problem -- the redundant dependency is. The word redundant suggests that it's already required... either you meant something like extraneous, or else I just plain misunderstood. Can you give me another sentence or two? John _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] okay to require rackunit in modules required at startup?
Four minutes ago, Robby Findler wrote: I think Eli is saying that it would create a bad dependency where Yes, the redundant was a bad translation of something like a dependency we don't really need. badness isn't something that is easy to say precisely what it is, but the rough idea is that there is a hierarchy of modules (ie a grouping of modules into levels of a tree) and dependencies should go one direction. Making drracket require rackunit would cross this hierarchy with a link in the wrong direction (I think). Well, I think that rackunit doesn't depend on drr[*] -- if that was the case then the dependency that John wanted to add would have made rackunit and drr interdependent, essentially making them part of a single package -- and that would be bad since they're conceptually not related. So it's really best to avoid any inter-package dependencies unless they make sense. [*] As an example, rackunit might become dependent on drr in the future, if it becomes a drr plugin. The cost of that is obvious: you need drr to use rackunit. A possible solution to that, if it becomes necessary, is to have another package for the plugin, one that depends on rackunit and drr. The fact that this is not easy to describe precisely is not new -- they're the same issues you face when you decide how to split your code into modules, except lifted up a level. And BTW, one thing that we agreed on is to forbid packages from having dependency cycles -- which will likely help package organization in a similar way it helps with modules. In general, we're not careful enough with the way we've organized the tree so things are a bit of a rat's nest. Part of the problem is that we don't have good tools to help us clean things up, but the larger problem is that we've just been growing for N years without spending much time cleaning up this particular aspect of things. ... and the fact that there is no organized package system to enforce tidiness. There's the distribution script, but that enforces very few boundaries, and they're at a very coarse level. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] okay to require rackunit in modules required at startup?
On Wed, Jun 29, 2011 at 8:10 AM, Robby Findler ro...@eecs.northwestern.edu wrote: On Wed, Jun 29, 2011 at 7:40 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Wed, Jun 29, 2011 at 2:52 AM, Eli Barzilay e...@barzilay.org wrote: [*] As an example, rackunit might become dependent on drr in the future, if it becomes a drr plugin. The cost of that is obvious: you need drr to use rackunit. A possible solution to that, if it becomes necessary, is to have another package for the plugin, one that depends on rackunit and drr. This is already the case for rackunit. There's a drracket tool for rackunit gui integration. I don't know the full story on the dependencies, but drracket plugins do not make direct links; they are discovered as drracket starts up and, if not present, nothing bad happens (unless two plugins need each other to be present, which is possible and happens in the current tree). Right, I was trying to say that Rackunit has already gone in the good direction that Eli pointed out wrt. DrRacket integration. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] okay to require rackunit in modules required at startup?
In certain places, I know that we're trying to be careful to minimize 'require's that occur as part of DrRacket startup. Is 'rackunit' something we're trying to avoid? Specifically, I have old unit tests in collects/stepper/private/shared.rkt that I'd like to revive as rackunit tests. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
