On Sun, May 19, 2013 at 6:32 PM, Asumu Takikawa as...@ccs.neu.edu wrote:
On 2013-05-19 17:55:26 -0700, Eric Dobson wrote:
This doesn't pass with contract checking enabled. make-StructTop
requires a Struct? not any old Type?. Is there a reason that the type
is not just bottom?
In the error
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,
Hi. I've successfully started Racket 5.3.4.7 with Geiser server through JNI +
SDL2 on Android (and this combination mostly works with small hacks), but got
some issues due to racket's implementation. This is last one I'm trying to
understand. What should be here instead of the address
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
13 matches
Mail list logo
