Yesterday, Robby Findler wrote:
> Hi Eli: I'm trying to understand your point. Do I have this right?
>
> Background: The git history consists of a series checkpoints in time
> of the entire repository, not a collection of individual files.
Yes, although the difference between "entire repository"
Right, but why cannot we forge an identifier easily? I'm happy getting
an armed identifier. What are the reasons for preventing such a
construction?
On Thu, May 23, 2013 at 6:04 PM, Carl Eastlund wrote:
> Essentially yes. It doesn't do anything else, but it needs an identifier to
> do it. Curre
Essentially yes. It doesn't do anything else, but it needs an identifier
to do it. Currently, TR starts with a module and a symbol, goes through an
expensive process to forge an identifier from them, just to call
free-identifier=? to compare based on the module and the symbol after all.
Doing the
Isn't that exactly what free-indentifier=? is checking for on
identfiers with a module level binding? Or is there something else it
does?
On Thu, May 23, 2013 at 3:13 PM, Carl Eastlund wrote:
> On Thu, May 23, 2013 at 4:13 PM, Ryan Culpepper wrote:
>>
>> On 05/23/2013 01:57 AM, Eric Dobson wrote
At Thu, 23 May 2013 07:09:17 -0400, Eli Barzilay wrote:
> "Relevant history" is vague.
The history I want corresponds to `git log --follow' on each of the
files that end up in a repository.
> The thing that you can't do with
> filter-branch is keep the complete history if you remove files from
>
On Thu, May 23, 2013 at 4:13 PM, Ryan Culpepper wrote:
> On 05/23/2013 01:57 AM, Eric Dobson wrote:
>
>> Some modules have macros which expand into identifiers that are not
>> exported, as they want to protect those bindings. TR currently has the
>> following code which allows it to generate an i
On 05/23/2013 01:57 AM, Eric Dobson wrote:
Some modules have macros which expand into identifiers that are not
exported, as they want to protect those bindings. TR currently has the
following code which allows it to generate an identifier which is
free-identifier=? to what would appear in the out
Hi Eli: I'm trying to understand your point. Do I have this right?
Background: The git history consists of a series checkpoints in time of the
entire repository, not a collection of individual files. So, when I do "git
log x.rkt" then what I get is essentially a filtered list (except where
people
+1 indeed, that way you can follow easily with typing a paren, thus
enclosing it again.
Laurent
Le 23 mai 2013 17:17, "John Clements" a écrit :
>
> On May 23, 2013, at 8:13 AM, Robby Findler wrote:
>
>
>
> On Thursday, May 23, 2013, Nadeem Abdul Hamid wrote:
>
>> Hello Racket devs,
>>
>> I'm wor
On May 23, 2013, at 8:13 AM, Robby Findler wrote:
>
>
> On Thursday, May 23, 2013, Nadeem Abdul Hamid wrote:
> Hello Racket devs,
>
> I'm working on tweaking how typing a double quote is handled in strings when
> DrRacket's auto parens mode is on, per recent post on the users list. If any
>
On Thursday, May 23, 2013, Nadeem Abdul Hamid wrote:
> Hello Racket devs,
>
> I'm working on tweaking how typing a double quote is handled in strings
> when DrRacket's auto parens mode is on, per recent post on the users list.
> If any of you use the mode and can offer feedback on the following, i
This sounds like the right solution to me too.
Robby
On Thursday, May 23, 2013, Matthias Felleisen wrote:
>
> +1
>
>
> On May 23, 2013, at 9:42 AM, Carl Eastlund >
> wrote:
>
> >
> > On Thu, May 23, 2013 at 9:39 AM, Matthias Felleisen <
> matth...@ccs.neu.edu > wrote:
> >
> > On May 23, 2013, at
Hello Racket devs,
I'm working on tweaking how typing a double quote is handled in strings
when DrRacket's auto parens mode is on, per recent post on the users list.
If any of you use the mode and can offer feedback on the following, it'd be
appreciated: In addition to handling Laurent's initial f
On May 23, 2013, at 9:42 AM, Sam Tobin-Hochstadt wrote:
> Given that we're currently working on splitting the entire system to
> make this dependency impossible, I don't think this is a viable option
> currently.
Perhaps that's a mistake.
_
Racket Developers list:
+1
On May 23, 2013, at 9:42 AM, Carl Eastlund wrote:
>
> On Thu, May 23, 2013 at 9:39 AM, Matthias Felleisen
> wrote:
>
> On May 23, 2013, at 9:34 AM, Sam Tobin-Hochstadt wrote:
>
> >> 2. Is it possible that we could solve the problem via a bootstrapping-only
> >> violation of our poli
On Thu, May 23, 2013 at 2:39 PM, Matthias Felleisen
wrote:
>
> On May 23, 2013, at 9:34 AM, Sam Tobin-Hochstadt wrote:
>
>>> 2. Is it possible that we could solve the problem via a bootstrapping-only
>>> violation of our policy that you can add types to Racket w/o modifying
>>> existing modules
On Thu, May 23, 2013 at 9:39 AM, Matthias Felleisen wrote:
>
> On May 23, 2013, at 9:34 AM, Sam Tobin-Hochstadt
> wrote:
>
> >> 2. Is it possible that we could solve the problem via a
> bootstrapping-only violation of our policy that you can add types to Racket
> w/o modifying existing modules?
>
On May 23, 2013, at 9:34 AM, Sam Tobin-Hochstadt wrote:
>> 2. Is it possible that we could solve the problem via a bootstrapping-only
>> violation of our policy that you can add types to Racket w/o modifying
>> existing modules?
>
> No. We can't specify types inside `racket/base` without maki
On Thu, May 23, 2013 at 2:29 PM, Matthias Felleisen
wrote:
>
> 1. At some point, we had a macro that opened up modules and made all
> module-level identifiers available. Wouldn't a flavor of this macro work here
> and, if so, wouldn't it be cheaper? Or is this what you call dumpster-diving,
> t
1. At some point, we had a macro that opened up modules and made all
module-level identifiers available. Wouldn't a flavor of this macro work here
and, if so, wouldn't it be cheaper? Or is this what you call dumpster-diving,
traversing the expansion and extracting ids from there?
2. Is it pos
On Thu, May 23, 2013 at 1:54 PM, Matthias Felleisen
wrote:
> Can you raise the level of discourse one level and perhaps figure out whether
> this is needed at all? I.e., find a different way to solve the problem? (What
> is the real problem?)
This is important, and it's the second implementatio
There are several identifiers that get introduced via expansion that TR needs
to give types to. Not all are exported. Sam probably knows the reasons why they
are not. I had to use the same code when concocting an analysis of racket core
forms.
-Ian
- Original Message -
From: Matthias Fel
This has a scary feeling to it.
Can you raise the level of discourse one level and perhaps figure out whether
this is needed at all? I.e., find a different way to solve the problem? (What
is the real problem?)
On May 23, 2013, at 1:57 AM, Eric Dobson wrote:
> Some modules have macros whi
On Thu, May 23, 2013 at 7:09 AM, Eli Barzilay wrote:
> Just now, Carl Eastlund wrote:
> > On Thu, May 23, 2013 at 6:57 AM, Eli Barzilay wrote:
> >
> > A few minutes ago, Carl Eastlund wrote:
> > >
> > > It doesn't seem wrong to me. It's an accurate representation
> > > of the hi
Just now, Carl Eastlund wrote:
> On Thu, May 23, 2013 at 6:57 AM, Eli Barzilay wrote:
>
> A few minutes ago, Carl Eastlund wrote:
> >
> > It doesn't seem wrong to me. It's an accurate representation
> > of the history of the project, which is exactly what git is
> > for retai
On Thu, May 23, 2013 at 6:57 AM, Eli Barzilay wrote:
> A few minutes ago, Carl Eastlund wrote:
> > On Thu, May 23, 2013 at 5:49 AM, Eli Barzilay wrote:
> >
> > 9 hours ago, Carl Eastlund wrote:
> > > I was going to comment on the same thing. While a naive use
> > > of "git filter-br
A few minutes ago, Carl Eastlund wrote:
> On Thu, May 23, 2013 at 5:49 AM, Eli Barzilay wrote:
>
> 9 hours ago, Carl Eastlund wrote:
> > I was going to comment on the same thing. While a naive use
> > of "git filter-branch" might not retain the history, it should
> > be entirely
On Thu, May 23, 2013 at 5:49 AM, Eli Barzilay wrote:
> 9 hours ago, Carl Eastlund wrote:
> > I was going to comment on the same thing. While a naive use of "git
> > filter-branch" might not retain the history, it should be entirely
> > possible to do something a little more intelligent and keep
9 hours ago, Carl Eastlund wrote:
> I was going to comment on the same thing. While a naive use of "git
> filter-branch" might not retain the history, it should be entirely
> possible to do something a little more intelligent and keep that
> history.
Just to be clear, this is exactly what you can
9 hours ago, Matthew Flatt wrote:
> At Wed, 22 May 2013 14:50:41 -0400, Eli Barzilay wrote:
> > That's true, but the downside of changing the structure and having
> > files and directories move post structure change will completely
> > destroy the relevant edit history of the files, since it will n
30 matches
Mail list logo
