[racket-dev] We just had our first totally clean build in DrDr in a long time

2012-12-08 Thread Jay McCarthy
We should get one of those signs like in factories: X days accident free.

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] We just had our first totally clean build in DrDr in a long time

2012-12-08 Thread Matthias Felleisen

You could make a Super 8 film then. 


On Dec 8, 2012, at 3:45 PM, Jay McCarthy wrote:

 We should get one of those signs like in factories: X days accident free.
 
 -- 
 Jay McCarthy j...@cs.byu.edu
 Assistant Professor / Brigham Young University
 http://faculty.cs.byu.edu/~jay
 
 The glory of God is Intelligence - DC 93
 _
  Racket Developers list:
  http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] We just had our first totally clean build in DrDr in a long time

2012-12-08 Thread Robby Findler
Cool!

Robby

On Sat, Dec 8, 2012 at 2:45 PM, Jay McCarthy jay.mccar...@gmail.com wrote:
 We should get one of those signs like in factories: X days accident free.

 --
 Jay McCarthy j...@cs.byu.edu
 Assistant Professor / Brigham Young University
 http://faculty.cs.byu.edu/~jay

 The glory of God is Intelligence - DC 93

 _
   Racket Developers list:
   http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] We just had our first totally clean build in DrDr in a long time

2012-12-08 Thread Neil Toronto

Is a clean build an accident? If so, we've gone back down to 0.

On 12/08/2012 01:45 PM, Jay McCarthy wrote:

We should get one of those signs like in factories: X days accident free.

--
Jay McCarthy j...@cs.byu.edu mailto:j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93


_
   Racket Developers list:
   http://lists.racket-lang.org/dev



_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Planet 2 Beta Release

2012-12-08 Thread Eli Barzilay
On Wednesday, Sam Tobin-Hochstadt wrote:
 
 Given that context, maybe the right thing here is (a) installation-
 specific packages by default and (b) a way to *upgrade* an existing
 installation when installing.  That might be as simple as
 automatically running 'raco pkg migrate', but I think making it part
 of the installation step would make life easier for people, and
 perhaps an upgrade could avoid duplicating files.

I think that this is exactly what Matthew was talking about.  One
tricky bit here is to know which packages were installed for which
level.  If *you* installed some packages, then the next time you *run*
(not install) an updated racket version you'd be asked if you want to
do the migration.  But if some package was installed as part of the
racket tree (not user specific) then the same question would apply
when a new version gets installed.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Planet 2 Beta Release

2012-12-08 Thread Sam Tobin-Hochstadt
On Dec 8, 2012 10:14 PM, Eli Barzilay e...@barzilay.org wrote:

 On Wednesday, Sam Tobin-Hochstadt wrote:
 
  Given that context, maybe the right thing here is (a) installation-
  specific packages by default and (b) a way to *upgrade* an existing
  installation when installing.  That might be as simple as
  automatically running 'raco pkg migrate', but I think making it part
  of the installation step would make life easier for people, and
  perhaps an upgrade could avoid duplicating files.

 I think that this is exactly what Matthew was talking about.  One
 tricky bit here is to know which packages were installed for which
 level.  If *you* installed some packages, then the next time you *run*
 (not install) an updated racket version you'd be asked if you want to
 do the migration.  But if some package was installed as part of the
 racket tree (not user specific) then the same question would apply
 when a new version gets installed.

Why would this wait for the first run for any packages?

One other thing that I think is important in a migration path is keeping
any modification made to the source of the packages that are already
installed.

Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Planet 2 Beta Release

2012-12-08 Thread Eli Barzilay
Just now, Sam Tobin-Hochstadt wrote:
 On Dec 8, 2012 10:14 PM, Eli Barzilay e...@barzilay.org wrote:
 
  I think that this is exactly what Matthew was talking about.  One
  tricky bit here is to know which packages were installed for which
  level.  If *you* installed some packages, then the next time you
  *run* (not install) an updated racket version you'd be asked if
  you want to do the migration.  But if some package was installed
  as part of the racket tree (not user specific) then the same
  question would apply when a new version gets installed.
 
 Why would this wait for the first run for any packages?

As usual, think about a lab with a central sysadmin-made racket
installation.  It's impossible to crawl over all users and change
stuff in their home directory when the sysadmin upgrades the
installation.

Now carry this over to OSX and Windows, and it's the same thing.  (And
even Windows is moving toward a more strict separation between the
administrator and plain users.)  The thing that makes it somewhat
easier there is that the interaction tends to be a single user that
plays both roles.  So either the user installed some packages for
everyone and the upgrade will update those at installation time, or
the user installed things for himself, and the upgrade will happen
when the new version runs -- usually just after the new installation.


 One other thing that I think is important in a migration path is
 keeping any modification made to the source of the packages that are
 already installed.

Yeah -- and IIUC, the difference between the two installations is
where the packages get installed is where the compiled files are, so
the sources are the same.  At least I *hope* that that's how it is,
otherwise it's back to the whole planet cache things, which IMO was
a major mistake.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Planet 2 Beta Release

2012-12-08 Thread Jay McCarthy
On Sat, Dec 8, 2012 at 8:29 PM, Eli Barzilay e...@barzilay.org wrote:

  One other thing that I think is important in a migration path is
  keeping any modification made to the source of the packages that are
  already installed.

 Yeah -- and IIUC, the difference between the two installations is
 where the packages get installed is where the compiled files are, so
 the sources are the same.  At least I *hope* that that's how it is,
 otherwise it's back to the whole planet cache things, which IMO was
 a major mistake.


They are in the same place. However, I thought the whole premise of this
proposed behavior is that the package won't work in the new version of
Racket, so certainly the package system can't be responsible for doing a
merge your local changes and whatever the updated version of the package
needs.

Jay

-- 
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

The glory of God is Intelligence - DC 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Planet 2 Beta Release

2012-12-08 Thread Eli Barzilay
30 minutes ago, Jay McCarthy wrote:
 On Sat, Dec 8, 2012 at 8:29 PM, Eli Barzilay e...@barzilay.org wrote:
 
  One other thing that I think is important in a migration path is
  keeping any modification made to the source of the packages that are
  already installed.

 Yeah -- and IIUC, the difference between the two installations is
 where the packages get installed is where the compiled files are, so
 the sources are the same.  At least I *hope* that that's how it is,
 otherwise it's back to the whole planet cache things, which IMO was
 a major mistake.
 
 They are in the same place. However, I thought the whole premise of
 this proposed behavior is that the package won't work in the new
 version of Racket, so certainly the package system can't be
 responsible for doing a merge your local changes and whatever the
 updated version of the package needs.

I'm not following that -- the compiled files and the sources are in
the same place?  If so then it makes the whole migration thing kind of
impossible with local changes, no?  (And I wasn't thinking about
merging, just reusing the same sources.)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!

_
  Racket Developers list:
  http://lists.racket-lang.org/dev