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. Becau
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 t
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 misunder
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
>
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 fil
[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
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 t
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"
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
>
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
On Thu, May 23, 2013 at 7:09 AM, Eli Barzilay wrote:
> Just now, Carl Eastlund wrote:
> > On Thu, May 23, 2013 at 6:57 AM, Eli Barzilay wrote:
> >
> > A few minutes ago, Carl Eastlund wrote:
> > >
> > > It doesn't seem wrong to me. It's an accurate representation
> > > of the hi
Just now, Carl Eastlund wrote:
> On Thu, May 23, 2013 at 6:57 AM, Eli Barzilay 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
> > for retai
On Thu, May 23, 2013 at 6:57 AM, Eli Barzilay wrote:
> A few minutes ago, Carl Eastlund wrote:
> > On Thu, May 23, 2013 at 5:49 AM, Eli Barzilay wrote:
> >
> > 9 hours ago, Carl Eastlund wrote:
> > > I was going to comment on the same thing. While a naive use
> > > of "git filter-br
A few minutes ago, Carl Eastlund wrote:
> On Thu, May 23, 2013 at 5:49 AM, Eli Barzilay 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
On Thu, May 23, 2013 at 5:49 AM, Eli Barzilay 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 and keep
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
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 n
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 w
On Wed, May 22, 2013 at 8:21 PM, 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
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'
Yesterday, Eric Dobson wrote:
> On Tue, May 21, 2013 at 4:29 AM, Jay McCarthy 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 to worry
> about
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 -- wi
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 th
[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 orga
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". W
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,
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
> refer
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
wrote:
On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote:
Eventua
On Tue, May 21, 2013 at 4:29 AM, Jay McCarthy wrote:
> On Mon, May 20, 2013 at 10:05 PM, Eric Dobson 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 pa
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 immedia
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 i
At Tue, 21 May 2013 00:09:49 -0700, Sam Tobin-Hochstadt wrote:
> On Mon, May 20, 2013 at 6:07 PM, Matthew Flatt 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
On Tue, May 21, 2013 at 6:22 AM, Jay McCarthy wrote:
> On Tue, May 21, 2013 at 12:16 AM, Antonio Menezes Leitao
> 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 difficu
On Mon, May 20, 2013 at 10:05 PM, Eric Dobson 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
> packages, but it
On Tue, May 21, 2013 at 12:16 AM, Antonio Menezes Leitao
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 good
> news.
>
> What happened
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
>> wrote:
>>
>> On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote:
>>>
Eventually, when the dust settle
On Mon, May 20, 2013 at 6:07 PM, Matthew Flatt 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 the switch fo
On Mon, May 20, 2013 at 2:23 PM, Jose A. Ortega Ruiz 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
will install
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.
_
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 side
On Mon, May 20, 2013 at 10:04 PM, Neil Van Dyke 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 identifier in my
> progra
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 anoth
On 05/20/13 23:24, Carl Eastlund wrote:
On Mon, May 20, 2013 at 4:58 PM, Asumu Takikawa 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 re
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
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
> ever
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 -- b
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 implica
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
On Mon, May 20, 2013 at 4:58 PM, Asumu Takikawa 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 submodules.
>
> One
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
notific
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 immediately. "Core" means enough to
run `raco pkg'
51 matches
Mail list logo
