I've been hesitant to comment on any of this, for three reasons: (1)
I've read the new package system documentation on at least 3 separate
occasions, and -- perhaps because I'm biased by having already formed
some ideas about where I'd like things to go -- I've had trouble
understanding the rat
Oh. I thought the proposal was that packages would remain multi
collection by default, and you'd add something like (define
single-collection "name") in info.rkt to opt for single. And the work
for current packagers would be if they wanted to change from multi to
single.
But I'm fine either way.
> I think more people need to speak up on this question --- particularly
> authors of existing packages, since the current proposal necessitates
> an update to each existing package.
>
> The proposal is to make single-package collections the default:
Fine by me: the only package I've contributed
Thanks, Jay. I have two high-level negative comments.
1) I don't think that it is feasible to aim for a world where 'raco setup'
never errors. (The real-world variation of your matthew-isnt-looking
example is system-specific code and we do do that a bunch.)
2) You are currently making a distincti
Hi,
I found two typos in the explanations of lisp-style list accessors.
Patch attached.
Thanks,
s.
diff --git a/collects/lang/private/beginner-funs.rkt b/collects/lang/private/beginner-funs.rkt
index 7102009..2ea82af 100644
--- a/collects/lang/private/beginner-funs.rkt
+++ b/collects/lang/private
On Jun 14, 2013, at 10:49 AM, Jay McCarthy wrote:
> Another idea is to make it so that 'raco setup' can have a mode where
> it passes error structures back that contain the paths (so 'raco pkg'
> knows where they are and which package directory it was) rather than
> just printing error messages.
I vote for this change.
I'm happy to change my packages (which make more sense as
single-collection packages anyway).
If I understand correctly, this would also have the advantage of making
a lot of github repositories (including most of mine) installable as
packages automatically, no change requ
Agreed. This looks good.
-Ian
- Original Message -
From: "Carl Eastlund"
To: "Matthew Flatt"
Cc: dev@racket-lang.org
Sent: Friday, June 14, 2013 10:42:06 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
I vote for this change. I'l
On Fri, Jun 14, 2013 at 8:40 AM, Carl Eastlund wrote:
> Jay,
>
> Thanks for the detailed summary. Right now I think the biggest missing
> piece of information when something goes wrong is "which packages were
> affected?". If I download package A, and it pulls in B and C, and they pull
> in D, E
Jay,
Thanks for the detailed summary. Right now I think the biggest missing
piece of information when something goes wrong is "which packages were
affected?". If I download package A, and it pulls in B and C, and they
pull in D, E, and F, and then somewhere along the lines raco setup fails, I
no
I vote for this change. I'll happily update my package in order to make it
easier for others to contribute new ones.
Carl Eastlund
On Fri, Jun 14, 2013 at 10:07 AM, Matthew Flatt wrote:
> I think more people need to speak up on this question --- particularly
> authors of existing packages, si
I'll try to respond to these four messages at the same time...
Sam said,
> In addition to the larger point Robby makes, this can be pretty
> confusing. For example, you can fail to install enough dependencies,
> I think.
>
> Another problem is that there's no way to know what to do to fix
> thing
I think more people need to speak up on this question --- particularly
authors of existing packages, since the current proposal necessitates
an update to each existing package.
The proposal is to make single-package collections the default:
* If a directory used as a package has no "info.rkt" fi
I've pushed the changes; syntax/modcode now exports get-module-path, which
returns the path of the most up-to-date file for a module, along with a
symbol indicating whether that is a source file, bytecode file, or native
library. It also exports get-metadata-path, which constructs derived path
nam
On Fri, Jun 14, 2013 at 6:19 AM, Sam Tobin-Hochstadt wrote:
> On Thu, Jun 13, 2013 at 10:56 PM, Jay McCarthy wrote:
>> On Thu, Jun 13, 2013 at 3:56 PM, Sam Tobin-Hochstadt
>> wrote:
>>> * The error message when you look for a missing collection is really
>>> long if you have a lot of packages i
True, but in this case, the code that is doing that reading knows what
the package was and could give a good error message.
Jay
On Thu, Jun 13, 2013 at 9:13 PM, Robby Findler
wrote:
> WRT to the stacktrace below, I guess that if the info.rkt file had been in a
> suggestively named directory, e.g
On Thu, Jun 13, 2013 at 10:56 PM, Jay McCarthy wrote:
> On Thu, Jun 13, 2013 at 3:56 PM, Sam Tobin-Hochstadt
> wrote:
>> As part of my experiment in creating a different split of the
>> repository into packages, I spent some time working with the new setup
>> for building Racket, and cut myself
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi list,
racket-5.3.3 and 5.3.4 are today both failing to compile for me with:
raco setup: in r5rs/private
raco setup: in typed-racket/optimizer
SIGSEGV MAPERR si_code 1 fault on addr 0x130
I get this error using gcc versions 4.5.3, 4.6.3 and 4.7.
18 matches
Mail list logo
