[racket-dev] Why did DrDr get much slower?

2013-07-13 Thread Sam Tobin-Hochstadt
The DrDr running time tripled recently. This doesn't seem to be a
result of any one thing getting slower, but instead of all the files
taking longer.  To pick two random examples,
`racket/lib/collects/racket/match/parse-quasi.rkt` went from ~1 second
to ~4 seconds, and `pkgs/realm/chapter2/source.rkt` went from ~1.5
seconds to ~3 seconds. You can see the charts here:


http://drdr.racket-lang.org/27103/racket/lib/collects/racket/match/parse-quasi.rkt
http://drdr.racket-lang.org/27103/pkgs/realm/chapter2/source.rkt

The change where this happened was Matthew's addition of
`filesystem-change-evt`, which was intended to make things faster.

This slowdown seems to be real on my machine as well --
realm/chapter2/source.rkt runs more than twice as slow in rev bd09a60e
as it does in v5.3.5. I'm testing the revision right before
`filesystem-change-evt` now.

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


Re: [racket-dev] Why did DrDr get much slower?

2013-07-13 Thread Robby Findler
Just as an aside, drdr rules.

Robby


On Sat, Jul 13, 2013 at 9:44 AM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote:

 The DrDr running time tripled recently. This doesn't seem to be a
 result of any one thing getting slower, but instead of all the files
 taking longer.  To pick two random examples,
 `racket/lib/collects/racket/match/parse-quasi.rkt` went from ~1 second
 to ~4 seconds, and `pkgs/realm/chapter2/source.rkt` went from ~1.5
 seconds to ~3 seconds. You can see the charts here:


 http://drdr.racket-lang.org/27103/racket/lib/collects/racket/match/parse-quasi.rkt
 http://drdr.racket-lang.org/27103/pkgs/realm/chapter2/source.rkt

 The change where this happened was Matthew's addition of
 `filesystem-change-evt`, which was intended to make things faster.

 This slowdown seems to be real on my machine as well --
 realm/chapter2/source.rkt runs more than twice as slow in rev bd09a60e
 as it does in v5.3.5. I'm testing the revision right before
 `filesystem-change-evt` now.

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

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


Re: [racket-dev] Why did DrDr get much slower?

2013-07-13 Thread Sam Tobin-Hochstadt
Indeed -- I'd have had no idea this happened at all.

On Sat, Jul 13, 2013 at 10:53 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 Just as an aside, drdr rules.

 Robby


 On Sat, Jul 13, 2013 at 9:44 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
 wrote:

 The DrDr running time tripled recently. This doesn't seem to be a
 result of any one thing getting slower, but instead of all the files
 taking longer.  To pick two random examples,
 `racket/lib/collects/racket/match/parse-quasi.rkt` went from ~1 second
 to ~4 seconds, and `pkgs/realm/chapter2/source.rkt` went from ~1.5
 seconds to ~3 seconds. You can see the charts here:


 http://drdr.racket-lang.org/27103/racket/lib/collects/racket/match/parse-quasi.rkt
 http://drdr.racket-lang.org/27103/pkgs/realm/chapter2/source.rkt

 The change where this happened was Matthew's addition of
 `filesystem-change-evt`, which was intended to make things faster.

 This slowdown seems to be real on my machine as well --
 realm/chapter2/source.rkt runs more than twice as slow in rev bd09a60e
 as it does in v5.3.5. I'm testing the revision right before
 `filesystem-change-evt` now.

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


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


Re: [racket-dev] Why did DrDr get much slower?

2013-07-13 Thread Sam Tobin-Hochstadt
On Sat, Jul 13, 2013 at 10:44 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:

 This slowdown seems to be real on my machine as well --
 realm/chapter2/source.rkt runs more than twice as slow in rev bd09a60e
 as it does in v5.3.5. I'm testing the revision right before
 `filesystem-change-evt` now.

The slowdown is indeed at the revision where `filesystem-change-evt`
was introduced, at least on my Linux x64 machine.

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


[racket-dev] re-rendering

2013-07-13 Thread Matthew Flatt
I've pushed changes to `raco setup' to fix problems with document
dependencies.

I think you're going to see a lot more re-renderings, and I think
it's too many --- I'm still investigating.

Matthew

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


Re: [racket-dev] Why did DrDr get much slower?

2013-07-13 Thread Jay McCarthy
FWIW, as far as I know, nothing has changed on the DrDr machine. It's
not a VM and it doesn't run any other services, so there's nothing
taking cycles from Racket.

On Sat, Jul 13, 2013 at 8:55 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
 On Sat, Jul 13, 2013 at 10:44 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu 
 wrote:

 This slowdown seems to be real on my machine as well --
 realm/chapter2/source.rkt runs more than twice as slow in rev bd09a60e
 as it does in v5.3.5. I'm testing the revision right before
 `filesystem-change-evt` now.

 The slowdown is indeed at the revision where `filesystem-change-evt`
 was introduced, at least on my Linux x64 machine.

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



