[racket-dev] OS X 10.7 review/summary
I don't know if you folks have already seen this, but for any of you considering or using OS X 10.7, the Ars Technica review appears to contain some fairly detailed developer information. I'm only on the second page, but table of contents entries such as "Automatic Reference Counting vs. Garbage Collection" look ... interesting. http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars • Installation • Reconsidering fundamentals • Lion's new look • Scroll bars • Window resizing • Animation • Here's to the crazy ones • Window management • Application management • Document model • Process model • The pitch • The reality • Internals • Security • Sandboxing • Privilege separation • Automatic Reference Counting • Enter (and exit) garbage collection • Cocoa memory management • Enter ARC • ARC versus garbage collection • ARC versus the world • The state of the file system • What's wrong with HFS+ • File system changes in Lion • File system future • Document revisions • Resolution independence • Applications • The Finder • Mail • Safari • Grab bag • System Preferences • Auto-correction • Mobile Time Machine • Lock screen • Emoji • Terminal • About This Mac • Recommendations • Conclusion smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OS X 10.7 review/summary
John Clements wrote at 08/06/2011 06:29 AM: [...] table of contents entries such as "Automatic Reference Counting vs. Garbage Collection" look ... interesting. [...] Might be helpful to exchange notes with CL implementors on any wins that can be had with any new Apple OS X features. OS X is popular among CL hackers, sometimes for running CL locally, and you know that CL implementors tend to be all over low-level optimizations (sometimes to the point of working only if certain kernel versions with certain nonstandard kernel options are set, and breaking on a new gcc or glibc version). (Separately, OS X laptops are also popular among CL hackers who use them as Emacs-based front-ends to SBCL or something running on headless Linux machines, for some goshforsaken reason.) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OS X 10.7 review/summary
In a fairly user-focused review I saw, the 'automatic snapshots' sounded great. Apparently an app that subscribes to some Lion protocol gets automatic snapshots so that you can say 'I don't like what I did in the last 10 mins, let's go back' It also saves automatically when you forget. Good for kids, students, and old professors. On Aug 6, 2011, at 6:29 AM, John Clements wrote: > I don't know if you folks have already seen this, but for any of you > considering or using OS X 10.7, the Ars Technica review appears to contain > some fairly detailed developer information. I'm only on the second page, but > table of contents entries such as "Automatic Reference Counting vs. Garbage > Collection" look ... interesting. > > http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars > > > • Installation > • Reconsidering fundamentals > • Lion's new look > • Scroll bars > • Window resizing > • Animation > • Here's to the crazy ones > • Window management > • Application management > • Document model > • Process model > • The pitch > • The reality > • Internals > • Security > • Sandboxing > • Privilege separation > • Automatic Reference Counting > • Enter (and exit) garbage collection > • Cocoa memory management > • Enter ARC > • ARC versus garbage collection > • ARC versus the world > • The state of the file system > • What's wrong with HFS+ > • File system changes in Lion > • File system future > • Document revisions > • Resolution independence > • Applications > • The Finder > • Mail > • Safari > • Grab bag > • System Preferences > • Auto-correction > • Mobile Time Machine > • Lock screen > • Emoji > • Terminal > • About This Mac > • Recommendations > • Conclusion_ > 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] OS X 10.7 review/summary
On Aug 6, 2011, at 11:14 AM, Matthias Felleisen wrote: > > In a fairly user-focused review I saw, the 'automatic snapshots' sounded > great. Apparently an app that subscribes to some Lion protocol gets automatic > snapshots so that you can say 'I don't like what I did in the last 10 mins, > let's go back' It also saves automatically when you forget. Good for kids, > students, and old professors. Agreed; it'll probably take some work on our part, though (a.k.a.: work on Robby & Matthew's part). John > > > > > On Aug 6, 2011, at 6:29 AM, John Clements wrote: > >> I don't know if you folks have already seen this, but for any of you >> considering or using OS X 10.7, the Ars Technica review appears to contain >> some fairly detailed developer information. I'm only on the second page, >> but table of contents entries such as "Automatic Reference Counting vs. >> Garbage Collection" look ... interesting. >> >> http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars >> >> >> • Installation >> • Reconsidering fundamentals >> • Lion's new look >> • Scroll bars >> • Window resizing >> • Animation >> • Here's to the crazy ones >> • Window management >> • Application management >> • Document model >> • Process model >> • The pitch >> • The reality >> • Internals >> • Security >> • Sandboxing >> • Privilege separation >> • Automatic Reference Counting >> • Enter (and exit) garbage collection >> • Cocoa memory management >> • Enter ARC >> • ARC versus garbage collection >> • ARC versus the world >> • The state of the file system >> • What's wrong with HFS+ >> • File system changes in Lion >> • File system future >> • Document revisions >> • Resolution independence >> • Applications >> • The Finder >> • Mail >> • Safari >> • Grab bag >> • System Preferences >> • Auto-correction >> • Mobile Time Machine >> • Lock screen >> • Emoji >> • Terminal >> • About This Mac >> • Recommendations >> • Conclusion_ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev > smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23181: master branch updated
1. I like Robby's mode suggestion. 2. I prefer shorter keywords, e.g., define-judgment. 3. Why is this in github and not in the docs? On Aug 5, 2011, at 9:56 PM, Robby Findler wrote: > How about > > #:mode (sum I I O) > > for the mode spec where the #:mode keyword is optional but, if present must > be followed by what looks like a use of the relation but with a > Mode? > > Robby > > On Friday, August 5, 2011, Casey Klein wrote: > > On Fri, Aug 5, 2011 at 8:13 AM, wrote: > >> clklein has updated `master' from 1a65678924 to 576272362b. > >> http://git.racket-lang.org/plt/1a65678924..576272362b > >> > > > > This push adds a more general way to define relations in Redex, > > currently under the name define-judgment-form. For those of you > > familiar with the existing define-relation form, this new form lifts > > the restriction that relations have no outputs when executed. In > > particular, it lets you specify which positions are inputs and which > > are outputs, and it statically checks that the outputs can be computed > > from the inputs without "guessing" any intermediate values. > > > > Here's a simple example: > > > > (define-language nats > > (n z (s n))) > > > > (define-judgment-form nats > > mode : O O I > > sum ⊆ n × n × n > > [(sum z n n)] > > [(sum (s n_1) n_2 (s n_3)) > > (sum n_1 n_2 n_3)]) > > > >> (judgment-holds (sum (s (s z)) (s z) (s (s (s z) > > true > >> (judgment-holds (sum (s (s z)) (s z) (s (s z > > false > >> (judgment-holds (sum (s z) n (s (s z))) n) > > `((s z)) > >> (judgment-holds (sum n_1 n_2 (s (s z))) (n_1 n_2)) > > `(((s (s z)) z) ((s z) (s z)) (z (s (s z > > > > I see three use cases: > > > > 1. Defining type systems in a way that supports mechanized > > typesetting. Here's an example: > > > > https://gist.github.com/1128672 > > > > There are still plenty of type systems Redex can't express, but the > > new form gets a lot of low-hanging fruit. > > > > 2. Defining structural operational semantics in a way that supports > > mechanized typesetting. Here's an example: > > > > https://gist.github.com/1128685 > > > > Relations defined in this way don't work directly with traces. You can > > embed them in reduction-relation, as the example demonstrates, but you > > lose out on edge labels. It shouldn't be too difficult to rig up > > something better, if this turns out to be important. > > > > 3. Defining relations using something like multi-valued metafunctions. > > Here's an example in which (add1 e) may reduce to 0. > > > > https://gist.github.com/1128692 > > > > Any feedback is welcome, but I'm especially interested in opinions on > > two points: > > > > 1. Is there a better name than define-judgment-form? I would have > > liked the name define-relation, if it weren't already taken. Is it OK > > to overload it? > > > > 2. Should mode declarations use a different syntax? I tried to do > > something in the paren-free style of define-relation contracts, but I > > don't like the result -- partially because I personally like parens, > > partially because it makes it harder to give good error messages. > > > > _ > > For list-related administrative tasks: > > http://lists.racket-lang.org/listinfo/dev > > _ > 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] [plt] Push #23181: master branch updated
On Sat, Aug 6, 2011 at 8:43 AM, Matthias Felleisen wrote: > 3. Why is this in github and not in the docs? I think you're mistaken here. It is in the head on our git servers. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23181: master branch updated
On Sat, Aug 6, 2011 at 10:43 AM, Matthias Felleisen wrote: > > 1. I like Robby's mode suggestion. > 2. I prefer shorter keywords, e.g., define-judgment. I'm having trouble reconciling these comments. Robby's suggestion, if I understand it correctly, is to overload the `define-relation' name instead of choosing a new one. If you supply the #:mode keyword, you get the `define-judgment-form' behavior (inputs and outputs, static checking, the `judgment-holds' syntax for application); if not, you get the current `define-relation' behavior. Do you mean keep the forms separate but use the name `define-judgment' for the new one? I intentionally avoided that name because what it defines, for example `sum', is not itself a judgment. Judgments are uses of that thing, i.e., assertions about particular objects, for example (sum z z z). > 3. Why is this in github and not in the docs? > Oh, good idea! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23181: master branch updated
On Sat, Aug 6, 2011 at 1:53 PM, Casey Klein wrote: > On Sat, Aug 6, 2011 at 10:43 AM, Matthias Felleisen > wrote: >> >> 1. I like Robby's mode suggestion. >> 2. I prefer shorter keywords, e.g., define-judgment. > > I'm having trouble reconciling these comments. Robby's suggestion, if > I understand it correctly, is to overload the `define-relation' name > instead of choosing a new one. If you supply the #:mode keyword, you > get the `define-judgment-form' behavior (inputs and outputs, static > checking, the `judgment-holds' syntax for application); if not, you > get the current `define-relation' behavior. My suggestion was meant to be separate from the overloading thing. You could use a #:mode even for define-judgment. (Casey is referring to the idea that define-relation is kind of like define-judgment but where you have an all-output mode as the default.) > Do you mean keep the forms separate but use the name `define-judgment' > for the new one? I intentionally avoided that name because what it > defines, for example `sum', is not itself a judgment. Judgments are > uses of that thing, i.e., assertions about particular objects, for > example (sum z z z). > >> 3. Why is this in github and not in the docs? >> > > Oh, good idea! > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Search by example (was Re: Roogle?)
On 2011-08-05 12:13 AM, Robby Findler wrote:
> So I wonder if anyone has a positive experience with this kind of
> searching in an "in anger" kind of setting?
Not with search by type, but at the risk of derailing the thread, I have
had quite a few positive experiences with search by example.
For instance, many's the time I've been unable to remember the name of
the selector that tells me whether a string starts with some other
substring in Smalltalk. So I open the "method finder", and enter
'abcde'. 'abc'. true
for the first and second arguments and the expected result,
respectively, and start it ticking, and it answers with suggested
methods such as
'abc' < 'abcde' --> true
'abcde' > 'abc' --> true
'abcde' beginsWith: 'abc' --> true
'abcde' includesSubString: 'abc' --> true
and so on. See attached picture. Clicking on the "beginsWith:" entry in
the results shows me all the classes implementing that method, in a
list. Clicking on an entry of that list opens up the relevant source code.
It has been useful to me on more than one occasion (e.g. entering
"'cbabad'. $a. 2" gives #occurrencesOf:).
There's nothing magic about Smalltalk either. It's implemented as a
giant hackish crock rather than as anything remotely viewable as elegant
:-) The implementation simply has a list of "safe" methods that it runs
through in order, collecting non-erroring results that compare equal to
the expected output, which it then displays in a list.
Something similar could work for Racket. Useful for students and others
learning or transitioning to the language, perhaps.
You could even use contracts, perhaps: check each given argument against
the positional arguments of a candidate's contract, check the given
result; you don't even have to run the contracted procedure, which could
after all be dangerous, and thus you get to avoid some of the
crockishness of the Squeak implementation.
(You could also, in both Squeak's and this imagined Racket solution,
permit additional examples to be given to narrow the field after some
first candidate is found. #('abcde' 'xyz' false), for instance, for the
original example.)
Cheers,
Tony
<>_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23181: master branch updated
On Sat, Aug 6, 2011 at 1:58 PM, Robby Findler wrote: > On Sat, Aug 6, 2011 at 1:53 PM, Casey Klein > wrote: >> On Sat, Aug 6, 2011 at 10:43 AM, Matthias Felleisen >> wrote: >>> >>> 1. I like Robby's mode suggestion. >>> 2. I prefer shorter keywords, e.g., define-judgment. >> >> I'm having trouble reconciling these comments. Robby's suggestion, if >> I understand it correctly, is to overload the `define-relation' name >> instead of choosing a new one. If you supply the #:mode keyword, you >> get the `define-judgment-form' behavior (inputs and outputs, static >> checking, the `judgment-holds' syntax for application); if not, you >> get the current `define-relation' behavior. > > My suggestion was meant to be separate from the overloading thing. You > could use a #:mode even for define-judgment. > Oh, I see. I like that. How do you feel about using the same style for contracts? For example: (define-judgment-form nats #:mode (sum I I O) #:contract (sum n n n) [(sum z n n)] [(sum (s n_1) n_2 (s n_3)) (sum n_1 n_2 n_3)]) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Roogle?
On Thu, Aug 4, 2011 at 11:13 PM, Robby Findler wrote: > So I wonder if anyone has a > positive experience with this kind of searching in an "in anger" kind > of setting? > I've had positive experiences searching by type signature in Hoogle. I've wished I could do the same for the Racket docs every time I try to remember the name of the function with this signature: (a -> [b]) -> [a] -> [b]. It's the first result in Hoogle, even if you get the order of arguments backwards. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Search by example (was Re: Roogle?)
[Oops - forgot to reply to all.] To build a sketch of this, I've found module->exports, dynamic-require and friends, but I think I'd need procedures along the lines of function-contract? : any -> boolean function-contract-domain-contracts : function-contract? -> (listof contract?) function-contract-range-contracts : function-contract? -> (listof contract?) I see contract?, flat-contract? etc, but I don't see anything that could let me take apart a contract to use its pieces. Is there any such thing? (Also there are, as usual, interesting wrinkles with search-by-example with higher-order functions.) Regards, Tony On 2011-08-06 3:13 PM, Tony Garnock-Jones wrote: > Not with search by type, but at the risk of derailing the thread, I have > had quite a few positive experiences with search by example. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #23181: master branch updated
I like it. Robby On Sat, Aug 6, 2011 at 2:47 PM, Casey Klein wrote: > On Sat, Aug 6, 2011 at 1:58 PM, Robby Findler > wrote: >> On Sat, Aug 6, 2011 at 1:53 PM, Casey Klein >> wrote: >>> On Sat, Aug 6, 2011 at 10:43 AM, Matthias Felleisen >>> wrote: 1. I like Robby's mode suggestion. 2. I prefer shorter keywords, e.g., define-judgment. >>> >>> I'm having trouble reconciling these comments. Robby's suggestion, if >>> I understand it correctly, is to overload the `define-relation' name >>> instead of choosing a new one. If you supply the #:mode keyword, you >>> get the `define-judgment-form' behavior (inputs and outputs, static >>> checking, the `judgment-holds' syntax for application); if not, you >>> get the current `define-relation' behavior. >> >> My suggestion was meant to be separate from the overloading thing. You >> could use a #:mode even for define-judgment. >> > > Oh, I see. I like that. How do you feel about using the same style for > contracts? For example: > > (define-judgment-form nats > #:mode (sum I I O) > #:contract (sum n n n) > [(sum z n n)] > [(sum (s n_1) n_2 (s n_3)) > (sum n_1 n_2 n_3)]) > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Search by example (was Re: Roogle?)
There isn't a way to do that, no. But I think in Racket we have better ways of avoiding such danger (namely using the sandbox library or the pieces it builds upon). In general, in fact, you'd have to do that anyways, since a contract can be some arbitrary predicate (and don't forget do-dads like #:pre and friends). Robby On Sat, Aug 6, 2011 at 3:31 PM, Tony Garnock-Jones wrote: > [Oops - forgot to reply to all.] > > To build a sketch of this, I've found module->exports, dynamic-require > and friends, but I think I'd need procedures along the lines of > > function-contract? : any -> boolean > function-contract-domain-contracts : function-contract? -> > (listof contract?) > function-contract-range-contracts : function-contract? -> > (listof contract?) > > I see contract?, flat-contract? etc, but I don't see anything that could > let me take apart a contract to use its pieces. Is there any such thing? > > (Also there are, as usual, interesting wrinkles with search-by-example > with higher-order functions.) > > Regards, > Tony > > On 2011-08-06 3:13 PM, Tony Garnock-Jones wrote: >> Not with search by type, but at the risk of derailing the thread, I have >> had quite a few positive experiences with search by example. > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Search by example (was Re: Roogle?)
On 2011-08-06 4:41 PM, Robby Findler wrote: > But I think in Racket we have better ways of avoiding such danger > (namely using the sandbox library or the pieces it builds upon). In > general, in fact, you'd have to do that anyways, since a contract can > be some arbitrary predicate (and don't forget do-dads like #:pre and > friends). OK - so rather than using the contracts as a kind of executable documentation, just go ahead and try out each possibility in the sandbox? Not a bad approach. Tony _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Search by example (was Re: Roogle?)
Three hours ago, Tony Garnock-Jones wrote: > On 2011-08-06 4:41 PM, Robby Findler wrote: > > But I think in Racket we have better ways of avoiding such danger > > (namely using the sandbox library or the pieces it builds > > upon). In general, in fact, you'd have to do that anyways, since a > > contract can be some arbitrary predicate (and don't forget do-dads > > like #:pre and friends). > > OK - so rather than using the contracts as a kind of executable > documentation, just go ahead and try out each possibility in the > sandbox? Not a bad approach. This makes more sense. In some cases, the contracts would be implemented manually (eg, primitives), etc. So running it in a sandbox makes the most sense in terms of getting safe executions as well as limiting the time you wait for each try. *However*, there's an awful lot of functions to try -- going over them will make a very slow search... -- ((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] Search by example (was Re: Roogle?)
We've just got to figure out some clever caching/incrementalization thing and then get one of google's or amazon's or whoever's trucks to drive up and plug in somewhere. Sounds like a nice research project. Robby On Sat, Aug 6, 2011 at 7:25 PM, Eli Barzilay wrote: > Three hours ago, Tony Garnock-Jones wrote: >> On 2011-08-06 4:41 PM, Robby Findler wrote: >> > But I think in Racket we have better ways of avoiding such danger >> > (namely using the sandbox library or the pieces it builds >> > upon). In general, in fact, you'd have to do that anyways, since a >> > contract can be some arbitrary predicate (and don't forget do-dads >> > like #:pre and friends). >> >> OK - so rather than using the contracts as a kind of executable >> documentation, just go ahead and try out each possibility in the >> sandbox? Not a bad approach. > > This makes more sense. In some cases, the contracts would be > implemented manually (eg, primitives), etc. So running it in a > sandbox makes the most sense in terms of getting safe executions as > well as limiting the time you wait for each try. > > *However*, there's an awful lot of functions to try -- going over them > will make a very slow search... > > -- > ((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] Search by example (was Re: Roogle?)
Two minutes ago, Robby Findler wrote: > We've just got to figure out some clever caching/incrementalization > thing and then get one of google's or amazon's or whoever's trucks > to drive up and plug in somewhere. Sounds like a nice research > project. With caching up results it will be interesting if that helps, but if you get your hand on a server truck, you could just as well run them all in parallel. (BTW, `random' and `read' would also be problematic.) -- ((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] Search by example (was Re: Roogle?)
On Sat, Aug 6, 2011 at 7:30 PM, Eli Barzilay wrote: > Two minutes ago, Robby Findler wrote: >> We've just got to figure out some clever caching/incrementalization >> thing and then get one of google's or amazon's or whoever's trucks >> to drive up and plug in somewhere. Sounds like a nice research >> project. > > With caching up results it will be interesting if that helps, but if > you get your hand on a server truck, you could just as well run them > all in parallel. > > (BTW, `random' and `read' would also be problematic.) Lets just throw out state. Its too hard to program with anyways. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Search by example (was Re: Roogle?)
On 2011-08-06 8:25 PM, Eli Barzilay wrote: > *However*, there's an awful lot of functions to try -- going over them > will make a very slow search... There's not *that* many. How long does 100,000 function calls take? I'd imagine you'd search the exports from racket/base before looking further afield, as well. Tony _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Search by example (was Re: Roogle?)
Two minutes ago, Tony Garnock-Jones wrote: > On 2011-08-06 8:25 PM, Eli Barzilay wrote: > > *However*, there's an awful lot of functions to try -- going over > > them will make a very slow search... > > There's not *that* many. How long does 100,000 function calls take? Not much, but: * Just loading the code will take some significant time. * Some calls will inevitably need to be rejected on the basis of a timeout. (For example, imagine (sleep 10).) If there are many of these, things become slow again. (Oh, and BTW, gui functionality will be interesting too.) > I'd imagine you'd search the exports from racket/base before looking > further afield, as well. If you restrict the search for only these, then things are definitely much more practical. -- ((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
