At Sun, 30 Jun 2013 18:10:52 -0400, Sam Tobin-Hochstadt wrote:
On Fri, Jun 28, 2013 at 11:25 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
So, I think option 2 is right for now, and we should eventually spend
cycles on really getting `mzscheme' out of the core.
Ok, I'll focus on
On Fri, Jun 28, 2013 at 11:25 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
So, I think option 2 is right for now, and we should eventually spend
cycles on really getting `mzscheme' out of the core.
Ok, I'll focus on that.
I'm mostly done with this now. Progress in this pull request:
On Thu, Jun 27, 2013 at 8:45 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
Did you consider moving #lang mzscheme out as well?
I've now created another pull request that does this, here:
https://github.com/plt/racket/pull/377
There's one remaining question. The `make-base-namespace`
At Fri, 28 Jun 2013 14:38:03 -0400, Sam Tobin-Hochstadt wrote:
On Thu, Jun 27, 2013 at 8:45 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
Did you consider moving #lang mzscheme out as well?
I've now created another pull request that does this, here:
On Fri, Jun 28, 2013 at 5:02 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Fri, 28 Jun 2013 14:38:03 -0400, Sam Tobin-Hochstadt wrote:
On Thu, Jun 27, 2013 at 8:45 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
Did you consider moving #lang mzscheme out as well?
I've now created
At Fri, 28 Jun 2013 17:08:19 -0400, Sam Tobin-Hochstadt wrote:
On Fri, Jun 28, 2013 at 5:02 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Fri, 28 Jun 2013 14:38:03 -0400, Sam Tobin-Hochstadt wrote:
On Thu, Jun 27, 2013 at 8:45 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
Did you
On Fri, Jun 28, 2013 at 5:17 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Fri, 28 Jun 2013 17:08:19 -0400, Sam Tobin-Hochstadt wrote:
On Fri, Jun 28, 2013 at 5:02 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Fri, 28 Jun 2013 14:38:03 -0400, Sam Tobin-Hochstadt wrote:
On Thu, Jun 27, 2013
At Fri, 28 Jun 2013 17:43:42 -0400, Sam Tobin-Hochstadt wrote:
On Fri, Jun 28, 2013 at 5:17 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Fri, 28 Jun 2013 17:08:19 -0400, Sam Tobin-Hochstadt wrote:
On Fri, Jun 28, 2013 at 5:02 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Fri, 28 Jun
On Fri, Jun 28, 2013 at 6:02 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Fri, 28 Jun 2013 17:43:42 -0400, Sam Tobin-Hochstadt wrote:
On Fri, Jun 28, 2013 at 5:17 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Fri, 28 Jun 2013 17:08:19 -0400, Sam Tobin-Hochstadt wrote:
On Fri, Jun 28, 2013
At Fri, 28 Jun 2013 23:25:22 -0400, Sam Tobin-Hochstadt wrote:
On Fri, Jun 28, 2013 at 6:02 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Fri, 28 Jun 2013 17:43:42 -0400, Sam Tobin-Hochstadt wrote:
On Fri, Jun 28, 2013 at 5:17 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Fri, 28 Jun
This all looks right to me.
At Wed, 26 Jun 2013 17:38:49 -0500, Robby Findler wrote:
I can move mzlib/contract after you get done with other stuff.
Robby
On Wednesday, June 26, 2013, Sam Tobin-Hochstadt wrote:
On Tue, Jun 25, 2013 at 4:32 PM, Sam Tobin-Hochstadt
On Thu, Jun 27, 2013 at 9:02 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
This all looks right to me.
Any thoughts on `mzlib/unit200` or `mzlib/compile`?
Sam
At Wed, 26 Jun 2013 17:38:49 -0500, Robby Findler wrote:
I can move mzlib/contract after you get done with other stuff.
Robby
On
At Thu, 27 Jun 2013 09:04:46 -0400, Sam Tobin-Hochstadt wrote:
On Thu, Jun 27, 2013 at 9:02 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
This all looks right to me.
Any thoughts on `mzlib/unit200` or `mzlib/compile`?
I imagine fixing them later by
* moving the useful part of
On Thu, Jun 27, 2013 at 9:11 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Thu, 27 Jun 2013 09:04:46 -0400, Sam Tobin-Hochstadt wrote:
On Thu, Jun 27, 2013 at 9:02 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
This all looks right to me.
Any thoughts on `mzlib/unit200` or `mzlib/compile`?
I
I've now pushed this set of changes, which pass all the racket tests
and build the whole system cleanly. I think the next steps are:
- Robby is going to move mzlib/contract.
- Matthew is going to modify mzlib/compiler and mzlib/unit200.
- Ryan is working on shrinking the db collection.
- I
Did you consider moving #lang mzscheme out as well?
Robby
On Thursday, June 27, 2013, Sam Tobin-Hochstadt wrote:
I've now pushed this set of changes, which pass all the racket tests
and build the whole system cleanly. I think the next steps are:
- Robby is going to move mzlib/contract.
-
Yes, since `scheme/mzscheme` is the same language for the (many) parts
of the core that need it. There are a number of other small bits that
I'll do as well.
On Thu, Jun 27, 2013 at 8:45 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
Did you consider moving #lang mzscheme out as well?
Is there a plan for moving the mzlib tests and docs from pkgs/racket-lib to
pkgs/compatibility-lib? (I didn't move the mzlib/contract ones yet because
I wasn't sure what to do. I can do stuff, tho, if you're not already.)
Robby
On Thursday, June 27, 2013, Sam Tobin-Hochstadt wrote:
Yes, since
I've kept tests and docs where they are, because I don't know what, if
any, plans Matthew might already have about splitting those. I'm
happy to follow such plans as needed.
Sam
On Thu, Jun 27, 2013 at 10:48 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
Is there a plan for moving the
One fairly clear thing is that the mzlib manual can move into the
compatibility-lib.
We could move the mzlib-specific files from (the collection) tests/racket
into a new tests/mzlib and put that into the compatibility-lib.
But that probably requires actual adjustments because tests/racket is
On Thu, Jun 27, 2013 at 11:06 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
One fairly clear thing is that the mzlib manual can move into the
compatibility-lib.
I agree.
We could move the mzlib-specific files from (the collection) tests/racket
into a new tests/mzlib and put that into
On Thu, Jun 27, 2013 at 10:08 PM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote:
On Thu, Jun 27, 2013 at 11:06 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
One fairly clear thing is that the mzlib manual can move into the
compatibility-lib.
I agree.
We could move the
On Thu, Jun 27, 2013 at 11:12 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
On Thu, Jun 27, 2013 at 10:08 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
On Thu, Jun 27, 2013 at 11:06 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
One fairly clear thing is that the mzlib
As far as I can tell they are up to date.
Robby
On Friday, June 28, 2013, Sam Tobin-Hochstadt wrote:
On Thu, Jun 27, 2013 at 11:12 PM, Robby Findler
ro...@eecs.northwestern.edu javascript:; wrote:
On Thu, Jun 27, 2013 at 10:08 PM, Sam Tobin-Hochstadt
sa...@ccs.neu.edujavascript:;
(BTW, there's a file/private/octree-quantize which should move to
where file/gif is.)
An hour ago, Robby Findler wrote:
The sandbox, IMO, is a nice standalone library the does not need to
be in the core. (Ditto for errortrace.)
I like the definition of the core as minimum stuff to get pkgs
On Wed, Jun 26, 2013 at 6:36 AM, Eli Barzilay e...@barzilay.org wrote:
An hour ago, Robby Findler wrote:
The sandbox, IMO, is a nice standalone library the does not need to
be in the core. (Ditto for errortrace.)
I like the definition of the core as minimum stuff to get pkgs
running and we
In general I agree with Robby on the definition of the core as minimum stuff
to get pkgs running and we should be picky about what goes in. BUT, as a
small addendum, I think the idea of sandboxing is so fundamental, I'd rather
see the idea (not necessarily the current implementation) become a
What does being so fundamental have to do with being in the core vs being
in a package? We should not confuse putting things in packages with making
them second-class concepts. We can put racket/sandbox in a package without
necessarily making it any less fundamental to Racket.
Carl Eastlund
On
Fundamental to me is Robby's necessary to install packages. One day we may
wish to offer sandboxing for the installation of packages.
On Jun 26, 2013, at 8:51 AM, Carl Eastlund wrote:
What does being so fundamental have to do with being in the core vs being
in a package? We should
Lots of things that are fundamental in the sense I think you mean are not
in the core: documentation, types, eventspaces.
The building blocks of sandboxing, such as custodians and security guards
and inspectors, are in the core.
Sam
On Jun 26, 2013 8:47 AM, Matthias Felleisen
On Tue, Jun 25, 2013 at 4:32 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
While moving some files around between packages, I realized that there
are a number of things that could be moved out of the core and into
packages. Here's a partial list of things that I think are not needed
at all
On 06/26/2013 02:32 PM, Sam Tobin-Hochstadt wrote:
[...]
Things that didn't move:
* `mzlib/compile`: This is used in one place in the compiler, and
should probably be handled differently. Matthew, any suggestions?
* `mzlib/unit200`. This is loaded into a new namespace in which code
is
I can move mzlib/contract after you get done with other stuff.
Robby
On Wednesday, June 26, 2013, Sam Tobin-Hochstadt wrote:
On Tue, Jun 25, 2013 at 4:32 PM, Sam Tobin-Hochstadt
sa...@ccs.neu.edujavascript:;
wrote:
While moving some files around between packages, I realized that there
On 2013-06-25 16:32:28 -0400, Sam Tobin-Hochstadt wrote:
- mzlib/{pconvert, class100, serialize, thread, transcr}
According to the 5.3 release announcement, class100 is set to be removed
by the August release, so maybe we can just remove it entirely now.
Cheers,
Asumu
_
At Tue, 25 Jun 2013 16:32:28 -0400, Sam Tobin-Hochstadt wrote:
While moving some files around between packages, I realized that there
are a number of things that could be moved out of the core and into
packages. Here's a partial list of things that I think are not needed
at all by the rest of
Two.5 notes:
* IMO the sandbox and errortrace should stay in -- even if they're not
needed, they are both intimately tied to the core so there wouldn't
be any benefit from moving them to a package.
* I think that it makes sense to move compatibility into its own
package, and move the mzlib
36 matches
Mail list logo
