[racket-dev] Temporal Contracts and Match Automata
I've recently prepared an extension to the contract system based on some work that Cormac Flanagan and I did. The code is available at: https://github.com/jeapostrophe/exp/tree/master/temporal-ctcs The documentation is available at: http://faculty.cs.byu.edu/~jay/tmp/20110107-tempc/temp-c/ and http://faculty.cs.byu.edu/~jay/tmp/20110107-tempc/automata/ Here is a short example: (with-monitor (cons/c (label 'malloc (-> addr?)) (label 'free (-> addr? void?))) (complement (seq (star _) (dseq (call 'free addr) (seq (star (not (ret 'malloc (== addr (call 'free (== addr))) This creates a contract for a pair of functions, malloc and free, where the contract system ensures the malloc always returns addresses and free takes address and returns void. Additionally, the monitoring system ensures that the only legal interactions between these functions and their clients are those that do not end in a double free (a free followed by a free without a malloc of the same address in between.) Should this code be a PLaneT package or should it go into the core? I think it is quite a big extension over racket/contract. What do you think generally? Jay -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
I'm surprised no one has linked this all-clarifying blog post :) http://tartley.com/?p=1267 On Fri, Jan 7, 2011 at 4:52 PM, Eli Barzilay wrote: > Two hours ago, John Clements wrote: >> >> Taking a step back: is there really anything wrong with such >> commits? > > What Robby and Vincent generalizes too -- merging can be confusing > sometimes, either to the author or to the others; and there are a > bunch of tools that become less useful if the history line is > cluttered with merges (for example, the log graphs become much less > useful). OTOH, doing a rebase means that for most users you end up > doing the same amount of work (a conflict to resolve will happen > either way). > > You could argue that these tools are the blame -- they could just > ignore these merges -- but there is no proper way to know when a merge > commit was really trivial (the notifications script is guessing when > it is, and I had a question on this on the git list, bottom line is > that you can't tell without replaying the whole thing). Bisecting is > even more problematic, since it really wants a flat line to work on. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Can't use (current-output-port) with subprocess in DrRacket: does it matter?
An hour and a half ago, John Clements wrote: > Currently, you can't run the mongodb tests in DrRacket, because they > use "subprocess" with (current-output-port), which (in DrRacket) is > not a file-stream port. So they should switch to `process' which does the necessary gluing. (One thing I don't like in this -- `subprocess' is nice in that it returns multiple values, but in practice you need to use `process' etc because of the above.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Can't use (current-output-port) with subprocess in DrRacket: does it matter?
On Jan 7, 2011, at 1:47 PM, Robby Findler wrote: > I don't think it is possible with our current port support to make a > port that goes into a text% and returns #t to that predicate (is it?). In that case, I'll edit the docs to reflect this. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Two hours ago, John Clements wrote: > > Taking a step back: is there really anything wrong with such > commits? What Robby and Vincent generalizes too -- merging can be confusing sometimes, either to the author or to the others; and there are a bunch of tools that become less useful if the history line is cluttered with merges (for example, the log graphs become much less useful). OTOH, doing a rebase means that for most users you end up doing the same amount of work (a conflict to resolve will happen either way). You could argue that these tools are the blame -- they could just ignore these merges -- but there is no proper way to know when a merge commit was really trivial (the notifications script is guessing when it is, and I had a question on this on the git list, bottom line is that you can't tell without replaying the whole thing). Bisecting is even more problematic, since it really wants a flat line to work on. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Can't use (current-output-port) with subprocess in DrRacket: does it matter?
I don't think it is possible with our current port support to make a port that goes into a text% and returns #t to that predicate (is it?). Robby On Fri, Jan 7, 2011 at 2:36 PM, John Clements wrote: > Currently, you can't run the mongodb tests in DrRacket, because they use > "subprocess" with (current-output-port), which (in DrRacket) is not a > file-stream port. > > In DrRacket's interactions window: > >> (file-stream-port? (current-output-port)) > #f > > Is this expected, or should DrRacket's current-output-port be a file-stream? > > John > > > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Four hours ago, Stevie Strickland wrote: > In general, this is why people say you really shouldn't train > yourself to do "git pull" automatically, because there's plenty of > places where you don't want that. I always do "git remote > update"/"git merge ..." separately because there's plenty of times > where I don't want to merge. I have this alias in my ~/.gitconfig file: up = pull --ff-only --stat --all so I can run `git up' conveniently. `--ff-only' is the key here, it makes the branch you're on advance only if it's a fast-forward. Otherwise it stops after fetching and leaves you with resolving things. For people who never use branches, you can alias it to `pull --rebase' instead. (And I wrote about all of this too in the git intro text.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Four hours ago, Stevie Strickland wrote: > On Jan 7, 2011, at 12:29 PM, Robby Findler wrote: > > Then, on the laptop, I did a git pull, and I ended up with the > > commits back in the original order and a merge commit afterwards > > but I would rather just have my state be like the server's was. > > Then don't do git pull. That not only updates your remotes, but > does a "git merge" (which will create a merge point if it's not a > simple fast-forward, as you've seen here). What you want to do is > update your remotes using "git remote update", and then use "git > reset --hard" to reset to the server's master (or whichever branch > off of which you're working). Yes, a hard reset is the simplest thing to do, basically dumping everything you had on the laptop and continuing from where you were on the desktop. But... Four hours ago, Robby Findler wrote: > Even worse, I forget if I forgot to push some changes from laptop or > not. ...that's the dangerous part -- a hard reset will make your master branch be where the desktop was, and if you forgot to push a change from the laptop then it will be lost. Two ways to solve this: * Use a rebase of the laptop's master on top of the desktop. Usually, git can figure out changes that were already included and it will omit them, leaving you with only forgotten commits, if any. > As far as my other question goes, I think that perhaps the right > answer is just "don't forget". * Yeah -- don't forget to push changes... IOW, just do the hard reset thing. This is practical, btw -- git maintains a "reflog" which logs where each branch was in the past (keeping information that goes back a month). This means that when you do the hard reset, you still have the old commit sha1 in the reflog, so if you find out that some commits are missing, you can use the reflog to see where you were, and look for the missing commits. (This is actually not as hard as it sounds.) Git does do an occasional GC over the object store, but it considers the reflog as part of the active roots, so you *are* safe for some time. > That is, when I go back to my laptop and I see that "git status" > thinks that things are not up to date (ie, before doing a pull or > 'git remote update'), then I should take my changes there and just > plan to either kill them or put them off in a branch somewhere else, > get the latest stuff from the server and then go from there. Remember that creating a branch is *very* cheap, so you can just create a new branch to point to where the master points, then do a hard reset with the master while you have the other branch conveniently available for comparisons etc. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Fri, Jan 7, 2011 at 3:00 PM, Eli Barzilay wrote:
> 5 minutes ago, Stevie Strickland wrote:
>> On Jan 7, 2011, at 3:43 PM, Eli Barzilay wrote:
>> > Yesterday, Robby Findler wrote:
>> >>
>> >> So I did this ("git" means "git.racket-lang.org" in my ssh setup as
>> >> I did things that way before Eli's recommendation changed)
>> >>
>> >> git clone git:robby/plt
>> >> git remote add plt git:plt
>> >
>> > It might be more convenient to flip it -- clone git:plt first, and
>> > then add a remote for git:robby/plt, so operations go to the main
>> > repo by default and to your copy only when specifically requested
>> > (which happens when you move).
>>
>> Personally, I prefer the other way; that I only affect the main repo
>> when I explicitly say so (and thus really mean it). This is
>> especially true when I'm doing branch juggling on my own repository,
>> so that I don't accidentally push new branches onto the main
>> repository. It's easy to fix my repository if I screw up, but
>> things that hit the main repository are forever (or at least,
>> forever in its history somewhere).
>
> I should have clarified:
>
> It might be more convenient for Robby to flip it
>
> This is following the same guess I have about how his working, where
> he only uses the private repo for machine switches.
I'm trying it the way Stevie is saying because I spend ~3 hours/day
(two 1.5 hour times) on the bus and I'm experimenting with switching
what I've done via robby/plt to home and to work. So if I continue
this way, switching will be the norm.
Also, in the short term, I think this'll force me to learn git, which
may or may not be a good thing.
Robby
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
5 hours ago, Robby Findler wrote: > Another question: what if I commit something just for the purpose of > moving to another machine and I don't want that commit to show up in > the main repository? Is that possible? (My tree is currently in that > state; it is one commit ahead of plt/master but that commit message > is a lie-- I've just started to do that job; ordinarily I'd do git > commit --amend to add more stuff to it, but now I'm worried about > that.) See my git text, look for "squash" and "fixup" -- I also have a description of such "checkpoint commits" and how they can be squashed away before you push the final product. (And I wrote that description mainly because I had your use case in mind.) 5 hours ago, Jay McCarthy wrote: > I like to do an interactive rebase and squash commits together: > > git rebase -i HEAD^^10 > > where 10 is how many commits ahead of the master I am You probably mean "HEAD~10". But again, see my text -- you don't need to count commits, instead just use git rebase -i origin which will show you all of the commits you have over the origin/master branch for reorganization. 5 hours ago, Robby Findler wrote: > Can I do that once I've pushed to robby/plt? What happens to other > machines that have unsquashed versions of those commits? Looks like you know what to do with that now, but just to summarize: any kind of history rewriting means that people will have problems updating -- in the case of robby/plt this is easy since "people" is only you, and you never need to worry about combining stuff if you do it only when you move between machines. It's only when you want others to use it that you need to be careful. (For example, Matthew warning people that he's occasionally rebasing the gr2 repo.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Yesterday, Carl Eastlund wrote: > > What you want to do is run gitk and/or git log on origin/master, > which is where those 53 show up. A useful bit here -- you can pass `--all' to gitk which will make it show all branches and tags. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
5 minutes ago, Stevie Strickland wrote:
> On Jan 7, 2011, at 3:43 PM, Eli Barzilay wrote:
> > Yesterday, Robby Findler wrote:
> >>
> >> So I did this ("git" means "git.racket-lang.org" in my ssh setup as
> >> I did things that way before Eli's recommendation changed)
> >>
> >> git clone git:robby/plt
> >> git remote add plt git:plt
> >
> > It might be more convenient to flip it -- clone git:plt first, and
> > then add a remote for git:robby/plt, so operations go to the main
> > repo by default and to your copy only when specifically requested
> > (which happens when you move).
>
> Personally, I prefer the other way; that I only affect the main repo
> when I explicitly say so (and thus really mean it). This is
> especially true when I'm doing branch juggling on my own repository,
> so that I don't accidentally push new branches onto the main
> repository. It's easy to fix my repository if I screw up, but
> things that hit the main repository are forever (or at least,
> forever in its history somewhere).
I should have clarified:
It might be more convenient for Robby to flip it
This is following the same guess I have about how his working, where
he only uses the private repo for machine switches.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
(Ping for Mike) Yesterday, Robby Findler wrote: > that is off on its own side path. Ie my graph looks like this: > >o improve canvas drawing docs >| >o Merge remote branch origin (committer Sperber) > /| > / | > | o > | | > | 73 commits (why 73?!) > | | > | o like f57b431c2e6466c (missed other case) > * | > \ | > \| >o New Racket version 5.0.99.6 > > where the * is the commit mentioned above. What you see here is the result of Mike pushing a commit without rebasing it, getting a merge instead. Specifically, it looks like Mike had his repo at the 5.0.99.6 commit, he then commited something, merged (not rebased) which added the 73 commits and created a merge commit that ties the knot at the top. What gitk etc are doing is some kind of a sort that is supposed to make things look better, but IME, this can be confusing (perhaps since I'm usually aware of the timeline). You can use a `-d' argument to gitk to make it sort things by date, which will show things in the order they were made. You can also use the log command -- compare the output of these two things side-by-side: git log --pretty=oneline --graph git log --pretty=oneline --graph --date-order (Mike: it would really be better to rebase, and avoid such unnecessary confusions.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Jan 7, 2011, at 3:43 PM, Eli Barzilay wrote:
> Yesterday, Robby Findler wrote:
>>
>> So I did this ("git" means "git.racket-lang.org" in my ssh setup as
>> I did things that way before Eli's recommendation changed)
>>
>> git clone git:robby/plt
>> git remote add plt git:plt
>
> It might be more convenient to flip it -- clone git:plt first, and
> then add a remote for git:robby/plt, so operations go to the main repo
> by default and to your copy only when specifically requested (which
> happens when you move).
Personally, I prefer the other way; that I only affect the main repo when I
explicitly say so (and thus really mean it). This is especially true when I'm
doing branch juggling on my own repository, so that I don't accidentally push
new branches onto the main repository. It's easy to fix my repository if I
screw up, but things that hit the main repository are forever (or at least,
forever in its history somewhere).
Then again, I tend to work with larger, longer-lived branches than most people,
so YMMV.
Stevie
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Yesterday, Robby Findler wrote:
>
> So I did this ("git" means "git.racket-lang.org" in my ssh setup as
> I did things that way before Eli's recommendation changed)
>
> git clone git:robby/plt
> git remote add plt git:plt
It might be more convenient to flip it -- clone git:plt first, and
then add a remote for git:robby/plt, so operations go to the main repo
by default and to your copy only when specifically requested (which
happens when you move).
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Yesterday, Carl Eastlund wrote: > > First do a "git fetch " for that remote, or just "git > remote update" which fetches from all your remotes. Then "git reset > --hard /master" will clobber whatever you have and > replace it with the remote's master branch. Note that this changes the current branch. (IOW, it can be tricky when the current branch is not `master'.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
[Pre-apologies for sending multiple messages, this thread is way too big to combine replies.] Yesterday, Robby Findler wrote: > Thanks, Carl. I have tried that route in the past and I found that I > let robby/plt get too far out of sync with the tree. So I'm looking > for a workflow where, perhaps, what I do is create robby/plt only > when I want to move between machines and use it as a temporary > storage place (as Eli's email suggests). Does that sound workable to > you? My kind of guess (since I didn't read everything yet) is that you settled on the usual use of robby/plt for syncing, with moving implemented by pushing there from one machine then pulling from another. (This is easy, since a repository is just a storage place for commit chains, so it's mostly unrelated to rebasing -- the only issue is forcing pushes that change a certain branch instead of just extending it.) The only slightly annoying thing that you'll run into is lots of noise whenever you haven't used the repository for a while, since there is a lot that will pass on. Here's a slight variant on this that can overall be more convenient when moving between machines is the exceptional case: * You usually work against the main repo, ignoring robby/plt completely * When you want to move you *delete* robby/plt (if it exists), then fork it from the plt repo, then push the changes over there. * On the new machine you pull (or clone) from it, and you can not just remove it, since you'll continue to work against the main repo. The important point here is that the second step is done efficiently enough that it is likely to be faster than updating a week-old repo. (Since it's basically a fast copy of the plt repo done by creating links, vs sending all the new content from your machine to the server.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Can't use (current-output-port) with subprocess in DrRacket: does it matter?
Currently, you can't run the mongodb tests in DrRacket, because they use "subprocess" with (current-output-port), which (in DrRacket) is not a file-stream port. In DrRacket's interactions window: > (file-stream-port? (current-output-port)) #f Is this expected, or should DrRacket's current-output-port be a file-stream? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
At Fri, 7 Jan 2011 11:39:33 -0800, John Clements wrote: > Taking a step back: is there really anything wrong with such commits? Given > that drdr and e-mail alerts are based on pushes rather than commits, it seems > not unreasonable to just let those be intermediate commits. I can see that > it's a bit easier to give a nice name to a single big commit, but if the > alternative is the fancy dance that this thread is suggesting, it seems like > it might be simpler just to go with the simple solution (tautology alert) git bisect is less useful if some commits are broken states. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Fri, Jan 7, 2011 at 1:39 PM, John Clements wrote: > > On Jan 7, 2011, at 7:42 AM, Robby Findler wrote: > >> Another question: what if I commit something just for the purpose of >> moving to another machine and I don't want that commit to show up in >> the main repository? Is that possible? (My tree is currently in that >> state; it is one commit ahead of plt/master but that commit message is >> a lie-- I've just started to do that job; ordinarily I'd do git commit >> --amend to add more stuff to it, but now I'm worried about that.) > > Taking a step back: is there really anything wrong with such commits? Given > that drdr and e-mail alerts are based on pushes rather than commits, it seems > not unreasonable to just let those be intermediate commits. I can see that > it's a bit easier to give a nice name to a single big commit, but if the > alternative is the fancy dance that this thread is suggesting, it seems like > it might be simpler just to go with the simple solution (tautology alert). IIUC, avoiding merges is actually the simpler solution overall. In this particular example, the merge came about because I issued the wrong command and Stevie pointed out that getting rid of it required running the same command that I should have run to get things in the right state in the first place. More generally, running "git pull" (just like that, without, say --ff-only or --rebase) is, I agree with Stevie, a bad idea (because it does two things: downloads and merges). If you're doing something complex like we're talking about you want to see the two steps one at a time as it is easier to fix problems after the first step before the second. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Jan 7, 2011, at 7:42 AM, Robby Findler wrote: > Another question: what if I commit something just for the purpose of > moving to another machine and I don't want that commit to show up in > the main repository? Is that possible? (My tree is currently in that > state; it is one commit ahead of plt/master but that commit message is > a lie-- I've just started to do that job; ordinarily I'd do git commit > --amend to add more stuff to it, but now I'm worried about that.) Taking a step back: is there really anything wrong with such commits? Given that drdr and e-mail alerts are based on pushes rather than commits, it seems not unreasonable to just let those be intermediate commits. I can see that it's a bit easier to give a nice name to a single big commit, but if the alternative is the fancy dance that this thread is suggesting, it seems like it might be simpler just to go with the simple solution (tautology alert). John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Jan 7, 2011, at 12:43 PM, Stevie Strickland wrote: > On Jan 7, 2011, at 12:29 PM, Robby Findler wrote: >> Then, on the laptop, I did a git pull, and I ended up with the commits >> back in the original order and a merge commit afterwards but I would >> rather just have my state be like the server's was. > > Then don't do git pull. That not only updates your remotes, but does a "git > merge" (which will create a merge point if it's not a simple fast-forward, as > you've seen here). What you want to do is update your remotes using "git > remote update", and then use "git reset --hard" to reset to the server's > master (or whichever branch off of which you're working). At this point, though, you can still do git reset --hard to just throw away all the merging you did and reset to the server's state. So it's not like you have to go back in time or anything to fix this. In general, this is why people say you really shouldn't train yourself to do "git pull" automatically, because there's plenty of places where you don't want that. I always do "git remote update"/"git merge ..." separately because there's plenty of times where I don't want to merge. Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Jan 7, 2011, at 12:29 PM, Robby Findler wrote: > Then, on the laptop, I did a git pull, and I ended up with the commits > back in the original order and a merge commit afterwards but I would > rather just have my state be like the server's was. Then don't do git pull. That not only updates your remotes, but does a "git merge" (which will create a merge point if it's not a simple fast-forward, as you've seen here). What you want to do is update your remotes using "git remote update", and then use "git reset --hard" to reset to the server's master (or whichever branch off of which you're working). Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] struct contracts
My answers are: 1. There isn't, but I've been planning to do this as soon as I revisit define-struct/contract in the new chaperone/impersonator world. 2. It's doable, but hasn't been done yet. I'll try and keep this in mind when I revisit the things listed in 1. If I were to do it, I'd imagine it'd look something like: (define-struct/contract foo ([bar number?] [moo (bar) ]) #:mutable) (i.e. it'd use the ->i convention for listing other fields on which this one is dependent.) Stevie On Jan 7, 2011, at 12:16 PM, Robby Findler wrote: > I think that chaperones let us implement this contract, but I don't > think that you can actually do it yet in the contract library (because > of the dependency), but Stevie would know best. > > Robby > > On Fri, Jan 7, 2011 at 9:58 AM, Matthias Felleisen > wrote: >> >> 1. Is there a struct/contract? >> >> 2. I would like to write something like this: >> >> (define-struct/contract foo ([bar number?][moo (->i (*bar*) ([x (and/c >> number? (>/c bar))]) (r number?))]) #:mutable) >> >> The *bar* is a 'reference' to the bar field, that is, I want to have a >> function contract for a structure field that depends on the (current) value >> of a (mutable) field of the same structure. >> >> Is this doable? >> >> 2a. I considered writing a function foo-init that mimics this, but I can't >> write this either. >> >> Q: Is my only choice to write a class with a contract? >> >> >> -- Matthias >> >> _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Okay, I tried an example of this and I'm getting stuck. I did one commit and pushed on my laptop. On the desktop, I did another commit and then I used an interactive rebase to swap the order of the commits. Then, I did a push --force, which I think I understand and I think worked. Then, on the laptop, I did a git pull, and I ended up with the commits back in the original order and a merge commit afterwards but I would rather just have my state be like the server's was. --- As far as my other question goes, I think that perhaps the right answer is just "don't forget". That is, when I go back to my laptop and I see that "git status" thinks that things are not up to date (ie, before doing a pull or 'git remote update'), then I should take my changes there and just plan to either kill them or put them off in a branch somewhere else, get the latest stuff from the server and then go from there. Thanks, Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] struct contracts
I think that chaperones let us implement this contract, but I don't think that you can actually do it yet in the contract library (because of the dependency), but Stevie would know best. Robby On Fri, Jan 7, 2011 at 9:58 AM, Matthias Felleisen wrote: > > 1. Is there a struct/contract? > > 2. I would like to write something like this: > > (define-struct/contract foo ([bar number?][moo (->i (*bar*) ([x (and/c > number? (>/c bar))]) (r number?))]) #:mutable) > > The *bar* is a 'reference' to the bar field, that is, I want to have a > function contract for a structure field that depends on the (current) value > of a (mutable) field of the same structure. > > Is this doable? > > 2a. I considered writing a function foo-init that mimics this, but I can't > write this either. > > Q: Is my only choice to write a class with a contract? > > > -- Matthias > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
I think what I get from you and Jay is that it is possible to do, but I guess I'm not completely clear on one particular usecase how it would play out. (I understand that history rewriting is not allowed on plt/master and that makes a lot of sense, etc.) Lets say that, on my laptop I make 7 commits. Then I push this to robby/plt and pull that down on my desktop. Now I squash those 7 commits into 3 and then I make another commit (perhaps in the middle somewhere via an interactive rebase). Now I push that. Now I go back to my laptop and everything will be all messed up. Even worse, I forget if I forgot to push some changes from laptop or not. What should I do to deal with this kind of situation? Robby On Fri, Jan 7, 2011 at 9:50 AM, Sam Tobin-Hochstadt wrote: > On Fri, Jan 7, 2011 at 10:42 AM, Robby Findler > wrote: >> Another question: what if I commit something just for the purpose of >> moving to another machine and I don't want that commit to show up in >> the main repository? Is that possible? (My tree is currently in that >> state; it is one commit ahead of plt/master but that commit message is >> a lie-- I've just started to do that job; ordinarily I'd do git commit >> --amend to add more stuff to it, but now I'm worried about that.) > > If you commit something to your own private repository, you can then > rebase relative to plt/master, and then the bogus commit won't show up > (or rather, whatever the result of the rebase is will show up, which > can differ arbitrarily). > > Once you commit to the main repository, though, history-rewriting is > disallowed. > > Does that answer your question? > -- > sam th > sa...@ccs.neu.edu > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
I like to do an interactive rebase and squash commits together: git rebase -i HEAD^^10 where 10 is how many commits ahead of the master I am Jay 2011/1/7 Robby Findler : > Another question: what if I commit something just for the purpose of > moving to another machine and I don't want that commit to show up in > the main repository? Is that possible? (My tree is currently in that > state; it is one commit ahead of plt/master but that commit message is > a lie-- I've just started to do that job; ordinarily I'd do git commit > --amend to add more stuff to it, but now I'm worried about that.) > > Robby > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] struct contracts
1. Is there a struct/contract? 2. I would like to write something like this: (define-struct/contract foo ([bar number?][moo (->i (*bar*) ([x (and/c number? (>/c bar))]) (r number?))]) #:mutable) The *bar* is a 'reference' to the bar field, that is, I want to have a function contract for a structure field that depends on the (current) value of a (mutable) field of the same structure. Is this doable? 2a. I considered writing a function foo-init that mimics this, but I can't write this either. Q: Is my only choice to write a class with a contract? -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
That's what the force option for a rebasing fetch is for, to accept overwriting the history on the machine. [For example, on Matthew's gr2 branch, he would regularly do this.] Jay 2011/1/7 Robby Findler : > Can I do that once I've pushed to robby/plt? What happens to other > machines that have unsquashed versions of those commits? > > Robby > > On Fri, Jan 7, 2011 at 9:43 AM, Jay McCarthy wrote: >> I like to do an interactive rebase and squash commits together: >> >> git rebase -i HEAD^^10 >> >> where 10 is how many commits ahead of the master I am >> >> Jay >> >> 2011/1/7 Robby Findler : >>> Another question: what if I commit something just for the purpose of >>> moving to another machine and I don't want that commit to show up in >>> the main repository? Is that possible? (My tree is currently in that >>> state; it is one commit ahead of plt/master but that commit message is >>> a lie-- I've just started to do that job; ordinarily I'd do git commit >>> --amend to add more stuff to it, but now I'm worried about that.) >>> >>> Robby >>> _ >>> For list-related administrative tasks: >>> http://lists.racket-lang.org/listinfo/dev >>> >> >> >> >> -- >> Jay McCarthy >> Assistant Professor / Brigham Young University >> http://faculty.cs.byu.edu/~jay >> >> "The glory of God is Intelligence" - D&C 93 >> > -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Fri, Jan 7, 2011 at 10:42 AM, Robby Findler wrote: > Another question: what if I commit something just for the purpose of > moving to another machine and I don't want that commit to show up in > the main repository? Is that possible? (My tree is currently in that > state; it is one commit ahead of plt/master but that commit message is > a lie-- I've just started to do that job; ordinarily I'd do git commit > --amend to add more stuff to it, but now I'm worried about that.) If you commit something to your own private repository, you can then rebase relative to plt/master, and then the bogus commit won't show up (or rather, whatever the result of the rebase is will show up, which can differ arbitrarily). Once you commit to the main repository, though, history-rewriting is disallowed. Does that answer your question? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Can I do that once I've pushed to robby/plt? What happens to other machines that have unsquashed versions of those commits? Robby On Fri, Jan 7, 2011 at 9:43 AM, Jay McCarthy wrote: > I like to do an interactive rebase and squash commits together: > > git rebase -i HEAD^^10 > > where 10 is how many commits ahead of the master I am > > Jay > > 2011/1/7 Robby Findler : >> Another question: what if I commit something just for the purpose of >> moving to another machine and I don't want that commit to show up in >> the main repository? Is that possible? (My tree is currently in that >> state; it is one commit ahead of plt/master but that commit message is >> a lie-- I've just started to do that job; ordinarily I'd do git commit >> --amend to add more stuff to it, but now I'm worried about that.) >> >> Robby >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev >> > > > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://faculty.cs.byu.edu/~jay > > "The glory of God is Intelligence" - D&C 93 > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Another question: what if I commit something just for the purpose of moving to another machine and I don't want that commit to show up in the main repository? Is that possible? (My tree is currently in that state; it is one commit ahead of plt/master but that commit message is a lie-- I've just started to do that job; ordinarily I'd do git commit --amend to add more stuff to it, but now I'm worried about that.) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
