On Friday, Matthew Flatt wrote:
At Fri, 24 May 2013 12:44:35 -0400, Eli Barzilay wrote:
* The script should also take care to deal with files that got
removed in the past.
Ditto.
I don't believe that it's *not* doing this, so I did the
double-check in the form of a test.
Now for the problems that are likely worth paying attention to, and
suggestions for improving things...
The quick summary of what I'm going to say is that I think that
there's a significant improvement that can be done with some more
work, one that requires some minimal manual intervention.
Yesterday, Robby Findler wrote:
Hi Eli: I'm trying to understand your point. Do I have this right?
Background: The git history consists of a series checkpoints in time
of the entire repository, not a collection of individual files.
Yes, although the difference between entire repository and
8 hours ago, Matthew Flatt wrote:
At Thu, 23 May 2013 07:09:17 -0400, Eli Barzilay wrote:
Relevant history is vague.
The history I want corresponds to `git log --follow' on each of the
files that end up in a repository.
(In this context this is clear; the problem in Carl's post is that it
[Note subject change...]
Two days ago, Eric Dobson wrote:
For binary vs source, I think you are providing a good argument for
the usefulness of a no source distribution. Some people want to use
tools written in Racket, and the fact that the tools are written in
Racket is immaterial to them.
At Fri, 24 May 2013 03:26:45 -0400, Eli Barzilay wrote:
If that can be done reliabely, then of course it makes it possible to
do the split reliabley after the first restructure.
Great! Let's do that, because I remain convinced that it's going to be
a lot easier.
* Also, I'd worry about file
Four hours ago, Matthew Flatt wrote:
At Fri, 24 May 2013 03:26:45 -0400, Eli Barzilay wrote:
If that can be done reliabely, then of course it makes it possible to
do the split reliabley after the first restructure.
Great! Let's do that, because I remain convinced that it's going to
be a
At Fri, 24 May 2013 12:44:35 -0400, Eli Barzilay wrote:
* The script should also take care to deal with files that got
removed in the past.
Ditto.
I don't believe that it's *not* doing this, so I did the double-check
in the form of a test.
You're right --- I misunderstood your
9 hours ago, Matthew Flatt wrote:
At Wed, 22 May 2013 14:50:41 -0400, Eli Barzilay wrote:
That's true, but the downside of changing the structure and having
files and directories move post structure change will completely
destroy the relevant edit history of the files, since it will not
9 hours ago, Carl Eastlund wrote:
I was going to comment on the same thing. While a naive use of git
filter-branch might not retain the history, it should be entirely
possible to do something a little more intelligent and keep that
history.
Just to be clear, this is exactly what you can't
On Thu, May 23, 2013 at 5:49 AM, Eli Barzilay e...@barzilay.org wrote:
9 hours ago, Carl Eastlund wrote:
I was going to comment on the same thing. While a naive use of git
filter-branch might not retain the history, it should be entirely
possible to do something a little more intelligent
A few minutes ago, Carl Eastlund wrote:
On Thu, May 23, 2013 at 5:49 AM, Eli Barzilay e...@barzilay.org wrote:
9 hours ago, Carl Eastlund wrote:
I was going to comment on the same thing. While a naive use
of git filter-branch might not retain the history, it should
be
On Thu, May 23, 2013 at 6:57 AM, Eli Barzilay e...@barzilay.org wrote:
A few minutes ago, Carl Eastlund wrote:
On Thu, May 23, 2013 at 5:49 AM, Eli Barzilay e...@barzilay.org wrote:
9 hours ago, Carl Eastlund wrote:
I was going to comment on the same thing. While a naive use
Just now, Carl Eastlund wrote:
On Thu, May 23, 2013 at 6:57 AM, Eli Barzilay e...@barzilay.org wrote:
A few minutes ago, Carl Eastlund wrote:
It doesn't seem wrong to me. It's an accurate representation
of the history of the project, which is exactly what git is
On Thu, May 23, 2013 at 7:09 AM, Eli Barzilay e...@barzilay.org wrote:
Just now, Carl Eastlund wrote:
On Thu, May 23, 2013 at 6:57 AM, Eli Barzilay e...@barzilay.org wrote:
A few minutes ago, Carl Eastlund wrote:
It doesn't seem wrong to me. It's an accurate
Hi Eli: I'm trying to understand your point. Do I have this right?
Background: The git history consists of a series checkpoints in time of the
entire repository, not a collection of individual files. So, when I do git
log x.rkt then what I get is essentially a filtered list (except where
people
At Thu, 23 May 2013 07:09:17 -0400, Eli Barzilay wrote:
Relevant history is vague.
The history I want corresponds to `git log --follow' on each of the
files that end up in a repository.
The thing that you can't do with
filter-branch is keep the complete history if you remove files from
the
Yesterday, Matthew Flatt wrote:
We already have a system for constructing a script that can move
files around and adjust content as needed: git.
The script that I'm talking about *would* be in the repository, of
course. It will essentially become a replacement for the distribution
specs --
Yesterday, Eric Dobson wrote:
On Tue, May 21, 2013 at 4:29 AM, Jay McCarthy jay.mccar...@gmail.com wrote:
In my tree, I have 20M of compiled code and 13M of source. I like
the idea of a reduction of about 50% in size of downloads.
I'm not sure if something on the order of 10M is something
At Wed, 22 May 2013 14:50:41 -0400, Eli Barzilay wrote:
That's true, but the downside of changing the structure and having
files and directories move post structure change will completely
destroy the relevant edit history of the files, since it will not be
carried over to the repos once it's
On Wed, May 22, 2013 at 8:21 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Wed, 22 May 2013 14:50:41 -0400, Eli Barzilay wrote:
That's true, but the downside of changing the structure and having
files and directories move post structure change will completely
destroy the relevant edit
I agree that 363 to 28 would be a great win. But you seem to be
describing the difference between Full Racket and core racket, not the
difference between binary and source.
For binary vs source, I think you are providing a good argument for
the usefulness of a no source distribution. Some people
I've been using using Racket (and DrRacket) to teach programming
to architecture students. These are not sophisticated users, so any
move that makes it more difficult for them to use Racket is not good
news.
What happened to the batteries included motto?
Just my 0.1 cents.
Best,
António.
On Mon, May 20, 2013 at 2:23 PM, Jose A. Ortega Ruiz j...@gnu.org wrote:
Here's hope that down the line there'll be binary+source packages that
end users can install with the same ease as today.
Matthew's email mentioned this a little, but the plan is that:
$ raco pkg install drracket
On Mon, May 20, 2013 at 6:07 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
To put it another way and overstate a little: I'm trying to get buy-in
from dev to make the switch to packages wholesale. The little bit of
staging in the plan is to make the conversion itself easier, and not to
simplify
On Mon, May 20, 2013 at 11:20 PM, Juan Francisco Cantero Hurtado
i...@juanfra.info wrote:
On 05/20/13 23:24, Carl Eastlund wrote:
On Mon, May 20, 2013 at 4:58 PM, Asumu Takikawa as...@ccs.neu.edu
wrote:
On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote:
Eventually, when the dust
On Tue, May 21, 2013 at 12:16 AM, Antonio Menezes Leitao
antonio.menezes.lei...@ist.utl.pt wrote:
I've been using using Racket (and DrRacket) to teach programming
to architecture students. These are not sophisticated users, so any
move that makes it more difficult for them to use Racket is not
On Mon, May 20, 2013 at 10:05 PM, Eric Dobson eric.n.dob...@gmail.com wrote:
I'm not sure I follow on why binary packages make it easier to reduce
dependencies between packages, or why binary packages offer faster
installs.
I'm guessing that binary packages prevent cyclic dependencies between
On Tue, May 21, 2013 at 6:22 AM, Jay McCarthy jay.mccar...@gmail.comwrote:
On Tue, May 21, 2013 at 12:16 AM, Antonio Menezes Leitao
antonio.menezes.lei...@ist.utl.pt wrote:
I've been using using Racket (and DrRacket) to teach programming
to architecture students. These are not sophisticated
At Tue, 21 May 2013 00:09:49 -0700, Sam Tobin-Hochstadt wrote:
On Mon, May 20, 2013 at 6:07 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
To put it another way and overstate a little: I'm trying to get buy-in
from dev to make the switch to packages wholesale. The little bit of
staging in
Jay McCarthy wrote:
If you have the source, then you need all the phase = 1 dependencies,
but if you just have the binary then you only need the phase = 0 deps.
That's assuming that you want to run the source, but I think that the
people who are arguing about still having the source available in
On 5/20/13 4:42 PM, Matthew Flatt wrote:
I used to think that we'd take advantage of the package manager by
gradually pulling parts out of the Racket git repo and making them
packages.
Now, I think we should just shift directly to a small-ish Racket core,
making everything else a package
On Tue, May 21, 2013 at 4:29 AM, Jay McCarthy jay.mccar...@gmail.com wrote:
On Mon, May 20, 2013 at 10:05 PM, Eric Dobson eric.n.dob...@gmail.com wrote:
I'm not sure I follow on why binary packages make it easier to reduce
dependencies between packages, or why binary packages offer faster
On 05/21/13 12:21, Carl Eastlund wrote:
On Mon, May 20, 2013 at 11:20 PM, Juan Francisco Cantero Hurtado
i...@juanfra.info wrote:
On 05/20/13 23:24, Carl Eastlund wrote:
On Mon, May 20, 2013 at 4:58 PM, Asumu Takikawa as...@ccs.neu.edu
wrote:
On 2013-05-20 14:42:15 -0600, Matthew Flatt
At Tue, 21 May 2013 10:46:29 -0400, David Van Horn wrote:
On 5/20/13 4:42 PM, Matthew Flatt wrote:
This plan has two prominent implications:
* The current git repo's directory structure will change.
Will this directory structure change have an impact on how modules are
referenced?
At Tue, 21 May 2013 05:29:19 -0600, Jay McCarthy wrote:
If you have the source, then you need all the phase = 1 dependencies,
but if you just have the binary then you only need the phase = 0 deps.
That's the right idea, but not precisely correct. If you `(require (for
syntax ...))' a module,
Yesterday, Matthew Flatt wrote:
Concretely, new repositories that are just a subset of the current
repo would be off-by-one in directory structure compared to a normal
package. Each package should correspond to a subtree starting from
the collects level, not the parent of collects. We could
[keeping the different subject since this is still about the repo.]
Yesterday, Asumu Takikawa wrote:
One nice thing about the current repo organization is that push
notifications for every part of the PLT codebase go to all of the
developers.
Will that still be available in this
We already have a system for constructing a script that can move files
around and adjust content as needed: git.
As long as some of us are trying to write that script while others are
changing the existing directories and files, there will be collisions.
We won't come up with a scripting system
On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote:
Eventually, when the dust settles, I think we'll want to convert every
directory to its own git repo, and then we can incorporate the
individual repos as git submodules.
One nice thing about the current repo organization is that push
On Mon, May 20, 2013 at 4:58 PM, Asumu Takikawa as...@ccs.neu.edu wrote:
On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote:
Eventually, when the dust settles, I think we'll want to convert every
directory to its own git repo, and then we can incorporate the
individual repos as git
On Mon, May 20 2013, Matthew Flatt wrote:
[...]
Some drawbacks to omitting source are immediately apparent:
- Users will be less able to make source changes on their systems to
help us debug.
Having the binary form of a package installed does not preclude
upgrading to a source
An hour and a half ago, Matthew Flatt wrote:
I used to think that we'd take advantage of the package manager by
gradually pulling parts out of the Racket git repo and making them
packages.
(Generally, +1. I'll reply just on the repository point here.)
This plan has two prominent
Well, ideally there would be some new module-name-source function
that could return URIs like http://path/to/file.rkt (or for that
matter, file:///path/to/file.rkt), based on info.rkt for packages?
Given that piece, a couple ways to do it -- favoring doing it more in
Emacs vs. more in Racket --
At Mon, 20 May 2013 18:27:34 -0400, Eli Barzilay wrote:
An hour and a half ago, Matthew Flatt wrote:
This plan has two prominent implications:
* The current git repo's directory structure will change. [...]
I very strongly object to this. While in theory git will follow
everything,
I'm calling for making Racket and package source transparently
accessible, even though not actually bundled into distribution downloads...
Racket has a research and education bent, and also attracts some of the
more sophisticated developers. For all of these audiences, there's a
tradition of
On 05/20/13 23:24, Carl Eastlund wrote:
On Mon, May 20, 2013 at 4:58 PM, Asumu Takikawa as...@ccs.neu.edu wrote:
On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote:
Eventually, when the dust settles, I think we'll want to convert every
directory to its own git repo, and then we can incorporate
Juan Francisco Cantero Hurtado wrote at 05/20/2013 11:20 PM:
I also think that git submodules are a bad idea for packages. One git
repo per package is more simple and less problematic.
Do people expect to often do commits involving changes across these
package boundaries? If so, would
On Mon, May 20, 2013 at 10:04 PM, Neil Van Dyke n...@neilvandyke.org wrote:
[snip]
Example: Imagine I'm in the middle of writing a Racket program and am
wondering about characteristics of some kind of I/O port in Racket. With
transparent source accessibility, I can just click on an
I'm not sure I follow on why binary packages make it easier to reduce
dependencies between packages, or why binary packages offer faster
installs.
I'm guessing that binary packages prevent cyclic dependencies between
packages, but it seems like there are many other options that still
get this
50 matches
Mail list logo
