Yesterday, Matthew Flatt wrote:
At Mon, 3 Jun 2013 10:36:51 -0400, Eli Barzilay wrote:
(BTW, a possible source of confusion: I'm assuming that
distribution must be done via archives and not via repository
specs, since there should be some way to put the compiled files in
there.
I don't
On Thursday, Matthew Flatt wrote:
You've sketched out the producer side, and I'm not sure of some
about some of those details. The consumer side seems even more
complex to me. It seems like the package system would have to keep
track of which subpackages are installed for a package,
At Mon, 3 Jun 2013 08:27:19 -0400, Eli Barzilay wrote:
On Thursday, Matthew Flatt wrote:
You've sketched out the producer side, and I'm not sure of some
about some of those details. The consumer side seems even more
complex to me. It seems like the package system would have to keep
50 minutes ago, Matthew Flatt wrote:
At Mon, 3 Jun 2013 08:27:19 -0400, Eli Barzilay wrote:
A very cheap way to do this is to use these sub-package
specifications only for creating packages for distribution. With
the obvious resulting package file names, this means that there is
no
At Mon, 3 Jun 2013 10:36:51 -0400, Eli Barzilay wrote:
(BTW, a possible source of confusion: I'm assuming that distribution
must be done via archives and not via repository specs, since there
should be some way to put the compiled files in there.
I don't think that's the right assumption. We
At Wed, 29 May 2013 15:51:30 -0400, Eli Barzilay wrote:
20 minutes ago, Matthew Flatt wrote:
[...package distribution kinds...]
Well, I agree with all these thoughts, but what's the conclusion?
There's no requirement that packages be in multiple repositories,
but different packages
On Thu, May 30, 2013 at 8:50 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
To summarize, I see our options as
1. Suspend the effort to reorganize our repository into packages and
instead start experimenting with subpackages.
2. Use a naming convention and keep the same kind of split as
At Thu, 30 May 2013 09:01:16 -0400, Sam Tobin-Hochstadt wrote:
I also really don't want to have Typed Racket's documentation outside
of Typed Racket's code repository, and I think it would be a mistake
to do that for other parts of Racket. An on-point comment on this
from just yesterday in a
On Thu, May 30, 2013 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Thu, 30 May 2013 09:01:16 -0400, Sam Tobin-Hochstadt wrote:
I also really don't want to have Typed Racket's documentation outside
of Typed Racket's code repository, and I think it would be a mistake
to do that for
At Thu, 30 May 2013 10:02:29 -0400, Sam Tobin-Hochstadt wrote:
One question, though: how does this work with the package manager.
Right now, only repositories can be specified as the source when
creating a package at pkg.racket-lang.org. There must be something
I'm missing about how this will
Matthew,
I have seen 'personal responsibility' mentioned only in passing.
Does existence of package imply any personal responsibilities?
The current organization doesn't seem to say so.
-- Matthias
_
Racket Developers list:
http://lists.racket-lang.org/dev
As I understand things, we should certainly try to align divisions of
responsibility with divisions of code (including tests and docs) among
packages.
My initial experiment probably doesn't align them very well, and I'd
expect a better alignment to emerge from everyone's efforts to improve
some
On 05/28/2013 03:44 PM, Sam Tobin-Hochstadt wrote:
On Tue, May 28, 2013 at 5:14 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
I don't know whether the -lib/-docs split is worthwhile, but it's
part of erring on the side of breaking things apart. Maybe it makes
more sense to keep things together
Yesterday, Matthew Flatt wrote:
Here's a first experiment at moving collections around into packages:
https://github.com/mflatt/racket/tree/pkg
[...]
Comments in no particular order, mostly about the actual file
selections. Many are kind of small todo-style laundry items, some are
At Wed, 29 May 2013 11:11:18 -0600, Neil Toronto wrote:
On 05/28/2013 03:44 PM, Sam Tobin-Hochstadt wrote:
On Tue, May 28, 2013 at 5:14 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
I don't know whether the -lib/-docs split is worthwhile, but it's
part of erring on the side of breaking
Yesterday, Sam Tobin-Hochstadt wrote:
One question -- a bunch of unstable seems to be in the
typed-racket-lib package. Why is that?
Since these things are used in TR only, I think that they should move
back. Ie, you get a trimmed TR repo with unstable/stuff which you
move to a better place
Yesterday, Robby Findler wrote:
This looks great to me!
I don't have a good sense of what level of granularity is the right
one, but I naturally would have gone even finer grained with
drracket: the macro-debugger, pkg/gui, and maybe even the
gui-debugger I would have separated out.
An hour ago, Neil Toronto wrote:
I expect `plot' to depend on `math' in the near-ish future. Right
now, `math' already depends on `plot' to build its docs. IOW, I
expect the sources to be interdependent, but as binaries, `plot'
will depend on `math' but `math' won't depend on `plot'. Can the
20 minutes ago, Matthew Flatt wrote:
Yes. Package dependencies can be cyclic (unlike module
dependencies), and packages can have cyclic build dependencies
without cyclic run dependencies.
(*sigh*) So the idea of acyclic package graph as module containers is
dead?
But to explain my sigh --
At Wed, 29 May 2013 14:14:11 -0400, Eli Barzilay wrote:
* Does this split actually work wrt having no circular dependencies?
It's mostly non-circular, but there are some exceptions.
I think there are no circularities among the -lib packages, but I'm
not 100% certain.
The existing -docs
Just to be clear, I agree that we want to minimize cycles.
I don't think that actually prohibiting cycles is going to be workable,
though, especially at the level of documentation.
Cycles at the level of -lib suggest to me that the organization
should be improved.
Cycles at the level of -doc
[shuffled]
20 minutes ago, Matthew Flatt wrote:
Just to be clear, I agree that we want to minimize cycles.
I don't think that actually prohibiting cycles is going to be workable,
though, especially at the level of documentation.
Cycles at the level of -lib suggest to me that the
On Tue, May 28, 2013 at 5:14 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
I don't know whether the -lib/-docs split is worthwhile, but it's
part of erring on the side of breaking things apart. Maybe it makes
more sense to keep things together and rely on binary packaging to
reduce
This looks great to me!
I don't have a good sense of what level of granularity is the right one,
but I naturally would have gone even finer grained with drracket: the
macro-debugger, pkg/gui, and maybe even the gui-debugger I would have
separated out. (Probably you were focused on lower-level
At Tue, 28 May 2013 17:44:08 -0400, Sam Tobin-Hochstadt wrote:
One question -- a bunch of unstable seems to be in the
typed-racket-lib package. Why is that?
Just a shortcut. Typed Racket seemed to be the only user of the
libraries in the repo, so I put the libraries there for now.
So, how
At Tue, 28 May 2013 19:36:14 -0500, Robby Findler wrote:
I don't have a good sense of what level of granularity is the right one,
but I naturally would have gone even finer grained with drracket: the
macro-debugger, pkg/gui, and maybe even the gui-debugger I would have
separated out. (Probably
On Tue, May 28, 2013 at 8:11 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Tue, 28 May 2013 19:36:14 -0500, Robby Findler wrote:
I don't have a good sense of what level of granularity is the right one,
but I naturally would have gone even finer grained with drracket: the
macro-debugger,
27 matches
Mail list logo