-- 
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-dev] package-system update

2013-07-13 Thread Matthew Flatt
Here's a big-picture update of where we are in the new package system
and the conversion of the Racket distribution to use packages.

This message covers

 - how I see things working after the package system and
   reorganization is done, and a report on what pieces are still
   missing to reach that vision;

 - a look at how we got to our current design/reorganization choices
   and whether we're choosing the right place; and

 - speculation on why the package changes have been so difficult to
   implement.

All of that makes it a long message (sorry!), but I hope this message
is useful to bring us more in sync.


A Package-Based Racket
--

Let's take a look at how you'll do various things in the new
package-based Racket world.

(There's no new information here, and parts marked with [guess] are
especially speculative.  Still, some details may be clearer than in
earlier accounts, now that much of it is implemented, and I think a
comprehensive review may be useful.)

** Downloading release installers from PLT

The www.racket-lang.org site's big blue button will provide the same
installers that it does now, at least by default. That is, the content
provided by the installer --- DrRacket, teaching languages, etc. ---
will be pretty much the same as now.

The blue button might also provide the option of Minimal Racket
installers, which gives you something that's a small as we can make it
and still provides command-line `raco pkg'.

** Downloading installers from other distributors

There are all sorts of reasons that the main distribution from PLT
might not fit the needs of some group. Maybe the release cycle is too
long or at the wrong time. Maybe it includes much too much, much too
little, or almost the right amount but missing a crucial
package. Maybe the group wants something almost minimal, but still
with a graphical package manager. Maybe some group uses a platform for
which PLT does not provide an installer.

For many of those groups, using a Minimal Racket installer plus
selective package installations will do the trick. For others,
creating a special set of installers might be worthwhile, but there
are too many reasons and too many permutations for PLT to provide
installers that cover all of them.

Fortunately, anyone can build a set of installers and put them on a
web page, and we make it as easy as possible to build a set of
installers that start with a given set of packages. PLT could host a
web page or wiki that points to other distributors. PLT might even be
able to provide an automated service that generates a set of
installers for a basic set of platforms.

** Compiling a release from source

In addition to installers, a download site can provide a source-code
option (not specific to any platform, unlike the current source
packages), which would mainly be used for building Racket on
additional platforms.

This option is mostly a snapshot of the source-code repository for the
core, but it includes a pre-built collects tree (see technical
detail, below) and a default configuration that points back to the
distributor's site for pre-built packages.

** Adding or upgrading supported packages

In much the same way that you can easily install a set of supported
packages on your current OS, you'll be able to easily install a set of
packages that are supported by your distributor. Those packages are
pre-built, so they install quickly, along with any included
documentation.

Depending on the distributor and installer, packages might be
downloaded and installed in binary form, which means that tests and
source code (for libraries and documentation) are omitted from the
package. PLT seems unlikely to provide such installers in the near
future.

The default package scope configured by a distribution tends to be
user, which means that packages are installed in a user-specific
location.

Package updates can be made available by distributors for whatever
reason and on whatever timetable see they fit.

If your distribution is from PLT, then the supported packages are
called ring-0 packages. Ring-0 packages include contributions from
third parties (i.e., not just packages implemented by PLT) that are
vetted and regularly tested by PLT.

[Guess:] The Racket and Minimal Racket distributions might point
to different pre-built package catalogs. Possibly, the Racket
catalog never updates packages that were included in the installer (on
the grounds that the user may not have write permission to the
install), while the Minimal Racket catalog includes more frequent
updates for bug fixes (on the grounds that the user can update any
installed package).

A distributor doesn't necessarily have to provide its own package
catalog. It can instead supply an installer that works with packages
as served by some other distributor's catalog, such as PLT's
catalog. (See technical detail below.)

A user can also redirect `raco pkg' to a different catalog server,
instead of using the configuration that was 

Re: [racket-dev] package-system update

2013-07-13 Thread Juan Francisco Cantero Hurtado

On 07/13/13 20:56, Matthew Flatt wrote:
[...]

** Downloading release installers from PLT

The www.racket-lang.org site's big blue button will provide the same
installers that it does now, at least by default. That is, the content
provided by the installer --- DrRacket, teaching languages, etc. ---
will be pretty much the same as now.



Will be also available a big tarball with the source and all batteries 
included, like the actual unix source?. Will be possible to compile a 
full distro of racket with the usual configure  make  make install?


[...]

 From Here to There
--

The snapshot site

http://www.cs.utah.edu/plt/snapshots/


(Now I understand that you said me about 5.3.900 in the bug of raco pkg, 
I was confusing the development version with an old X.Y.Z.900 release :) )



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