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
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" expressi
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'
15 matches
Mail list logo