I've pushed the splice-at-file-level change so we can try it out.
There are many uses of `collection-path' that should change to
`collection-file-path'. Most would be easy to change, but as expected,
that's not always the case. For a while, I think file-level splicing
will work well only for colle
On Sat, Jul 10, 2010 at 9:59 AM, Matthew Flatt wrote:
> At Sat, 10 Jul 2010 09:49:31 -0500, Robby Findler wrote:
>> On Sat, Jul 10, 2010 at 9:47 AM, Matthew Flatt wrote:
>> > At Sat, 10 Jul 2010 09:35:28 -0500, Robby Findler wrote:
>> >> Just to be sure I understand, you're saying that these two
At Sat, 10 Jul 2010 09:49:31 -0500, Robby Findler wrote:
> On Sat, Jul 10, 2010 at 9:47 AM, Matthew Flatt wrote:
> > At Sat, 10 Jul 2010 09:35:28 -0500, Robby Findler wrote:
> >> Just to be sure I understand, you're saying that these two may or may
> >> not refer to the same file:
> >>
> >> >> (
On Sat, Jul 10, 2010 at 9:47 AM, Matthew Flatt wrote:
> At Sat, 10 Jul 2010 09:35:28 -0500, Robby Findler wrote:
>> Just to be sure I understand, you're saying that these two may or may
>> not refer to the same file:
>>
>> >> (require foo/blah)
>> >> (require "blah.rkt")
>>
>> right?
>
> Right
At Sat, 10 Jul 2010 09:35:28 -0500, Robby Findler wrote:
> Just to be sure I understand, you're saying that these two may or may
> not refer to the same file:
>
> >> (require foo/blah)
> >> (require "blah.rkt")
>
> right?
Right --- depending on whether the enclosing file is required through
Just to be sure I understand, you're saying that these two may or may
not refer to the same file:
>> (require foo/blah)
>> (require "blah.rkt")
right?
Robby
On Sat, Jul 10, 2010 at 9:07 AM, Matthew Flatt wrote:
> At Sat, 10 Jul 2010 01:48:09 -0400, Eli Barzilay wrote:
>> On Jul 9, Matthew
At Sat, 10 Jul 2010 01:48:09 -0400, Eli Barzilay wrote:
> On Jul 9, Matthew Flatt wrote:
> > At Wed, 30 Jun 2010 22:28:48 -0400, Eli Barzilay wrote:
> > > Back to `data', the problem is that you cannot have two toplevel
> > > `data' collections -- which means that you cannot have separate
> > > di
On Jul 9, Matthew Flatt wrote:
> At Wed, 30 Jun 2010 22:28:48 -0400, Eli Barzilay wrote:
> > Back to `data', the problem is that you cannot have two toplevel
> > `data' collections -- which means that you cannot have separate
> > distributions of `data/foo' and `data/bar' since they must both
> >
At Wed, 30 Jun 2010 22:28:48 -0400, Eli Barzilay wrote:
> Back to `data', the problem is that you cannot have two toplevel
> `data' collections -- which means that you cannot have separate
> distributions of `data/foo' and `data/bar' since they must both appear
> in your plt installation or in your
> 1. collect evidence that size matters to anyone out there besides you
I'm happy to be a datapoint
Size matters to me for three reasons;
- startup time is significantly slowed on my (early 2010) MacBook pro
given all the packages :
- I disable all but the minimum to run on my ASus 701 4g which s
On Jul 8, 2010, at 1:46 PM, Eli Barzilay wrote:
> But I still think that giving up on any organization will only make
> things worse, and I don't want that to happen.
Okay. As I wrote before:
> For Chicago:
>
> 1. collect evidence that size matters to anyone out there besides you
>
> 2. pr
On Jul 8, Matthias Felleisen wrote:
> This sounds like we should give up on stratification.
That was my first thought when I saw that mess: give up also on
distributing smaller packages, and dump the current distributions that
are used as sanity checks. (Given that I usually end up in long
thre
This sounds like we should give up on stratification.
On Jul 7, 2010, at 5:21 PM, Eli Barzilay wrote:
> On Jul 6, Petey Aldous wrote:
>> That would be interesting and it would not be terribly difficult to
>> instrument setup-plt to do it.
>
> There's no reason to do that -- the data is all t
On Jul 6, Petey Aldous wrote:
> That would be interesting and it would not be terribly difficult to
> instrument setup-plt to do it.
There's no reason to do that -- the data is all there in the dep
files. It just needs to be trimmed for the collection name instead of
the full paths.
I'm attachi
help.
- Petey
-Original Message-
From: Matthias Felleisen [mailto:matth...@ccs.neu.edu]
Sent: Sunday, July 04, 2010 4:16 PM
To: Petey Aldous
Cc: 'Jay McCarthy'; 'Robby Findler'; dev@racket-lang.org
Subject: Re: [racket-dev] proposal: `data' collection
Wouldn't
lay; dev@racket-lang.org; Petey Aldous
> Subject: Re: [racket-dev] proposal: `data' collection
>
> On Fri, Jul 2, 2010 at 5:17 AM, Robby Findler
> wrote:
>> Those numbers seem pretty small in today's disk sizes, but I do agree
>> that there is value in being able to d
i Barzilay; dev@racket-lang.org; Petey Aldous
Subject: Re: [racket-dev] proposal: `data' collection
On Fri, Jul 2, 2010 at 5:17 AM, Robby Findler
wrote:
> Those numbers seem pretty small in today's disk sizes, but I do agree
> that there is value in being able to divide up the dis
On 07/02/2010 11:50 AM, Eli Barzilay wrote:
> On Jul 2, Matthias Felleisen wrote:
>
> [...]
>> I think this really gets at the questions,
>>
>> what is the purpose of a collect?
>>
>> Even if we ignore the distribution idea, it should concern us that
>> we don't have a concise answer for that
On Jul 2, 2010, at 1:50 PM, Eli Barzilay wrote:
> In both of these cases,
> I think that the *proper* way to tackle the changes is to move code
> between packages (even if it keeps the same owner) -- *not* to create
> the connections and leave the code where it is.
This is good software engineer
On Jul 2, Matthias Felleisen wrote:
> 1. Size matters even if it doesn't really matter. Seeing these
>numbers makes it clear that our download will be called a
>behemoth and an ms style colossus. We all know that in the end,
>this number is irrelevant. PLT comes with a lot of extra stu
On the abundance of riches;
On Friday, July 2, 2010, Matthias Felleisen wrote:
>
> 1. Size matters even if it doesn't really matter. Seeing these numbers makes
> it clear that our download will be called a behemoth and an ms style
> colossus. We all know that in the end, this number is irreleva
1. Size matters even if it doesn't really matter. Seeing these numbers makes it
clear that our download will be called a behemoth and an ms style colossus. We
all know that in the end, this number is irrelevant. PLT comes with a lot of
extra stuff and that stuff is useful. But among the hacker
On Jul 2, Robby Findler wrote:
>
> Did you forget java and gcc?
Here's a few more:
winooski:~ eli> rpm -q --queryformat '%{SIZE} %{NAME}\n' tcl perl ghc js python
ruby lua plt-scheme gcc-java gcc kawa guile bigloo | sort -n
595769 lua
962834 js
1441553 ghc
1679403 ruby
3318547 guile
3669827 t
On Fri, Jul 2, 2010 at 9:22 AM, Eli Barzilay wrote:
> On Jul 2, Robby Findler wrote:
>> Those numbers seem pretty small in today's disk sizes,
>
> Obviously -- but the issue is not diskspace.
>
> And Jay McCarthy wrote:
>> I feel like I routinely download programs and dev environments where
>> th
On Jul 2, Robby Findler wrote:
> Those numbers seem pretty small in today's disk sizes,
Obviously -- but the issue is not diskspace.
And Jay McCarthy wrote:
> I feel like I routinely download programs and dev environments where
> the distribution is over 100MBs.
winooski:~/mail eli> rpm -q --
On Fri, Jul 2, 2010 at 5:17 AM, Robby Findler
wrote:
> Those numbers seem pretty small in today's disk sizes, but I do agree
> that there is value in being able to divide up the distribution and to
> be able to stratify things so we can better keep track of our
> dependencies.
I feel like I routi
Those numbers seem pretty small in today's disk sizes, but I do agree
that there is value in being able to divide up the distribution and to
be able to stratify things so we can better keep track of our
dependencies. (BTW, just a random question: have you thought about
trying to visualize the colle
[Sorry for the late reply.]
On Jun 30, Matthias Felleisen wrote:
> Which part is a symptom? My request for a description when there's
> no owner?
>
> The no-owner fact?
>
> The unstable collects?
"All of the above."
Here are some questions that can demonstrate the problem better:
1. What t
This sounds like a good plan to me. Taking a month to think thru the
issues carefully to plan the talk can only have good consequences for
the discussion. And delaying the solution for the release after August
does not seem like it hurts anything.
Robby
On Wed, Jun 30, 2010 at 9:34 PM, Matthias F
Your mail raises two separate issues in my mind:
1. I am beginning to think that some of our collects need a PURPOSE.txt file.
Specifically, all collects that don't have a primary owner should specify such
a file. I requested this when you proposed unstable and introduced it, and I
don't see,
Which part is a symptom? My request for a description when there's no owner?
The no-owner fact?
The unstable collects?
On Jun 30, 2010, at 10:33 PM, Eli Barzilay wrote:
> On Jun 30, Matthias Felleisen wrote:
>> Your mail raises two separate issues in my mind:
>>
>> 1. I am beginning to t
I do not understand your answer.
I nominate you for a major speech at PLT day.
You can get up to 30 mins full time and 30 mins
of discussion time.
If things aren't clear after that, you will never
be allowed again to use the words 'coherent' and
'package.'
Until then I propose we postpone
On Jun 30, Matthias Felleisen wrote:
> Your mail raises two separate issues in my mind:
>
> 1. I am beginning to think that some of our collects need a
>PURPOSE.txt file. Specifically, all collects that don't have a
>primary owner should specify such a file. I requested this when
>you
On Jun 30, Matthias Felleisen wrote:
> Eli, I do not understand and/or appreciate your objection.
>
> Here is what I understand:
>
> -- you believe that top-level collects are something coherent
> Q: could you explain this? In what sense is lang/ more or less
> coherent than data/
Th
On Jun 30, Sam Tobin-Hochstadt wrote:
> On Wed, Jun 30, 2010 at 9:44 PM, Eli Barzilay wrote:
> > On Jun 30, Sam Tobin-Hochstadt wrote:
> >> On Wed, Jun 30, 2010 at 9:02 PM, Eli Barzilay wrote:
> >> > On Jun 30, Sam Tobin-Hochstadt wrote:
> >> >> On Wed, Jun 23, 2010 at 2:29 PM, Sam Tobin-Hochstad
Eli, I do not understand and/or appreciate your objection.
Here is what I understand:
-- you believe that top-level collects are something coherent
Q: could you explain this? In what sense is lang/ more or less coherent
than data/
-- you introduce the notion of a package
Q: what i
On Wed, Jun 30, 2010 at 9:44 PM, Eli Barzilay wrote:
> On Jun 30, Sam Tobin-Hochstadt wrote:
>> On Wed, Jun 30, 2010 at 9:02 PM, Eli Barzilay wrote:
>> > On Jun 30, Sam Tobin-Hochstadt wrote:
>> >> On Wed, Jun 23, 2010 at 2:29 PM, Sam Tobin-Hochstadt
>> >> wrote:
>> >> > At the Northeastern PLT
On Jun 30, Sam Tobin-Hochstadt wrote:
> On Wed, Jun 30, 2010 at 9:02 PM, Eli Barzilay wrote:
> > On Jun 30, Sam Tobin-Hochstadt wrote:
> >> On Wed, Jun 23, 2010 at 2:29 PM, Sam Tobin-Hochstadt
> >> wrote:
> >> > At the Northeastern PLT lunch today, I proposed adding a top-level
> >> > `data' col
On Wed, Jun 30, 2010 at 9:02 PM, Eli Barzilay wrote:
> On Jun 30, Sam Tobin-Hochstadt wrote:
>> On Wed, Jun 23, 2010 at 2:29 PM, Sam Tobin-Hochstadt
>> wrote:
>> > At the Northeastern PLT lunch today, I proposed adding a top-level
>> > `data' collection, for all manner of data structures.
>>
>>
On Jun 30, Sam Tobin-Hochstadt wrote:
> On Wed, Jun 23, 2010 at 2:29 PM, Sam Tobin-Hochstadt
> wrote:
> > At the Northeastern PLT lunch today, I proposed adding a top-level
> > `data' collection, for all manner of data structures.
>
> Based on the discussion,
There was no discussion. I posted
On Wed, Jun 23, 2010 at 2:29 PM, Sam Tobin-Hochstadt wrote:
> At the Northeastern PLT lunch today, I proposed adding a top-level
> `data' collection, for all manner of data structures.
Based on the discussion, here's the plan:
In the next few days:
1. I will create a `data' collection, with subc
On Thu, Jun 24, 2010 at 2:07 PM, Eli Barzilay wrote:
> On Jun 24, Matthias Felleisen wrote:
>> On Jun 23, 2010, at 5:37 PM, Sam Tobin-Hochstadt wrote:
>>
>> > To clarify, I'm proposing that this be a part of the "core"
>>
>> I agree with this goal and the name.
>
> [BTW, when I talked about part o
On Jun 24, Matthias Felleisen wrote:
> On Jun 23, 2010, at 5:37 PM, Sam Tobin-Hochstadt wrote:
>
> > To clarify, I'm proposing that this be a part of the "core"
>
> I agree with this goal and the name.
[BTW, when I talked about part of the core earlier, the meaning was
the actual `racket' collec
On Jun 23, 2010, at 5:37 PM, Sam Tobin-Hochstadt wrote:
> To clarify, I'm proposing that this be a part of the "core"
I agree with this goal and the name. We could call it 'collections' hierarchy
as in Java, but I don't think that this is a good name. Ideally, I'd like to
call it data-struct
On Jun 23, Sam Tobin-Hochstadt wrote:
> [...] the "core" (which I think just means "the things in the Racket
> Textual" distribution).
The "Racket Textual" distribution is not a core one, its the textual
part of the racket distribution. Eventually both distributions will
be made smaller. In any
On Wed, Jun 23, 2010 at 5:31 PM, Eli Barzilay wrote:
> On Jun 23, Sam Tobin-Hochstadt wrote:
>> At the Northeastern PLT lunch today, I proposed adding a top-level
>> `data' collection, for all manner of data structures. People here
>> thought it was a good idea, so I'm proposing it to the whole g
On Jun 23, Sam Tobin-Hochstadt wrote:
> At the Northeastern PLT lunch today, I proposed adding a top-level
> `data' collection, for all manner of data structures. People here
> thought it was a good idea, so I'm proposing it to the whole group.
(The name sounds iffy to me.)
> Definitely candida
On Jun 23, 2010, at 2:29 PM, Sam Tobin-Hochstadt wrote:
Thoughts?
The idea is great. Make sure to watch 'distribution' constraints. --
Matthias
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
+1
I assume some kind of unifying API will be created. Bonus points if it
is done/available in Typed Scheme.
N.
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
At the Northeastern PLT lunch today, I proposed adding a top-level
`data' collection, for all manner of data structures. People here
thought it was a good idea, so I'm proposing it to the whole group.
Definitely candidates:
Hari Prashanth's functional data structure library (which he's been
work
50 matches
Mail list logo
