Re: [racket-dev] make & --clone installed pkgs
On Feb 17, 2015, at 7:59 PM, Sam Tobin-Hochstadt wrote: > I expect that the packages that update for Matthias on `make` are > packages in "main-distribution", Personally, I have used the 'same' one-line command going back to csv through svn and now git (_update). When I write "Speaking as the user I am .." I am thinking of people like me. Then again, you're probably saying that I am the bottom element of the lattice of make/update knowledge, so never mind what I write. -- Matthias -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/8DB5B81F-1701-411E-8E2D-0546904BA960%40ccs.neu.edu. For more options, visit https://groups.google.com/d/optout.
Re: [racket-dev] make & --clone installed pkgs
On Feb 17, 2015, at 2:12 PM, Sam Tobin-Hochstadt wrote: > Regardless of that, though, I think we should switch to updating only > "main-distribution" (and perhaps "main-distribution-tests"). I doubt > people expect `make` in the Racket source tree to update their > software somewhere else on their machine -- I certainly would be very > unpleasantly surprised if that happened to me when rebuilding some > other language I had installed. Speaking as the user I am, I really like it that make updates my extra-pkgs. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/357EA559-01FF-40AD-B670-D3765E0C72C1%40ccs.neu.edu. For more options, visit https://groups.google.com/d/optout.
Re: [racket-dev] What is the policy on what is included in the core libraries?
(I was thinking dissertations.) On Feb 17, 2015, at 2:47 PM, Dan Burton wrote: > Matthias, when you say "At some point TR will move on," what do you mean by > that? I, for one, would like to see TR more tightly integrated with regular > racket a la progressive types, rather than branching off into its own arena. > > On Tuesday, February 17, 2015, Matthias Felleisen > wrote: > > At some point TR will move on, and perhaps the time has come. > > > On Feb 17, 2015, at 12:06 PM, Vincent St-Amour wrote: > > > I don't think we should add functions to TR that are not in Racket and > > that are not clearly type-related (e.g., `cast`). > > > > I also like Jens's solution better. Education vs crutches. > > > > Vincent > > > > > > > > At Tue, 17 Feb 2015 10:39:16 -0500, > > Matthias Felleisen wrote: > >> > >> > >> I'd add them to Typed Racket. That's what Haskellians are most likely to > >> explore and when they find them, it's a good thing (tm). -- Matthias > >> > >> > >> > >> > >> On Feb 17, 2015, at 2:18 AM, Alexis King wrote: > >> > >>> I was just thinking today that I would, for example, find it useful to > >>> have a (zip ...) function in racket/list that would be equivalent to (map > >>> list ...). Users coming from a Haskell background might even find it > >>> useful to have a zip-with function that is simply an alias for map. > >>> Admittedly, these are rather trivial, but (especially in the first case) > >>> I think they’d still be useful. > >>> > >>> I am all for avoiding feature creep and code bloat, but Racket’s > >>> “batteries included” approach seems to make functions like these prime > >>> candidates for libraries like racket/list. As long as they’re not in > >>> racket/base, they seem fairly harmless, especially considering they would > >>> only be needed at compile-time. > >>> > >>> Should I even consider adding things like this, or is the consensus that > >>> the libraries are mostly sufficient as-is? > >>> > >>> -- > >>> You received this message because you are subscribed to the Google Groups > >>> "Racket Developers" group. > >>> To unsubscribe from this group and stop receiving emails from it, send an > >>> email to racket-dev+unsubscr...@googlegroups.com. > >>> To post to this group, send email to racket-...@googlegroups.com. > >>> To view this discussion on the web visit > >>> https://groups.google.com/d/msgid/racket-dev/5D941DB1-8A55-4A41-98A2-A3BE1BFE6D40%40gmail.com. > >>> For more options, visit https://groups.google.com/d/optout. > >> > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Racket Developers" group. > >> To unsubscribe from this group and stop receiving emails from it, send an > >> email to racket-dev+unsubscr...@googlegroups.com. > >> To post to this group, send email to racket-...@googlegroups.com. > >> To view this discussion on the web visit > >> https://groups.google.com/d/msgid/racket-dev/EAAD5B93-DB78-419B-A662-131AD1D3E303%40ccs.neu.edu. > >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-dev+unsubscr...@googlegroups.com. > To post to this group, send email to racket-...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-dev/63C7696A-1532-400A-825D-247BB3E31750%40ccs.neu.edu. > For more options, visit https://groups.google.com/d/optout. > > > -- > -- Dan Burton -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/31B41614-950F-49D8-AB81-D237FD917DB3%40ccs.neu.edu. For more options, visit https://groups.google.com/d/optout.
Re: [racket-dev] What is the policy on what is included in the core libraries?
At some point TR will move on, and perhaps the time has come. On Feb 17, 2015, at 12:06 PM, Vincent St-Amour wrote: > I don't think we should add functions to TR that are not in Racket and > that are not clearly type-related (e.g., `cast`). > > I also like Jens's solution better. Education vs crutches. > > Vincent > > > > At Tue, 17 Feb 2015 10:39:16 -0500, > Matthias Felleisen wrote: >> >> >> I'd add them to Typed Racket. That's what Haskellians are most likely to >> explore and when they find them, it's a good thing (tm). -- Matthias >> >> >> >> >> On Feb 17, 2015, at 2:18 AM, Alexis King wrote: >> >>> I was just thinking today that I would, for example, find it useful to have >>> a (zip ...) function in racket/list that would be equivalent to (map list >>> ...). Users coming from a Haskell background might even find it useful to >>> have a zip-with function that is simply an alias for map. Admittedly, these >>> are rather trivial, but (especially in the first case) I think they’d still >>> be useful. >>> >>> I am all for avoiding feature creep and code bloat, but Racket’s “batteries >>> included” approach seems to make functions like these prime candidates for >>> libraries like racket/list. As long as they’re not in racket/base, they >>> seem fairly harmless, especially considering they would only be needed at >>> compile-time. >>> >>> Should I even consider adding things like this, or is the consensus that >>> the libraries are mostly sufficient as-is? >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Racket Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to racket-dev+unsubscr...@googlegroups.com. >>> To post to this group, send email to racket-...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/racket-dev/5D941DB1-8A55-4A41-98A2-A3BE1BFE6D40%40gmail.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Racket Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to racket-dev+unsubscr...@googlegroups.com. >> To post to this group, send email to racket-...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-dev/EAAD5B93-DB78-419B-A662-131AD1D3E303%40ccs.neu.edu. >> For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/63C7696A-1532-400A-825D-247BB3E31750%40ccs.neu.edu. For more options, visit https://groups.google.com/d/optout.
Re: [racket-dev] What is the policy on what is included in the core libraries?
I'd add them to Typed Racket. That's what Haskellians are most likely to explore and when they find them, it's a good thing (tm). -- Matthias On Feb 17, 2015, at 2:18 AM, Alexis King wrote: > I was just thinking today that I would, for example, find it useful to have a > (zip ...) function in racket/list that would be equivalent to (map list ...). > Users coming from a Haskell background might even find it useful to have a > zip-with function that is simply an alias for map. Admittedly, these are > rather trivial, but (especially in the first case) I think they’d still be > useful. > > I am all for avoiding feature creep and code bloat, but Racket’s “batteries > included” approach seems to make functions like these prime candidates for > libraries like racket/list. As long as they’re not in racket/base, they seem > fairly harmless, especially considering they would only be needed at > compile-time. > > Should I even consider adding things like this, or is the consensus that the > libraries are mostly sufficient as-is? > > -- > You received this message because you are subscribed to the Google Groups > "Racket Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-dev+unsubscr...@googlegroups.com. > To post to this group, send email to racket-...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-dev/5D941DB1-8A55-4A41-98A2-A3BE1BFE6D40%40gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/EAAD5B93-DB78-419B-A662-131AD1D3E303%40ccs.neu.edu. For more options, visit https://groups.google.com/d/optout.
Re: [racket-dev] Full transparency
Sounds like a straightforward change to the existing macros. Why don't you create a fork and experiment? On Jan 21, 2015, at 1:15 PM, Byron Davies wrote: > Or, more conservatively, every struct and object in a given package, file, or > set of files. > > On Wed, Jan 21, 2015 at 11:03 AM, Byron Davies > wrote: > Would it be easy to create a compiler flag that would make every struct and > object transparent? This would then make it easy to create a Lisp > Machine-style Inspector that would be able to roam through every data > structure during debugging. > > Byron > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Announcing Soft Contract Verification tool
Argh, I wanted the other way (negative). I always get the directions confused. Sorry. On Jan 15, 2015, at 11:26 AM, David Van Horn wrote: > On 1/15/15, 11:17 AM, Matthias Felleisen wrote: >> >> >> On Jan 15, 2015, at 11:13 AM, David Van Horn >> wrote: >> >>> On 1/15/15, 11:04 AM, Matthias Felleisen wrote: >>>> >>>> Well that got me all excited. So I tried to get the sample >>>> module to pass the verification step -- until I realized how >>>> restricted the grammar is! >>>> >>>> (module f racket (provide (contract-out [f (real? . -> . >>>> integer?)])) (define (f n) (/ 1 (- 100 n >>>> >>>> I would love to be able to use at least (and/c real? (>/c 0)) >>>> for the domain so I can get the example done. >>>> >>>> Or am I overlooking a way to make this work here? >>> >>> The >/c contract is there, but missing from the grammar (we'll >>> fix that). >>> >>> But (>/c 0) will not make this program verify. You want this >>> contract: >>> >>> ((and/c real? (lambda (x) (not (= x 100 . -> . real?) >>> >>> Using this contract, the program verifies. >> >> >> My contract is stronger than yours. So why will it not go through? >> >> > > 100 is (>/c 0) but (f 100) divides by zero. > > David > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Announcing Soft Contract Verification tool
On Jan 15, 2015, at 11:13 AM, David Van Horn wrote: > On 1/15/15, 11:04 AM, Matthias Felleisen wrote: >> >> Well that got me all excited. So I tried to get the sample module >> to pass the verification step -- until I realized how restricted >> the grammar is! >> >> (module f racket (provide (contract-out [f (real? . -> . >> integer?)])) (define (f n) (/ 1 (- 100 n >> >> I would love to be able to use at least (and/c real? (>/c 0)) for >> the domain so I can get the example done. >> >> Or am I overlooking a way to make this work here? > > The >/c contract is there, but missing from the grammar (we'll fix that). > > But (>/c 0) will not make this program verify. You want this contract: > > ((and/c real? (lambda (x) (not (= x 100 . -> . real?) > > Using this contract, the program verifies. My contract is stronger than yours. So why will it not go through? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Announcing Soft Contract Verification tool
Well that got me all excited. So I tried to get the sample module to pass the verification step -- until I realized how restricted the grammar is! (module f racket (provide (contract-out [f (real? . -> . integer?)])) (define (f n) (/ 1 (- 100 n I would love to be able to use at least (and/c real? (>/c 0)) for the domain so I can get the example done. Or am I overlooking a way to make this work here? On Jan 14, 2015, at 7:11 PM, David Van Horn wrote: > Racketeers, > > Over the last year, we've been working on a tool for automatically > verifying that programs live up to their contracts. We're happy to > announce that it's now available for people to try out here: > > http://scv.umiacs.umd.edu > > You type in some modules in the editor, and click either Run or > Verify. The Verify button uses our tool to determine if the modules > always live up to their contract, and if they don't, it automatically > generates a counterexample, showing how to break the module. There are > a number of examples that you can play with, accessed via a menu on > the site. > > Right now, the tool supports a fixed subset of Racket, but we're > working on making it handle much more by analyzing fully-expanded > programs. > > There's explanations on the site to go along with each example > program, and there's an "About" page with more info, and links to our > papers about the work, at http://scv.umiacs.umd.edu/about > > We plan to release a command-line tool and a DrRacket plugin in the > future, once we can handle more of Racket. > > If you have questions, comments, bugs, or any other feedback, let us > know, or just file bug reports on the GitHub source code. > > Phil, David, Sam > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] pushing to new repos
Which leaves me with the problem that I can't submit. On Jan 11, 2015, at 7:57 PM, Matthias Felleisen wrote: > > [[ completely off-topic and not that I really care but why does github think > I started contributing to htdp in 2010: > > https://github.com/racket/htdp/graphs/contributors ]] > > > > > > On Jan 11, 2015, at 7:55 PM, Matthias Felleisen wrote: > >> >>> [:~/plt/extra-pkgs/htdp] matthias% hub remote add -p racket/htdp >>> [:~/plt/extra-pkgs/htdp] matthias% git push >>> error: The requested URL returned error: 403 while accessing >>> https://github.com/racket/htdp.git/info/refs >>> >>> fatal: HTTP request failed >> >> >> >> >> >> >> On Jan 11, 2015, at 7:54 PM, Sam Tobin-Hochstadt wrote: >> >>> You seem to be using hub from the directory you checked out hub in, not the >>> htdp directory. >>> >>> Sam >>> >>> >>> On Sun, Jan 11, 2015, 7:40 PM Matthias Felleisen >>> wrote: >>> >>> Sorry I am late to the party but how do I push to the new repos: >>> >>> I tried >>> >>> ** Asumu's method: >>> >>> >>> > [:~/Hub/Hub] matthias% hub remote add -p racket/htdp >>> > [:~/Hub/Hub] matthias% git push >>> > error: The requested URL returned error: 403 while accessing >>> > https://github.com/github/hub.git/info/refs >>> > >>> > fatal: HTTP request failed >>> >>> >>> >>> ** Sam's method: >>> >>> >>> > [:~/Hub/Hub] matthias% hub remote add -p racket/htdp >>> > [:~/Hub/Hub] matthias% git push >>> > error: The requested URL returned error: 403 while accessing >>> > https://github.com/github/hub.git/info/refs >>> > >>> > fatal: HTTP request failed >>> >>> ** and a plain push: >>> >>> > [:htdp/htdp-lib/2htdp] matthias% git push >>> > fatal: remote error: >>> > You can't push to git://github.com/racket/htdp.git >>> > Use https://github.com/racket/htdp.git >>> >>> >>> To no avail. Hints appreciated -- Matthias >>> >>> >>> >>> Sam wrote a long time ago: >>> >>> > I think this is the case for everyone. >>> > >>> > I've used the `hub` [1] tool to address this. Once I have a checkout, >>> > if I need to push, I do: >>> > >>> >$ hub remote add -p racket/typed-racket >>> > >>> > and then >>> > >>> >$ git push racket >>> > >>> > Having an option to `raco pkg update` and `raco pkg install` to use >>> > the corresponding ssh URL for `--clone` would be nice, though, and I >>> > think it should be pretty easy to add. :) >>> > >>> > Sam >>> > >>> > On Tue, Dec 16, 2014 at 4:42 PM, Asumu Takikawa wrote: >>> > Hi all, >>> > >>> > I've been trying to adjust to the new package-split workflow now and >>> > I've bumped into a small usability problem and I wanted to see if anyone >>> > else has encountered this or if my config is just broken somehow. >>> > >>> > On a fresh build of Racket, if I do the following: >>> > raco pkg update --clone typed-racket >>> > >>> > it will install TR from github and reinstall. An excerpt from the config >>> > for that git repo looks like this: >>> > >>> > [remote "origin"] >>> > url = git://github.com/racket/typed-racket/ >>> > >>> > The problem is that this URL is not as useful as it could be because >>> > github won't let you push to it (at least I can't seem to). The >>> > corresponding SSH URL "g...@github.com:racket/typed-racket.git" lets me >>> > push. >>> > >>> > Is this something other people have encountered or is there some git >>> > config that I should fix on my end? >>> > >>> > FWIW, I have just been doing "git remote set-url origin >> > error message>" and it has worked well and been easy. >>> > >>> >>> _ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev >> >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] pushing to new repos
[[ completely off-topic and not that I really care but why does github think I started contributing to htdp in 2010: https://github.com/racket/htdp/graphs/contributors ]] On Jan 11, 2015, at 7:55 PM, Matthias Felleisen wrote: > >> [:~/plt/extra-pkgs/htdp] matthias% hub remote add -p racket/htdp >> [:~/plt/extra-pkgs/htdp] matthias% git push >> error: The requested URL returned error: 403 while accessing >> https://github.com/racket/htdp.git/info/refs >> >> fatal: HTTP request failed > > > > > > > On Jan 11, 2015, at 7:54 PM, Sam Tobin-Hochstadt wrote: > >> You seem to be using hub from the directory you checked out hub in, not the >> htdp directory. >> >> Sam >> >> >> On Sun, Jan 11, 2015, 7:40 PM Matthias Felleisen >> wrote: >> >> Sorry I am late to the party but how do I push to the new repos: >> >> I tried >> >> ** Asumu's method: >> >> >> > [:~/Hub/Hub] matthias% hub remote add -p racket/htdp >> > [:~/Hub/Hub] matthias% git push >> > error: The requested URL returned error: 403 while accessing >> > https://github.com/github/hub.git/info/refs >> > >> > fatal: HTTP request failed >> >> >> >> ** Sam's method: >> >> >> > [:~/Hub/Hub] matthias% hub remote add -p racket/htdp >> > [:~/Hub/Hub] matthias% git push >> > error: The requested URL returned error: 403 while accessing >> > https://github.com/github/hub.git/info/refs >> > >> > fatal: HTTP request failed >> >> ** and a plain push: >> >> > [:htdp/htdp-lib/2htdp] matthias% git push >> > fatal: remote error: >> > You can't push to git://github.com/racket/htdp.git >> > Use https://github.com/racket/htdp.git >> >> >> To no avail. Hints appreciated -- Matthias >> >> >> >> Sam wrote a long time ago: >> >> > I think this is the case for everyone. >> > >> > I've used the `hub` [1] tool to address this. Once I have a checkout, >> > if I need to push, I do: >> > >> >$ hub remote add -p racket/typed-racket >> > >> > and then >> > >> >$ git push racket >> > >> > Having an option to `raco pkg update` and `raco pkg install` to use >> > the corresponding ssh URL for `--clone` would be nice, though, and I >> > think it should be pretty easy to add. :) >> > >> > Sam >> > >> > On Tue, Dec 16, 2014 at 4:42 PM, Asumu Takikawa wrote: >> > Hi all, >> > >> > I've been trying to adjust to the new package-split workflow now and >> > I've bumped into a small usability problem and I wanted to see if anyone >> > else has encountered this or if my config is just broken somehow. >> > >> > On a fresh build of Racket, if I do the following: >> > raco pkg update --clone typed-racket >> > >> > it will install TR from github and reinstall. An excerpt from the config >> > for that git repo looks like this: >> > >> > [remote "origin"] >> > url = git://github.com/racket/typed-racket/ >> > >> > The problem is that this URL is not as useful as it could be because >> > github won't let you push to it (at least I can't seem to). The >> > corresponding SSH URL "g...@github.com:racket/typed-racket.git" lets me >> > push. >> > >> > Is this something other people have encountered or is there some git >> > config that I should fix on my end? >> > >> > FWIW, I have just been doing "git remote set-url origin > > error message>" and it has worked well and been easy. >> > >> >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] pushing to new repos
> [:~/plt/extra-pkgs/htdp] matthias% hub remote add -p racket/htdp > [:~/plt/extra-pkgs/htdp] matthias% git push > error: The requested URL returned error: 403 while accessing > https://github.com/racket/htdp.git/info/refs > > fatal: HTTP request failed On Jan 11, 2015, at 7:54 PM, Sam Tobin-Hochstadt wrote: > You seem to be using hub from the directory you checked out hub in, not the > htdp directory. > > Sam > > > On Sun, Jan 11, 2015, 7:40 PM Matthias Felleisen wrote: > > Sorry I am late to the party but how do I push to the new repos: > > I tried > > ** Asumu's method: > > > > [:~/Hub/Hub] matthias% hub remote add -p racket/htdp > > [:~/Hub/Hub] matthias% git push > > error: The requested URL returned error: 403 while accessing > > https://github.com/github/hub.git/info/refs > > > > fatal: HTTP request failed > > > > ** Sam's method: > > > > [:~/Hub/Hub] matthias% hub remote add -p racket/htdp > > [:~/Hub/Hub] matthias% git push > > error: The requested URL returned error: 403 while accessing > > https://github.com/github/hub.git/info/refs > > > > fatal: HTTP request failed > > ** and a plain push: > > > [:htdp/htdp-lib/2htdp] matthias% git push > > fatal: remote error: > > You can't push to git://github.com/racket/htdp.git > > Use https://github.com/racket/htdp.git > > > To no avail. Hints appreciated -- Matthias > > > > Sam wrote a long time ago: > > > I think this is the case for everyone. > > > > I've used the `hub` [1] tool to address this. Once I have a checkout, > > if I need to push, I do: > > > >$ hub remote add -p racket/typed-racket > > > > and then > > > >$ git push racket > > > > Having an option to `raco pkg update` and `raco pkg install` to use > > the corresponding ssh URL for `--clone` would be nice, though, and I > > think it should be pretty easy to add. :) > > > > Sam > > > > On Tue, Dec 16, 2014 at 4:42 PM, Asumu Takikawa wrote: > > Hi all, > > > > I've been trying to adjust to the new package-split workflow now and > > I've bumped into a small usability problem and I wanted to see if anyone > > else has encountered this or if my config is just broken somehow. > > > > On a fresh build of Racket, if I do the following: > > raco pkg update --clone typed-racket > > > > it will install TR from github and reinstall. An excerpt from the config > > for that git repo looks like this: > > > > [remote "origin"] > > url = git://github.com/racket/typed-racket/ > > > > The problem is that this URL is not as useful as it could be because > > github won't let you push to it (at least I can't seem to). The > > corresponding SSH URL "g...@github.com:racket/typed-racket.git" lets me > > push. > > > > Is this something other people have encountered or is there some git > > config that I should fix on my end? > > > > FWIW, I have just been doing "git remote set-url origin > error message>" and it has worked well and been easy. > > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] pushing to new repos
Sorry I am late to the party but how do I push to the new repos: I tried ** Asumu's method: > [:~/Hub/Hub] matthias% hub remote add -p racket/htdp > [:~/Hub/Hub] matthias% git push > error: The requested URL returned error: 403 while accessing > https://github.com/github/hub.git/info/refs > > fatal: HTTP request failed ** Sam's method: > [:~/Hub/Hub] matthias% hub remote add -p racket/htdp > [:~/Hub/Hub] matthias% git push > error: The requested URL returned error: 403 while accessing > https://github.com/github/hub.git/info/refs > > fatal: HTTP request failed ** and a plain push: > [:htdp/htdp-lib/2htdp] matthias% git push > fatal: remote error: > You can't push to git://github.com/racket/htdp.git > Use https://github.com/racket/htdp.git To no avail. Hints appreciated -- Matthias Sam wrote a long time ago: > I think this is the case for everyone. > > I've used the `hub` [1] tool to address this. Once I have a checkout, > if I need to push, I do: > >$ hub remote add -p racket/typed-racket > > and then > >$ git push racket > > Having an option to `raco pkg update` and `raco pkg install` to use > the corresponding ssh URL for `--clone` would be nice, though, and I > think it should be pretty easy to add. :) > > Sam > > On Tue, Dec 16, 2014 at 4:42 PM, Asumu Takikawa wrote: > Hi all, > > I've been trying to adjust to the new package-split workflow now and > I've bumped into a small usability problem and I wanted to see if anyone > else has encountered this or if my config is just broken somehow. > > On a fresh build of Racket, if I do the following: > raco pkg update --clone typed-racket > > it will install TR from github and reinstall. An excerpt from the config > for that git repo looks like this: > > [remote "origin"] > url = git://github.com/racket/typed-racket/ > > The problem is that this URL is not as useful as it could be because > github won't let you push to it (at least I can't seem to). The > corresponding SSH URL "g...@github.com:racket/typed-racket.git" lets me > push. > > Is this something other people have encountered or is there some git > config that I should fix on my end? > > FWIW, I have just been doing "git remote set-url origin error message>" and it has worked well and been easy. > _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Racket Winter Release
Dear Racket users, Happy New Year. As you may know, we split the Git repo for the core last year. We have been working on re-creating the release process for this new organization. Our plan is to (1) skip our normal Jan/Feb release cycle (2) test-run the release process during this cycle instead (3) resume our regular release rhythm this spring. Thanks for your patience. Matthew, Robby, Sam, Ryan, Jay, and Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Fwd: [ACM-BULLETIN] Today's Topic: ACM Names 2014 Distinguished Members
Even the ACM considers our very own Matthew Flatt as a distinguished scientist. -- Matthias Begin forwarded message: > From: ACM Bulletin > Subject: [ACM-BULLETIN] Today's Topic: ACM Names 2014 Distinguished Members > Date: December 4, 2014 11:04:44 AM EST > To: acm-bulle...@listserv.acm.org > Reply-To: acmbulle...@acm.org > > > Today's Topic: ACM Names 2014 Distinguished Members > > Thursday, December 4, 2014 > ACM has named 49 Distinguished Members for their individual contributions and > their singular impacts on the vital field of computing. Their achievements > have had a significant influence on the social, economic and cultural areas > of daily lives all over the world. The 2014 Distinguished Members are from > universities in Austria, Germany, Switzerland, Netherlands, Sweden, Japan, > India, the United Kingdom and North America, and from leading international > corporations and research institutions. > > ACM President Alexander Wolf hailed these ACM members as "drivers of the > advances and inventions that are propelling the information revolution in new > directions. Their creativity and commitment to their craft ensures that we > will benefit as a society in the digital age." He added that these innovators > "demonstrate the advantages of ACM membership, which empowers and inspires a > bold vision for advancing computing and the computing community." > > The ACM Distinguished Member program can recognize the top 10 percent of ACM > worldwide membership based on professional experience as well as significant > achievements in the computing field. > > news release. > > > > Connect with us: > > > > > > To unsubscribe: Enter your email address > > matth...@ccs.neu.edu > Association for Computing Machinery > Advancing Computing as a Science & Profession > > © 2014 ACM, Inc. > All rights reserved > > To unsubscribe from the ACM-BULLETIN list: > > write to: acm-bulletin-signoff-requ...@listserv.acm.org or click the > following link: > http://listserv.acm.org/SCRIPTS/WA-ACMLPX.CGI?SUBED1=ACM-BULLETIN&A=1 All > rights reserved © 2014 ACM, Inc. > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] The repository is now split
For those of you who have my level of experience with such things, here is what Sam's phrase "I *highly* recommend creating a new clone of the repository, and re-running `make`." means, for your value of the name 'plt2': $ git clone git:plt plt2 $ cd plt2/ $ git submodule init $ git submodule update $ make > > On Dec 4, 2014, at 10:51 AM, Sam Tobin-Hochstadt wrote: > >> I've just push a change to the plt repository that removes almost all >> the packages. >> >> The split repositories are all in the `racket` organization on GitHub. >> You can see them here: https://github.com/racket/ >> >> I *highly* recommend creating a new clone of the repository, and >> re-running `make`. This will install all of the packages in >> "main-distribution" and "main-distribution-test" from the package >> catalog. >> >> There are a number of problems with the current Makefile setup, which >> we're working on fixing, but which you'll need to know about for a >> little while (hopefully not more than today). >> >> * If you specify an explicit set of PKGS on the `make` command line, >> that will NOT work. >> * If you have user-installed Planet packages, there may be errors. >> >> If you encounter other errors, please let me know, either by replying >> or by finding me on IRC. >> >> If you run `make` and then you want to edit and commit to a package >> such as "rackunit", run the following commands inside your git >> checkout: >> >> $ mkdir extra-pkgs >> $ cd extra-pkgs >> $ raco pkg update --clone rackunit >> >> That will create a git checkout in the extra-pkgs/rackunit directory. >> The `extra-pkgs` directory is set up to be ignored by the top-level >> git checkout, so it's a good place to put package checkouts. >> >> This will almost certainly break our continuous integration systems >> for a little while, but I'm working to get that fixed. >> >> Everyone should feel free to commit to the split repositories or to >> the main repository at this point -- we do not plan any git surgery >> that would be harmed by that. >> >> I'd especially like to thank Jay and Matthew for working hard to help >> with this, including fixing things I've broken. :) >> >> Sam >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] The repository is now split
Is this the expected behavior: > $ git clone git:plt plt2 > $ cd plt2/ > $ make ... > raco setup: --- post-installing collections --- > raco setup: --- checking package dependencies --- > make install-common-last > make fix-paths > if [ "" != "" ]; then \ > if [ "" = "" ]; then \ > racket/racketcgc -G /Users/matthias/plt2/build/config -u \ > "../../collects/setup/unixstyle-install.rkt" \ > make-install-destdir-fix "../.." \ > "/Users/matthias/plt2/racket/bin" > "/Users/matthias/plt2/racket/collects" "/Users/matthias/plt2/racket/doc" > "/Users/matthias/plt2/racket/lib" "/Users/matthias/plt2/racket/include" > "/Users/matthias/plt2/racket/lib" "/Users/matthias/plt2/racket/share" > "/Users/matthias/plt2/racket/etc" > "/Users/matthias/plt2/racket/share/applications" > "/Users/matthias/plt2/racket/man" "yes"; \ > fi \ > fi > make preserve-raco-pkg-default-scope > : > cp "../COPYING-libscheme.txt" "../COPYING_LESSER.txt" "../COPYING.txt" > "/Users/matthias/plt2/racket/share"/ > if racket/bin/racket -G build/config -I racket/base -e '(case (system-type) > [(macosx) (exit 0)] [else (exit 1)])' ; then make native-from-git ; fi > if [ ! -d native-pkgs/racket-win32-i386 ]; then make complain-no-submodule ; > fi > : > : Native packages are not in the expected subdirectory. Probably, > : you need to use 'git submodule init' and 'git submodule update' to get > : the submodule for native packages. > : > exit 1 > make[3]: *** [complain-no-submodule] Error 1 > make[2]: *** [native-from-git] Error 2 > make[1]: *** [plain-in-place] Error 2 > make: *** [in-place] Error 2 > [:~/plt2] matthias% On Dec 4, 2014, at 10:51 AM, Sam Tobin-Hochstadt wrote: > I've just push a change to the plt repository that removes almost all > the packages. > > The split repositories are all in the `racket` organization on GitHub. > You can see them here: https://github.com/racket/ > > I *highly* recommend creating a new clone of the repository, and > re-running `make`. This will install all of the packages in > "main-distribution" and "main-distribution-test" from the package > catalog. > > There are a number of problems with the current Makefile setup, which > we're working on fixing, but which you'll need to know about for a > little while (hopefully not more than today). > > * If you specify an explicit set of PKGS on the `make` command line, > that will NOT work. > * If you have user-installed Planet packages, there may be errors. > > If you encounter other errors, please let me know, either by replying > or by finding me on IRC. > > If you run `make` and then you want to edit and commit to a package > such as "rackunit", run the following commands inside your git > checkout: > > $ mkdir extra-pkgs > $ cd extra-pkgs > $ raco pkg update --clone rackunit > > That will create a git checkout in the extra-pkgs/rackunit directory. > The `extra-pkgs` directory is set up to be ignored by the top-level > git checkout, so it's a good place to put package checkouts. > > This will almost certainly break our continuous integration systems > for a little while, but I'm working to get that fixed. > > Everyone should feel free to commit to the split repositories or to > the main repository at this point -- we do not plan any git surgery > that would be harmed by that. > > I'd especially like to thank Jay and Matthew for working hard to help > with this, including fixing things I've broken. :) > > Sam > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new package system collections and conflicts
Thanks for being with with us for so long. I think you misunderstood the word 'charity' here and perhaps Jay could have used a different, a more appropriate word than 'charity', which I now realize can have a negative connotation. Otherwise, I think that the package system design is about reducing power for core developers so that we put ourselves into the position of contributors. Our hope is that this step will eventually improve the overall social/eco system surrounding Racket. Please stay with us, and please do give constructive feedback. The most constructive feedback is of the form "I would like to solve the problem ... describe problem ..". We have been thinking for a long, long time about breaking up the core so that more people can become "core" and we realize that this is a nontrivial step. We need your helps and everyone's help. Thanks! -- Matthias On Dec 3, 2014, at 11:32 AM, Neil Van Dyke wrote: > I don't think I need charity. > > I thought the vision for the new package system had already been explained > adequately. I would be very interested to learn how the model is well-suited > to third-party developers like me. > > But -- I mean this constructively -- I'd be happy if someone simply came out > and said "this model is great for core developers, we still have to figure > out everyone else, and maybe the model isn't great for everyone else". The > reason is that I've looked at the new package system seriously 5-6 times > since it was announced, and I keep being told that the model is intended for > non-core people like me, and that someone else knows my needs better than me. > Open source reuse was an especial area of interest to me, the package system > is very important, and I've given the benefit of the doubt 5-6 times now. > (This has actually stalled most of my public Racket work, one way or another, > for about 2 years.) > > I'm not harshing on Racket; just on how the new package system was sprung on > non-core people, and the narrative. It doesn't look typical of Racket. > Racket is usually in the position that it could say "we have a better idea" > (on, e.g., module system sophistication, various syntax extension mechanisms > and mixed languages support, various aspects of DrRacket, the related > pedagogic projects, etc.), and usually that doesn't have to be said, because > the superiority of Racket is immediately apparent. That's why I've been a > Racketeer for 13 years and counting. > > Neil V. > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] meeting notes, November 2014
Every few months, the principals of the Racket world meet for a day to discuss the state and near (and, occasionally, distant) future of the Racket world. We met this past weekend in Chicago, and here is the list of major points we discussed. 1. We will split the central Racket repo so that every directory in the pkgs/ directory -- i.e. every major package -- will each get its own repo. [The *-lib, *-doc, *-test packages will be kept together.] The process will start with packages that no/few other packages depend on so that we can test the idea on an incremental basis. Once the repository is split, we plan to migrate the existing bug database to GitHub, splitting it along the same lines as the repository. As we split the repos, we will improve the infrastructure so that not only core packages but all ring-0 packages are tested on drdr on a per commit basis; see http://drdr.racket-lang.org . Similarly, we are hoping to improve our search service so that searching for functionality includes all packages not just the ones included with a specific bundle. The primary intention is to put core developers and package developers on roughly the same footing. A secondary intention is to facilitate the creation of targeted download bundles, e.g., for specific sites with particular security needs or for books with special language and library needs. 2. The download site will make use of this last point after the split. It will then offer three different kinds of packages: -- one minimal bundle, for just Racket -- one graphical bundle, including the Racket IDE -- several 'book' bundles, covering for example DeinProgram, EOPL, HtDP, PLAI, PP, Realm, Redex This step simultaneously thins out our all-in-one bundle and promotes Racket-related works. 3. We will improve the package site in two ways. First we will upgrade the cloud service and determine how much it will improve the reliability of the server (whose memory and cpu needs spike at certain points and thus reach the limits of the low level of services we rent). Second, we will collaborate with Tony Garnock-Jones to improve the UI experience based on the latter's prototype. 4. We discussed the issue of backwards compatibility, and we will continue to think how to balance it with other needs of our user base. 5. Finally, we want to explore the possibility of donating directly to the Racket project. Thus far, some of us have paid for PLT Design, Inc, web sites, and web services out of pocket. To have funds for additional services or upgrading the services for improved experiences, additional funding would be welcome. To support donors who may wish to receive a tax deduction, we need to investigate forwarding organizations, such as the Software Conservancy, that comply with the US Tax code (so-called 501 c(3) organizations). -- Jay, Matthew, Robby, Sam, and Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] parse errors in types, poly-dots cause me headaches
I am sending you the status line from DrRacket, version 6.1.1.5--2014-11-18(c4684c12/d) [3m]. On Nov 18, 2014, at 12:10 PM, Sam Tobin-Hochstadt wrote: > With that program, I get this error message: > >unsaved editor:7:48: Type Checker: parse error in type; type > variable must be used with ... variable: Y in: Y > > Which you also got. What changed it from the parse error to the > "unbound identifier" error? > > Sam > > On Tue, Nov 18, 2014 at 12:05 PM, Matthias Felleisen > wrote: >> >> What I sent is the exact program that produced the attached error in today's >> drracket [updated around 10am]. >> >> >> >> >> On Nov 18, 2014, at 11:58 AM, Sam Tobin-Hochstadt >> wrote: >> >>> No, I ran it, it barfed, and then I figured out what went wrong. Then >>> I sent you an email with a fix. Unfortunately, that fix isn't enough >>> to make the program type check. Partly, there's an internal error, but >>> that's a missing case that will take work to support properly. >>> >>> We can do better with the error message as well, by special casing ... >>> in ->*, I think. >>> >>> I don't, however, get the unbound identifier error that is in your >>> screenshot. I just got the error message from your original post. Can >>> you send the exact program that produced the error in the screenshot? >>> >>> Sam >>> >>> On Tue, Nov 18, 2014 at 11:54 AM, Matthias Felleisen >>> wrote: >>>> >>>> On Nov 18, 2014, at 11:34 AM, Sam Tobin-Hochstadt >>>> wrote: >>>> >>>>> On Tue, Nov 18, 2014 at 10:45 AM, Matthias Felleisen >>>>> wrote: >>>>>> >>>>>> It's quite possible that this is Eli's bug again, but boy this causes >>>>>> headaches: >>>>>> >>>>>>> Type Checker: parse error in type; >>>>>>> type variable must be used with ... >>>>>>> variable: Y in: Y >>>>>> >>>>>> And it points precisely to where Y is followed by ... >>>>> >>>>> The problem here is that you're using ->* without using the syntax of >>>>> ->*. Fortunately, this program doesn't need ->* at all. >>>>> >>>>> Unfortunately, I don't know how to make this function type check yet, >>>>> but I'll keep playing with it. >>>> >>>> >>>> Are you blaming the victim here? Please run what I send out and experience >>>> how the type checker barfs on you. This is a bug report. >> _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] parse errors in types, poly-dots cause me headaches
What I sent is the exact program that produced the attached error in today's drracket [updated around 10am]. On Nov 18, 2014, at 11:58 AM, Sam Tobin-Hochstadt wrote: > No, I ran it, it barfed, and then I figured out what went wrong. Then > I sent you an email with a fix. Unfortunately, that fix isn't enough > to make the program type check. Partly, there's an internal error, but > that's a missing case that will take work to support properly. > > We can do better with the error message as well, by special casing ... > in ->*, I think. > > I don't, however, get the unbound identifier error that is in your > screenshot. I just got the error message from your original post. Can > you send the exact program that produced the error in the screenshot? > > Sam > > On Tue, Nov 18, 2014 at 11:54 AM, Matthias Felleisen > wrote: >> >> On Nov 18, 2014, at 11:34 AM, Sam Tobin-Hochstadt >> wrote: >> >>> On Tue, Nov 18, 2014 at 10:45 AM, Matthias Felleisen >>> wrote: >>>> >>>> It's quite possible that this is Eli's bug again, but boy this causes >>>> headaches: >>>> >>>>> Type Checker: parse error in type; >>>>> type variable must be used with ... >>>>> variable: Y in: Y >>>> >>>> And it points precisely to where Y is followed by ... >>> >>> The problem here is that you're using ->* without using the syntax of >>> ->*. Fortunately, this program doesn't need ->* at all. >>> >>> Unfortunately, I don't know how to make this function type check yet, >>> but I'll keep playing with it. >> >> >> Are you blaming the victim here? Please run what I send out and experience >> how the type checker barfs on you. This is a bug report. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] parse errors in types, poly-dots cause me headaches
Attached is the screen shot of the error report. On Nov 18, 2014, at 11:54 AM, Matthias Felleisen wrote: > > On Nov 18, 2014, at 11:34 AM, Sam Tobin-Hochstadt > wrote: > >> On Tue, Nov 18, 2014 at 10:45 AM, Matthias Felleisen >> wrote: >>> >>> It's quite possible that this is Eli's bug again, but boy this causes >>> headaches: >>> >>>> Type Checker: parse error in type; >>>> type variable must be used with ... >>>> variable: Y in: Y >>> >>> And it points precisely to where Y is followed by ... >> >> The problem here is that you're using ->* without using the syntax of >> ->*. Fortunately, this program doesn't need ->* at all. >> >> Unfortunately, I don't know how to make this function type check yet, >> but I'll keep playing with it. > > > Are you blaming the victim here? Please run what I send out and experience > how the type checker barfs on you. This is a bug report. > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] parse errors in types, poly-dots cause me headaches
On Nov 18, 2014, at 11:34 AM, Sam Tobin-Hochstadt wrote: > On Tue, Nov 18, 2014 at 10:45 AM, Matthias Felleisen > wrote: >> >> It's quite possible that this is Eli's bug again, but boy this causes >> headaches: >> >>> Type Checker: parse error in type; >>> type variable must be used with ... >>> variable: Y in: Y >> >> And it points precisely to where Y is followed by ... > > The problem here is that you're using ->* without using the syntax of > ->*. Fortunately, this program doesn't need ->* at all. > > Unfortunately, I don't know how to make this function type check yet, > but I'll keep playing with it. Are you blaming the victim here? Please run what I send out and experience how the type checker barfs on you. This is a bug report. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] parse errors in types, poly-dots cause me headaches
It's quite possible that this is Eli's bug again, but boy this causes headaches: > Type Checker: parse error in type; > type variable must be used with ... > variable: Y in: Y And it points precisely to where Y is followed by ... #lang typed/racket (module+ test (require rackunit)) ;; [Listof X] [X [Listof X] Y ... -> Y ...] Y ... -> Y ... (: foldl* (All (X Y ...) (->* [Listof X] [->* X Y ... (Values Y ...)] Y ... (Values Y ... (define (foldl* l f e1 . es) (define e+ (cons e1 es)) (cond [(empty? l) (apply values e+)] [else (call-with-values (lambda () (apply f (first l) e+)) (lambda e* (unless (cons? e*) ;; should I check that (= (length e*) (length e+)) (error 'fold* "f produced too few values: ~e" e*)) (apply foldl* (rest l) f e*)))])) (module+ test (define distances '(50 40 70 30 30)) (check-equal? (call-with-values (lambda () (foldl* distances (lambda (fst distance distance*) (values (+ fst distance) (cons (+ fst distance) distance*))) 0 '())) (lambda (_ x) (reverse x))) '(50 90 160 190 220))) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #29515: master branch updated
On Nov 17, 2014, at 11:05 PM, j...@racket-lang.org wrote:
> 981a68b Jay McCarthy 2014-11-17 18:59
> :
> | Moving enumerator
> :
> C pkgs/{redex-pkgs/redex-lib/redex/private/enumerator.rkt =>
> data-pkgs/data-lib/data/enumerate.rkt} (96%)
> M .../redex-lib/redex/private/enumerator.rkt| 1529 +-
>
> ~~
>
> 1b2c8ef Jay McCarthy 2014-11-17 20:04
> :
> | Adding contracts to data/enumerate
> :
> M pkgs/data-pkgs/data-lib/data/enumerate.rkt| 258 +--
> M .../redex-lib/redex/private/enumerator.rkt| 20 +-
>
> ~~
>
> 8a9b9c0 Jay McCarthy 2014-11-17 23:04
> :
> | Adding documentation
> :
> M pkgs/data-pkgs/data-doc/data/scribblings/data.scrbl | 1 +
> M pkgs/data-pkgs/data-lib/data/enumerate.rkt | 18 +++---
Well, things happen to the creator of packages too:
raco setup: --- checking package dependencies ---
raco setup: found undeclared dependency:
raco setup: mode: run
raco setup: for package: "data-lib"
raco setup: on package: "math-lib"
raco setup: dependent source:
/Users/matthias/plt/pkgs/data-pkgs/data-lib/data/compiled/enumerate_rkt.zo
raco setup: used module: (lib "math/flonum.rkt")
raco setup: found undeclared dependency:
raco setup: mode: run
raco setup: for package: "data-lib"
raco setup: on package: "math-lib"
raco setup: dependent source:
/Users/matthias/plt/pkgs/data-pkgs/data-lib/data/compiled/enumerate_rkt.zo
raco setup: used module: (lib "math/number-theory.rkt")
raco setup: --- summary of package problems ---
raco setup: undeclared dependency detected
raco setup: for package: "data-lib"
raco setup: on package:
raco setup:"math-lib"
raco setup: --- summary of errors ---
raco setup: error: during making for /redex-test/redex/tests
raco setup: require: unknown module
raco setup: module name: #
raco setup: context...:
raco setup: /Users/matthias/plt/racket/collects/compiler/cm.rkt:315:0:
compile-zo*
raco setup: /Users/matthias/plt/racket/collects/compiler/cm.rkt:519:26
raco setup: /Users/matthias/plt/racket/collects/compiler/cm.rkt:511:42
raco setup: /Users/matthias/plt/racket/collects/compiler/cm.rkt:476:0:
maybe-compile-zo
raco setup: /Users/matthias/plt/racket/collects/compiler/cm.rkt:591:2:
do-check
raco setup: /Users/matthias/plt/racket/collects/compiler/cm.rkt:673:4
raco setup:
/Users/matthias/plt/racket/collects/setup/parallel-do.rkt:423:20: loop
raco setup:
make[1]: *** [plain-in-place] Error 1
make: *** [in-place] Error 2
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] using module system for alternate namespaces
On Nov 3, 2014, at 10:10 PM, Dan Liebgold wrote: > Jay's idea was to use "define" to create a module binding from "a" to a > generated or decorated name, provide "a" (or not), and put the generated name > in the hash table. I'm pursuing that approach currently. Yeap, that would be the next idea (now that I figured what you meant). > PS: The motivation for this is to finally get our custom language "DC" to be > implemented as a proper Racket module language. It's turning out to be a bit > of a nightmare since we rely so heavily on the side effects of "load" and we > have 4 different namespaces active at once. This example is just one small > piece. What this really shows is how bad the choice of load was. I would bet a beer or something that you'll find #lang/require and friend will eventually make your life easier and happier. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] using module system for alternate namespaces
On Oct 27, 2014, at 7:00 PM, Dan Liebgold wrote: > I have a namespace behind a particular API. I'd love to hook into the module > system to control compilation, visibility, etc. of all the definitions and > references. > > Here's an example. 'a' is available in the top level module even though it > was defined by module 'm1' and not provided by any explicit mechanism. (Also, > order dependencies seem imminent.) Since you didn't reply to Jay's response, let me resume the thread. You had written not quite this: > #lang racket (module base racket (define my-table (make-hasheq)) (define-syntax (my-define stx) (syntax-case stx () [(_ my-id expr) (identifier? #'my-id) #'(hash-set! my-table 'my-id expr)])) (define-syntax (my-eval stx) (syntax-case stx () [(_ my-id) #'(hash-ref my-table 'my-id #f)])) ;; <--- my first change (provide my-define my-eval)) (module m1 racket (require (submod ".." base)) (my-define a (+ 1 2))) (require 'base 'm1) (my-eval a) ;; <--- my second change ;; --- When you write 'a' is available in the top-level module, even though you didn't import it, I don't see it. You imported all of base into the top level and m1. These imports include accessors to 'my-table' and 'm1' happened to store a key in this table. Why should you not be able to retrieve the value of 'a'? -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v6.1.1, Second Draft
On Oct 30, 2014, at 3:45 PM, Sam Tobin-Hochstadt wrote: >> >> How about this one? (Starting from Matthias's offering and editing the >> apology from Sam's a bit.) >> >> Typed Racket closes a safety hole in the typing for the >> exception system. The revised type system restricts raise so >> that only instances of the exn structure type and flat data >> are communicated to handlers. As a side-effect, previously >> well-typed programs may fail to typecheck. > > How about: > > Typed Racket now checks uses of the exception system more strictly, > eliminating safety bugs. The revised type system restricts raise so > that only instances of the exn structure type and flat data > are communicated to handlers, and enforces that exception handlers > deal with all possible arguments. As a side-effect, previously > well-typed programs may fail to typecheck. Can we please, pretty please, pretty please, pretty please drop these "nows"? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v6.1.1, Second Draft
properly -> corresponding fashion? Otherwise fine On Oct 29, 2014, at 6:54 PM, Sam Tobin-Hochstadt wrote: > On Wed, Oct 29, 2014 at 6:42 PM, Matthias Felleisen > wrote: >> >> 1. Can we please, pretty please, drop these "now"s from every single >> sentence? >> >> 2. I think this is close to what we may wish to say. Here is a small edit: >> >> * Typed Racket closes a safety hole due to the types for the >> exception system. The revised type system restricts raise so >> that only instances of the exn structure type and flat data >> are communicated to handlers. > > I like this, but we need to at least mention the other change. So how about: > > * Typed Racket closes two safety holes in the types for the > exception system. The revised type system restricts raise so > that only instances of the exn structure type and flat data > are communicated to handlers, and checks exception handlers properly. > > Sam > >> >> 3. I think it is perfectly acceptable to imply that a >> restriction of an existing type system breaks existing >> programs. If you don't, I'd say >> >> Existing programs may suffer from new type errors >> due to this restriction. >> >> >> >> >> >> >> >> On Oct 29, 2014, at 6:32 PM, Sam Tobin-Hochstadt >> wrote: >> >>> Here's another idea: >>> >>> * To ensure safety, Typed Racket now prohibits raising any values >>> other than exns and simple flat data. Some existing programs may now >>> have type errors because of this. >>> >>> Sam >>> >>> On Wed, Oct 29, 2014 at 6:12 PM, Sam Tobin-Hochstadt >>> wrote: >>>> The reason I don't like the second sentence you wrote is that it's >>>> true of every type system everywhere. And also, the more significant >>>> change for users will almost certainly be the first one (it's required >>>> changes to several packages already) -- almost no one raises anything >>>> that isn't an exn, and so I haven't seen any code actually affected by >>>> the second change. >>>> >>>> Sam >>>> >>>> On Wed, Oct 29, 2014 at 6:00 PM, Robby Findler >>>> wrote: >>>>> I prefer the second sentence I sent to either of those. Fundamentally >>>>> I think it is reasonable for the sentence to be slightly apologetic. >>>>> There was a problem, we fixed it, but the fix may require some pain of >>>>> our users. There's nothing wrong with that; it's just a fact of life. >>>>> No shame in hiding it. >>>>> >>>>> Robby >>>>> >>>>> On Wed, Oct 29, 2014 at 4:55 PM, Sam Tobin-Hochstadt >>>>> wrote: >>>>>> On Wed, Oct 29, 2014 at 5:47 PM, Robby Findler >>>>>> wrote: >>>>>>> Yes, that's what I mean. I don't think that the sentence "This may >>>>>>> break existing programs that rely on unsafe behavior." is accurate. >>>>>>> How about "This may break existing programs." or "Closing this hole >>>>>>> requires us to disallow some programs that do not signal runtime >>>>>>> errors." or something like that? >>>>>> >>>>>> How about "This may result in type errors in existing programs that >>>>>> rely on the original behavior; specifically, programs that `raise` >>>>>> higher-order values." >>>>>> >>>>>> Sam >>>>>> >>>>>>> >>>>>>> Robby >>>>>>> >>>>>>> On Wed, Oct 29, 2014 at 4:35 PM, Sam Tobin-Hochstadt >>>>>>> wrote: >>>>>>>> There were two holes. >>>>>>>> >>>>>>>> 1. We allowed exception handlers to assume that they received values >>>>>>>> of type `exn`, even when that wasn't right. >>>>>>>> 2. We allowed typed programs to throw arbitrary values, which means >>>>>>>> that you could throw a typed function to an untyped handler, which >>>>>>>> could then misuse it. >>>>>>>> >>>>>>>> Both of these changes could lead to type errors in programs that won't >>>>>>>> fai
Re: [racket-dev] Release Announcement for v6.1.1, Second Draft
1. Can we please, pretty please, drop these "now"s from every single sentence? 2. I think this is close to what we may wish to say. Here is a small edit: * Typed Racket closes a safety hole due to the types for the exception system. The revised type system restricts raise so that only instances of the exn structure type and flat data are communicated to handlers. 3. I think it is perfectly acceptable to imply that a restriction of an existing type system breaks existing programs. If you don't, I'd say Existing programs may suffer from new type errors due to this restriction. On Oct 29, 2014, at 6:32 PM, Sam Tobin-Hochstadt wrote: > Here's another idea: > > * To ensure safety, Typed Racket now prohibits raising any values > other than exns and simple flat data. Some existing programs may now > have type errors because of this. > > Sam > > On Wed, Oct 29, 2014 at 6:12 PM, Sam Tobin-Hochstadt > wrote: >> The reason I don't like the second sentence you wrote is that it's >> true of every type system everywhere. And also, the more significant >> change for users will almost certainly be the first one (it's required >> changes to several packages already) -- almost no one raises anything >> that isn't an exn, and so I haven't seen any code actually affected by >> the second change. >> >> Sam >> >> On Wed, Oct 29, 2014 at 6:00 PM, Robby Findler >> wrote: >>> I prefer the second sentence I sent to either of those. Fundamentally >>> I think it is reasonable for the sentence to be slightly apologetic. >>> There was a problem, we fixed it, but the fix may require some pain of >>> our users. There's nothing wrong with that; it's just a fact of life. >>> No shame in hiding it. >>> >>> Robby >>> >>> On Wed, Oct 29, 2014 at 4:55 PM, Sam Tobin-Hochstadt >>> wrote: On Wed, Oct 29, 2014 at 5:47 PM, Robby Findler wrote: > Yes, that's what I mean. I don't think that the sentence "This may > break existing programs that rely on unsafe behavior." is accurate. > How about "This may break existing programs." or "Closing this hole > requires us to disallow some programs that do not signal runtime > errors." or something like that? How about "This may result in type errors in existing programs that rely on the original behavior; specifically, programs that `raise` higher-order values." Sam > > Robby > > On Wed, Oct 29, 2014 at 4:35 PM, Sam Tobin-Hochstadt > wrote: >> There were two holes. >> >> 1. We allowed exception handlers to assume that they received values >> of type `exn`, even when that wasn't right. >> 2. We allowed typed programs to throw arbitrary values, which means >> that you could throw a typed function to an untyped handler, which >> could then misuse it. >> >> Both of these changes could lead to type errors in programs that won't >> fail at runtime, but that's true of just about everything in Typed >> Racket, so I don't really understand what you're asking. Here are >> examples of programs that will now type-error for each change. >> >> 1. (with-handlers ([void exn-message]) #f) >> 2. (raise (lambda ([x : Integer]) x)) >> >> I think the second problem is more what you mean, in that the first >> program is "wrong" in some sense, even though it doesn't go wrong, but >> the second example is a perfectly fine Racket program (if perhaps poor >> style), but not one that can be allowed in the presence of untyped >> code. >> >> Does that help explain things? >> Sam >> >> On Wed, Oct 29, 2014 at 5:17 PM, Robby Findler >> wrote: >>> Sam: can you elaborate on precisely what the hole was? In particular, >>> if there are any safe programs that the type system now rejects, I'd >>> be in favor of a slightly different wording. >>> >>> Robby >>> >>> On Wed, Oct 29, 2014 at 2:35 PM, Sam Tobin-Hochstadt >>> wrote: On Wed, Oct 29, 2014 at 3:30 PM, Ryan Culpepper wrote: > > * Exception handling changed to be safe. This may break existing > programs that rely on unsafe behavior. > > * Casts and predicates are supported in typed regions. I think these two bullets (esp the first one) need to make clear that they're about Typed Racket. How about: * Typed Racket's rules for exception handlers are now more restrictive, as required for safety. This may cause type errors for existing programs that rely on unsafe behavior. * Typed Racket now supports casts and predicates in typed regions. Sam _ Racket Developers list: http://lists.racket-lang.org/dev > _ > Racket Developers list: > http://lists.racket-lang.org/dev
[racket-dev] unstable contract lib
Just re-built HEAD on my desktop and got a load of missing dependency declarations -- unstable-contract-lib. What happened? -- Matthias > raco setup: --- checking package dependencies --- > raco setup: found undeclared dependency: > raco setup: mode: run > raco setup: for package: "future-visualizer-typed" > raco setup: on package: "unstable-contract-lib" > raco setup: dependent source: > /Users/matthias/plt/pkgs/future-visualizer-pkgs/future-visualizer-typed/future-visualizer/compiled/typed_rkt.zo > raco setup: used module: (lib "unstable/contract.rkt") > raco setup: found undeclared dependency: > raco setup: mode: run > raco setup: for package: "images-lib" > raco setup: on package: "unstable-contract-lib" > raco setup: dependent source: > /Users/matthias/plt/pkgs/images-pkgs/images-lib/images/compiled/flomap_rkt.zo > raco setup: used module: (lib "unstable/contract.rkt") > raco setup: found undeclared dependency: > raco setup: mode: run > raco setup: for package: "images-lib" > raco setup: on package: "unstable-contract-lib" > raco setup: dependent source: > /Users/matthias/plt/pkgs/images-pkgs/images-lib/images/private/compiled/deep-flomap-parameters_rkt.zo > raco setup: used module: (lib "unstable/contract.rkt") > raco setup: found undeclared dependency: > raco setup: mode: run > raco setup: for package: "images-lib" > raco setup: on package: "unstable-contract-lib" > raco setup: dependent source: > /Users/matthias/plt/pkgs/images-pkgs/images-lib/images/private/compiled/deep-flomap-render_rkt.zo > raco setup: used module: (lib "unstable/contract.rkt") > raco setup: found undeclared dependency: > raco setup: mode: run > raco setup: for package: "images-lib" > raco setup: on package: "unstable-contract-lib" > raco setup: dependent source: > /Users/matthias/plt/pkgs/images-pkgs/images-lib/images/private/compiled/deep-flomap-struct_rkt.zo > raco setup: used module: (lib "unstable/contract.rkt") > raco setup: found undeclared dependency: > raco setup: mode: run > raco setup: for package: "images-lib" > raco setup: on package: "unstable-contract-lib" > raco setup: dependent source: > /Users/matthias/plt/pkgs/images-pkgs/images-lib/images/private/compiled/deep-flomap_rkt.zo > raco setup: used module: (lib "unstable/contract.rkt") > raco setup: found undeclared dependency: > raco setup: mode: run > raco setup: for package: "images-lib" > raco setup: on package: "unstable-contract-lib" > raco setup: dependent source: > /Users/matthias/plt/pkgs/images-pkgs/images-lib/images/private/compiled/flomap-blur_rkt.zo > raco setup: used module: (lib "unstable/contract.rkt") > raco setup: found undeclared dependency: > raco setup: mode: run > raco setup: for package: "images-lib" > raco setup: on package: "unstable-contract-lib" > raco setup: dependent source: > /Users/matthias/plt/pkgs/images-pkgs/images-lib/images/private/compiled/flomap-composite_rkt.zo > raco setup: used module: (lib "unstable/contract.rkt") > raco setup: found undeclared dependency: > raco setup: mode: run > raco setup: for package: "images-lib" > raco setup: on package: "unstable-contract-lib" > raco setup: dependent source: > /Users/matthias/plt/pkgs/images-pkgs/images-lib/images/private/compiled/flomap-effects_rkt.zo > raco setup: used module: (lib "unstable/contract.rkt") > raco setup: found undeclared dependency: > raco setup: mode: run > raco setup: for package: "images-lib" > raco setup: on package: "unstable-contract-lib" > raco setup: dependent source: > /Users/matthias/plt/pkgs/images-pkgs/images-lib/images/private/compiled/flomap-gradient_rkt.zo > raco setup: used module: (lib "unstable/contract.rkt") > raco setup: found undeclared dependency: > raco setup: mode: run > raco setup: for package: "images-lib" > raco setup: on package: "unstable-contract-lib" > raco setup: dependent source: > /Users/matthias/plt/pkgs/images-pkgs/images-lib/images/private/compiled/flomap-pointwise_rkt.zo > raco setup: used module: (lib "unstable/contract.rkt") > raco setup: found undeclared dependency: > raco setup: mode: run > raco setup: for package: "images-lib" > raco setup: on package: "unstable-contract-lib" > raco setup: dependent source: > /Users/matthias/plt/pkgs/images-pkgs/images-lib/images/private/compiled/flomap-resize_rkt.zo > raco setup: used module: (lib "unstable/contract.rkt") > raco setup: found undeclared dependency: > raco setup: mode: run > raco setup: for package: "images-lib" > raco setup: on package: "unstable-contract-lib" > raco setup: dependent source: > /Users/matthias/plt/pkgs/images-pkgs/images-lib/images/private/compiled/flomap-stats_rkt.zo > raco setup: used module: (lib "unstable/contract.rkt") > raco setup: found undeclared dependency: > raco setup: mode: run > raco setup: for package: "images-lib" > raco setup: on package: "unstable-contract-lib" > raco setup: dep
Re: [racket-dev] Pre-Release Checklist for v6.1.1, Second Call
(I know, and I hadn't used it in forever.) On Oct 23, 2014, at 9:04 PM, Matthew Flatt wrote: > Ad, I hadn't guessed that you use the "Installer Package". It isn't one > of our normal distribution mode (i.e., there's no link to it on the > eventual download page), so far, and so I forgot about it, but it is > certaily prominent on the pre-release page. > > I'm not yet sure of the right repair, but I'll work on it. > > At Thu, 23 Oct 2014 15:11:03 -0400, Matthias Felleisen wrote: >> >> Yes, I did and expected this to be the problem. Can't we add a line to the >> Mac >> package installer that removes left-over stuff? >> >> I deleted the old installation and re-installed and drracket starts up fine. >> >> -- Matthias >> >> >> >> >> >> On Oct 23, 2014, at 2:26 PM, Matthew Flatt wrote: >> >>> Is it possible that you installed on top of an existing v6.0.900.900 >>> installation (for the previous release's candidate)? >>> >>> The file >>> >>> share/pkgs/drracket/drracket/private/compiled/rectangle-intersect_rkt.zo >>> >>> existed in v6.0.900.900, but it does not exist in v6.1.0.900, because >>> the library moved to a different package, "drracket-tool-lib". If you >>> installed v6.1.0.900 on top of v6.0.900.900, then the file would not >>> get replaced, and the module search would potentially find the old file >>> instead of the replacement that is in a different location. >>> >>> At Thu, 23 Oct 2014 13:24:08 -0400, Matthias Felleisen wrote: >>>> >>>> DrRacket on Mac OS X, 64-bit, Installer Package won't start on >>>> double-click. >>>> >>>> At the command line, I get this error message: >>>> >>>> [:~] matthias% /Applications/Racket/DrRacket.app/Contents/MacOS/DrRacket >>>> >> /Applications/Racket/share/pkgs/drracket/drracket/private/compiled/rectangle-int >>>> ersect_rkt.zo::1: read (compiled): wrong version for compiled code >>>> compiled version: 6.0.900.900 >>>> expected version: 6.1.0.900 >>>> context...: >>>> standard-module-name-resolver >>>> >>>> >> /Applications/Racket/share/pkgs/drracket/drracket/private/module-browser.rkt: >> >>>> [traversing imports] >>>> /Applications/Racket/share/pkgs/drracket/drracket/private/link.rkt: >>>> [traversing imports] >>>> /Applications/Racket/share/pkgs/drracket/drracket/tool-lib.rkt: >> [traversing >>>> imports] >>>> >>>> >> /Applications/Racket/share/pkgs/drracket/drracket/private/drracket-normal.rkt: >> >>>> [running body] >>>> /Applications/Racket/share/pkgs/drracket/drracket/drracket.rkt: [running >>>> body] >>>> >>>> >>>> >>>> >>>> >>>> On Oct 23, 2014, at 12:48 PM, Ryan Culpepper wrote: >>>> >>>>> Checklist items for the v6.1.1 release >>>>> (using the v6.1.0.900 release candidate build) >>>>> >>>>> Search for your name to find relevant items, reply when you finish an >>>>> item (please indicate which item/s is/are done). Also, if you have any >>>>> commits that should have been picked, make sure that the changes are in. >>>>> >>>>> Important: new builds are created without announcement, usually whenever >>>>> I pick a few commits. If you need to commit changes, please make sure >>>>> you tell me to pick it into the release branch. >>>>> >>>>> --> Release candidates are at >>>>> --> http://pre-release.racket-lang.org >>>>> >>>>> Please use these installers (or source bundles) -- don't test from >>>>> your own git clone (don't test the `master' branch by mistake!). To >>>>> get the tests, you can do this: >>>>> >>>>> cd ...racket-root... >>>>> ./bin/raco pkg install -i main-distribution-test >>>>> >>>>> -- >>>>> >>>>> * Matthias Felleisen >>>>> - Teachpacks Tests: check that new teachpacks are addable >>>>> - Teachpack Docs: check teachpack docs in the bundles >>>>> - Try teaching-languages testing f
Re: [racket-dev] Pre-Release Checklist for v6.1.1, Second Call
Yes, I did and expected this to be the problem. Can't we add a line to the Mac
package installer that removes left-over stuff?
I deleted the old installation and re-installed and drracket starts up fine.
-- Matthias
On Oct 23, 2014, at 2:26 PM, Matthew Flatt wrote:
> Is it possible that you installed on top of an existing v6.0.900.900
> installation (for the previous release's candidate)?
>
> The file
>
> share/pkgs/drracket/drracket/private/compiled/rectangle-intersect_rkt.zo
>
> existed in v6.0.900.900, but it does not exist in v6.1.0.900, because
> the library moved to a different package, "drracket-tool-lib". If you
> installed v6.1.0.900 on top of v6.0.900.900, then the file would not
> get replaced, and the module search would potentially find the old file
> instead of the replacement that is in a different location.
>
> At Thu, 23 Oct 2014 13:24:08 -0400, Matthias Felleisen wrote:
>>
>> DrRacket on Mac OS X, 64-bit, Installer Package won't start on double-click.
>>
>> At the command line, I get this error message:
>>
>> [:~] matthias% /Applications/Racket/DrRacket.app/Contents/MacOS/DrRacket
>> /Applications/Racket/share/pkgs/drracket/drracket/private/compiled/rectangle-int
>> ersect_rkt.zo::1: read (compiled): wrong version for compiled code
>> compiled version: 6.0.900.900
>> expected version: 6.1.0.900
>> context...:
>> standard-module-name-resolver
>>
>> /Applications/Racket/share/pkgs/drracket/drracket/private/module-browser.rkt:
>>
>> [traversing imports]
>> /Applications/Racket/share/pkgs/drracket/drracket/private/link.rkt:
>> [traversing imports]
>> /Applications/Racket/share/pkgs/drracket/drracket/tool-lib.rkt:
>> [traversing
>> imports]
>>
>> /Applications/Racket/share/pkgs/drracket/drracket/private/drracket-normal.rkt:
>>
>> [running body]
>> /Applications/Racket/share/pkgs/drracket/drracket/drracket.rkt: [running
>> body]
>>
>>
>>
>>
>>
>> On Oct 23, 2014, at 12:48 PM, Ryan Culpepper wrote:
>>
>>> Checklist items for the v6.1.1 release
>>> (using the v6.1.0.900 release candidate build)
>>>
>>> Search for your name to find relevant items, reply when you finish an
>>> item (please indicate which item/s is/are done). Also, if you have any
>>> commits that should have been picked, make sure that the changes are in.
>>>
>>> Important: new builds are created without announcement, usually whenever
>>> I pick a few commits. If you need to commit changes, please make sure
>>> you tell me to pick it into the release branch.
>>>
>>> --> Release candidates are at
>>> --> http://pre-release.racket-lang.org
>>>
>>> Please use these installers (or source bundles) -- don't test from
>>> your own git clone (don't test the `master' branch by mistake!). To
>>> get the tests, you can do this:
>>>
>>> cd ...racket-root...
>>> ./bin/raco pkg install -i main-distribution-test
>>>
>>> --
>>>
>>> * Matthias Felleisen
>>> - Teachpacks Tests: check that new teachpacks are addable
>>> - Teachpack Docs: check teachpack docs in the bundles
>>> - Try teaching-languages testing framework (check-expect)
>>> Updates:
>>> - Teachpack Updates: update HISTORY
>>> (updates should show v6.1.1 as the most current version; email me
>>> to pick the changes when they're done, or tell me if there are no such
>>> changes.)
>>>
>>> * Eli Barzilay
>>> - Swindle Tests
>>> - XREPL Tests
>>> - Verify PL language
>>> - Racket Tree: compare new distribution tree to previous one
>>> - Run the unix installer tests
>>> - Run zsh completions tests
>>> (". .../racket-completion.zsh; _racket --self-test")
>>>
>>> * Stephen Bloch
>>> - Picturing Programs Tests
>>>
>>> * Jon Rafkind
>>> Release tests for (one of the) linux releases:
>>> - Test that the `racket' and `racket-textual' source releases
>>> compile fine (note that they're still called `plt' and `mz' at
>>> this stage).
>>> - Test that the binary installers for both work, try each one in
>>> both normal and unix-style installation modes. (just ubuntu)
>>> [Note: get the release candidates from the URL in this email. Use
>>> the 'static table' link to see a list of all tar files available]
>>>
>>> * David Van Horn
>>> - EoPL Tests
>>>
>>> * Neil Toronto
>>> - Plot Tests
>>> - Images Tests
>>> - Inspect icons
>>> - Math tests
>>
>>
>> _
>> Racket Developers list:
>> http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Pre-Release Checklist for v6.1.1, Second Call
DrRacket on Mac OS X, 64-bit, Installer Package won't start on double-click.
At the command line, I get this error message:
[:~] matthias% /Applications/Racket/DrRacket.app/Contents/MacOS/DrRacket
/Applications/Racket/share/pkgs/drracket/drracket/private/compiled/rectangle-intersect_rkt.zo::1:
read (compiled): wrong version for compiled code
compiled version: 6.0.900.900
expected version: 6.1.0.900
context...:
standard-module-name-resolver
/Applications/Racket/share/pkgs/drracket/drracket/private/module-browser.rkt:
[traversing imports]
/Applications/Racket/share/pkgs/drracket/drracket/private/link.rkt:
[traversing imports]
/Applications/Racket/share/pkgs/drracket/drracket/tool-lib.rkt: [traversing
imports]
/Applications/Racket/share/pkgs/drracket/drracket/private/drracket-normal.rkt:
[running body]
/Applications/Racket/share/pkgs/drracket/drracket/drracket.rkt: [running
body]
On Oct 23, 2014, at 12:48 PM, Ryan Culpepper wrote:
> Checklist items for the v6.1.1 release
> (using the v6.1.0.900 release candidate build)
>
> Search for your name to find relevant items, reply when you finish an
> item (please indicate which item/s is/are done). Also, if you have any
> commits that should have been picked, make sure that the changes are in.
>
> Important: new builds are created without announcement, usually whenever
> I pick a few commits. If you need to commit changes, please make sure
> you tell me to pick it into the release branch.
>
> --> Release candidates are at
> --> http://pre-release.racket-lang.org
>
> Please use these installers (or source bundles) -- don't test from
> your own git clone (don't test the `master' branch by mistake!). To
> get the tests, you can do this:
>
> cd ...racket-root...
> ./bin/raco pkg install -i main-distribution-test
>
> --
>
> * Matthias Felleisen
> - Teachpacks Tests: check that new teachpacks are addable
> - Teachpack Docs: check teachpack docs in the bundles
> - Try teaching-languages testing framework (check-expect)
> Updates:
> - Teachpack Updates: update HISTORY
> (updates should show v6.1.1 as the most current version; email me
> to pick the changes when they're done, or tell me if there are no such
> changes.)
>
> * Eli Barzilay
> - Swindle Tests
> - XREPL Tests
> - Verify PL language
> - Racket Tree: compare new distribution tree to previous one
> - Run the unix installer tests
> - Run zsh completions tests
>(". .../racket-completion.zsh; _racket --self-test")
>
> * Stephen Bloch
> - Picturing Programs Tests
>
> * Jon Rafkind
> Release tests for (one of the) linux releases:
> - Test that the `racket' and `racket-textual' source releases
>compile fine (note that they're still called `plt' and `mz' at
>this stage).
> - Test that the binary installers for both work, try each one in
>both normal and unix-style installation modes. (just ubuntu)
> [Note: get the release candidates from the URL in this email. Use
> the 'static table' link to see a list of all tar files available]
>
> * David Van Horn
> - EoPL Tests
>
> * Neil Toronto
> - Plot Tests
> - Images Tests
> - Inspect icons
> - Math tests
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #29396: master branch updated
DOn't we want to merge this into 6.1.1? On Oct 20, 2014, at 3:44 PM, stamo...@racket-lang.org wrote: > stamourv has updated `master' from 538bb75d64 to 9030680e31. > http://git.racket-lang.org/plt/538bb75d64..9030680e31 > > =[ One Commit ]= > Directory summary: > 16.9% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/ > 83.0% pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/ > > ~~ > > 9030680 Vincent St-Amour 2014-10-20 11:34 > : > | Fix types for foldl and foldr with 3 lists. > | > | Thanks to Jack Firth for the report. > : > M .../tests/typed-racket/unit-tests/typecheck-tests.rkt| 13 + > M .../typed-racket-lib/typed-racket/base-env/base-env.rkt | 4 ++-- > > =[ Overall Diff ]=== > > pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/base-env.rkt > ~~ > --- > OLD/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/base-env.rkt > +++ > NEW/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/base-env.rkt > @@ -657,11 +657,11 @@ > (-poly (a b c d) > (cl-> [((a b . -> . b) b (-lst a)) b] > [((a b c . -> . c) c (-lst a) (-lst b)) c] > - [((a b c d . -> . d) d (-lst a) (-lst b) (-lst d)) d]))] > + [((a b c d . -> . d) d (-lst a) (-lst b) (-lst c)) d]))] > [foldr (-poly (a b c d) >(cl-> [((a b . -> . b) b (-lst a)) b] > [((a b c . -> . c) c (-lst a) (-lst b)) c] > - [((a b c d . -> . d) d (-lst a) (-lst b) (-lst d)) d]))] > + [((a b c d . -> . d) d (-lst a) (-lst b) (-lst c)) d]))] > [filter (-poly (a b) (cl->* > ((asym-pred a Univ (-FS (-filter b 0) -top)) >(-lst a) > > pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/typecheck-tests.rkt > ~~ > --- > OLD/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/typecheck-tests.rkt > +++ > NEW/pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/unit-tests/typecheck-tests.rkt > @@ -1155,6 +1155,19 @@ > (-polydots (a) ((list) (a a) . ->... . -Integer))] > |# > > +[tc-e (foldl (lambda: ([x : Integer] [acc : String]) acc) "" '(1 2 > 3)) > + -String] > +[tc-e (foldl (lambda: ([x : Integer] [y : Float] [acc : String]) > acc) "" '(1 2 3) '(1.2 3.4 5.6)) > + -String] > +[tc-e (foldl (lambda: ([x : Integer] [y : Float] [z : Symbol ] [acc > : String]) acc) "" '(1 2 3) '(1.2 3.4 5.6) '(a b c)) > + -String] > +[tc-e (foldr (lambda: ([x : Integer] [acc : String]) acc) "" '(1 2 > 3)) > + -String] > +[tc-e (foldr (lambda: ([x : Integer] [y : Float] [acc : String]) > acc) "" '(1 2 3) '(1.2 3.4 5.6)) > + -String] > +[tc-e (foldr (lambda: ([x : Integer] [y : Float] [z : Symbol ] [acc > : String]) acc) "" '(1 2 3) '(1.2 3.4 5.6) '(a b c)) > + -String] > + > ;; First is same as second, but with map explicitly instantiated. > [tc-e/t (plambda: (a ...) [ys : (a ... a -> Number) *] > (lambda: [zs : a ... a] _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] #f instead of path-string? when (require cKanren)
Could you use the github issue tracker to submit this? Thanks -- Matthias https://github.com/calvis/cKanren On Oct 2, 2014, at 12:05 PM, A.J. Lepper wrote: > Windows 64-bit, Racket v6.1 64-bit > > If I install cKanren from the package manager then (require cKanren) works > fine in Racket.exe from the command prompt, but produces an error in > DrRacket. simple-form-path receives #f instead of a path-string?, from > file-stamp-in-paths. Adding a [(false? (car paths)) #f] clause to the outer > cond stops the error, but may not be a good fix - I got a bit lost digging > through the stack above it and went for the easy option. I've attached the > backtrace. > > Thanks very much, > -Angus. > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] How to translate DrRacket GUI to another (human) language?
On Sep 5, 2014, at 11:15 AM, Antti Karttunen wrote: > On Fri, Sep 5, 2014 at 5:16 PM, Matthias Felleisen > wrote: >> >> A word of caution about *SL error messages. These messages are synthesized >> from fragments of sentences and then a global rewriter re-arranges them to >> improve their meaning based on work done by Guillaume Marceau, Kathi Fisler >> and Shriram (see SIGCSE 2010). The rewriter catches English phrases at the >> moment; you might be best off checking it out first. >> >> Sorry -- one day we'll get this aspect right -- Matthias >> > > Well, thanks in any case! For the moment we decided to proceed with > the English version. > > By the way, would it be a good idea to create a mailing list for > people who use (or intend to use) DrRacket in teaching, as separate > from an ordinary technical discussion? (I mean the main list.) There is plt-edu, low traffic. populated by educators who teach at many levels but mostly high school (14-18), freshman college. You can sign up for it from the Racket web site. > Here in Finland I know at least our team of three people who have > independently chosen (not knowing each other until quite recently) > DrRacket for teaching programming to (almost) complete beginners (not > CS-students), with encouraging results. Yes, I hear this again and again. We should be proactive and support such larger, special-domain user bases better. > It would be nice to have a forum for sharing specific pedagogical tips > when using DrRacket, with people from all over the world. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] How to translate DrRacket GUI to another (human) language?
A word of caution about *SL error messages. These messages are synthesized from fragments of sentences and then a global rewriter re-arranges them to improve their meaning based on work done by Guillaume Marceau, Kathi Fisler and Shriram (see SIGCSE 2010). The rewriter catches English phrases at the moment; you might be best off checking it out first. Sorry -- one day we'll get this aspect right -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] variable wrong procedure or structure-type shape error?
You need to clean out the cached compiled code and remake those collections. Remove the compiled directories, and run raco make again. -- Matthias On Aug 29, 2014, at 5:10 PM, Kevin Forchione wrote: > H…. something changed between Racket 6.1 and the latest release that is > producing this mysterious (to me at least!) error in a project of mine that > compiles fine with 6.1, but not with the latest version, producing: > > Welcome to DrRacket, version 6.1.0.5--2014-08-28(a1f5340/a) [3m]. > Language: racket [custom]; memory limit: 512 MB. > link: bad variable linkage; > reference to a variable that has the wrong procedure or structure-type shape > reference phase level: 0 > variable module: "/Users/lysseus/Racket/games/lib/matrix.rkt" > variable phase: 0 > reference in module: "/Users/lysseus/Racket/games/2048/2048-obj.rkt" in: > matrix-row > > Any idea wheat this error means and why 6.1.0.5 is getting the error? It > appears to have been introduced sometime after version > 6.1.0.5--2014-08-25(32ae3f8/a) [3m]., which compiled fine. > > -Kevin > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Should `register-finalizer` unwrap impersonators?
I imagine a type-definition construct that allows programmers to specify how the type is translated into a contract. Think (define-trusted-type Finalizer C) and then the C specifies how little and how much of the type you wish to check. And yes, this is potentially a soundness hole but I am thinking that the primary uses could be connected to things in the core or the FFI. And programmers who wish to reduce the soundness of TR could use it to speed up boundary crossings at the cost of getting things wrong. In a sense, it's an FFI for types. -- Matthias On Aug 17, 2014, at 3:47 PM, Sam Tobin-Hochstadt wrote: > Can you say more about what the API for what you're imagining is? > > Sam > > On Sun, Aug 17, 2014 at 3:41 PM, Matthias Felleisen > wrote: >> >> I am imagining that the type compilation of type Finalizer and such things >> would be parameterized over programmer code which would yield a 'trusted' >> 'thing' in this case except that this would open the door for other such >> things. >> >> >> >> >> On Aug 17, 2014, at 3:39 PM, Sam Tobin-Hochstadt wrote: >> >>> How would that change things here? The issue is about >>> finalizer-for-what, and that chaperones/impersonators affect object >>> identity. >>> >>> Sam >>> >>> On Sun, Aug 17, 2014 at 3:37 PM, Matthias Felleisen >>> wrote: >>>> >>>> Could we benefit from an abstract/opaque Finalizer type here? I know we >>>> don't have those yet but it may address the general problem. -- Matthias >>>> >>>> >>>> >>>> >>>> On Aug 16, 2014, at 8:55 AM, Neil Toronto wrote: >>>> >>>>> Short version: the contract system doesn't allow `register-finalizer` to >>>>> be used in Typed Racket. >>>>> >>>>> Long version: consider the following Typed Racket program, in which >>>>> instances of `os-resource-wrapper` represent an operating system resource >>>>> `os-resource`, which itself is just a counter. It attempts to register a >>>>> finalizer for allocated wrappers, which decrements the counter. >>>>> >>>>> >>>>> #lang typed/racket >>>>> >>>>> (require/typed >>>>> ffi/unsafe >>>>> [register-finalizer (All (A) (-> A (-> A Any) Void))]) >>>>> >>>>> (: os-resource Integer) >>>>> (define os-resource 0) >>>>> >>>>> (struct os-resource-wrapper ()) >>>>> >>>>> (: alloc-os-resource (-> os-resource-wrapper)) >>>>> (define (alloc-os-resource) >>>>> (set! os-resource (add1 os-resource)) >>>>> (define w (os-resource-wrapper)) >>>>> (register-finalizer w (λ (w) (set! os-resource (sub1 os-resource >>>>> w) >>>>> >>>>> (define w (alloc-os-resource)) >>>>> (printf "os-resource = ~v~n" os-resource) >>>>> (collect-garbage) >>>>> (sleep 1) ; give finalizers a chance to run >>>>> (printf "os-resource = ~v~n" os-resource) >>>>> >>>>> >>>>> I get this output: >>>>> >>>>> os-resource = 1 >>>>> os-resource = 0 >>>>> >>>>> The finalizer is being run while the program still has a pointer to the >>>>> wrapper object. I think it's because the wrapper object is being >>>>> impersonated when it's sent across the contract barrier, and the >>>>> *impersonator* is getting the finalizer. (Or it's a chaperone, or an >>>>> impostor, or a charlatan, or whatever. Let's go with impersonator.) >>>>> >>>>> In my specific case, the OS resources are OpenGL objects; e.g. vertex >>>>> object arrays. The call to `register-finalizer` *must* be in Typed Racket >>>>> code because the wrapper contains an (Instance GL-Context<%>), which >>>>> can't have a contract put on it, so it can't pass from untyped to typed >>>>> code. >>>>> >>>>> Is there any reason for `register-finalizer` to behave this way? Does it >>>>> ever make sense to register a finalizer on an impersonator? >>>>> >>>>> Neil ⊥ >>>>> _ >>>>> Racket Developers list: >>>>> http://lists.racket-lang.org/dev >>>> >>>> >>>> _ >>>> Racket Developers list: >>>> http://lists.racket-lang.org/dev >> _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Should `register-finalizer` unwrap impersonators?
I am imagining that the type compilation of type Finalizer and such things would be parameterized over programmer code which would yield a 'trusted' 'thing' in this case except that this would open the door for other such things. On Aug 17, 2014, at 3:39 PM, Sam Tobin-Hochstadt wrote: > How would that change things here? The issue is about > finalizer-for-what, and that chaperones/impersonators affect object > identity. > > Sam > > On Sun, Aug 17, 2014 at 3:37 PM, Matthias Felleisen > wrote: >> >> Could we benefit from an abstract/opaque Finalizer type here? I know we >> don't have those yet but it may address the general problem. -- Matthias >> >> >> >> >> On Aug 16, 2014, at 8:55 AM, Neil Toronto wrote: >> >>> Short version: the contract system doesn't allow `register-finalizer` to be >>> used in Typed Racket. >>> >>> Long version: consider the following Typed Racket program, in which >>> instances of `os-resource-wrapper` represent an operating system resource >>> `os-resource`, which itself is just a counter. It attempts to register a >>> finalizer for allocated wrappers, which decrements the counter. >>> >>> >>> #lang typed/racket >>> >>> (require/typed >>> ffi/unsafe >>> [register-finalizer (All (A) (-> A (-> A Any) Void))]) >>> >>> (: os-resource Integer) >>> (define os-resource 0) >>> >>> (struct os-resource-wrapper ()) >>> >>> (: alloc-os-resource (-> os-resource-wrapper)) >>> (define (alloc-os-resource) >>> (set! os-resource (add1 os-resource)) >>> (define w (os-resource-wrapper)) >>> (register-finalizer w (λ (w) (set! os-resource (sub1 os-resource >>> w) >>> >>> (define w (alloc-os-resource)) >>> (printf "os-resource = ~v~n" os-resource) >>> (collect-garbage) >>> (sleep 1) ; give finalizers a chance to run >>> (printf "os-resource = ~v~n" os-resource) >>> >>> >>> I get this output: >>> >>> os-resource = 1 >>> os-resource = 0 >>> >>> The finalizer is being run while the program still has a pointer to the >>> wrapper object. I think it's because the wrapper object is being >>> impersonated when it's sent across the contract barrier, and the >>> *impersonator* is getting the finalizer. (Or it's a chaperone, or an >>> impostor, or a charlatan, or whatever. Let's go with impersonator.) >>> >>> In my specific case, the OS resources are OpenGL objects; e.g. vertex >>> object arrays. The call to `register-finalizer` *must* be in Typed Racket >>> code because the wrapper contains an (Instance GL-Context<%>), which can't >>> have a contract put on it, so it can't pass from untyped to typed code. >>> >>> Is there any reason for `register-finalizer` to behave this way? Does it >>> ever make sense to register a finalizer on an impersonator? >>> >>> Neil ⊥ >>> _ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev >> >> >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Should `register-finalizer` unwrap impersonators?
Could we benefit from an abstract/opaque Finalizer type here? I know we don't have those yet but it may address the general problem. -- Matthias On Aug 16, 2014, at 8:55 AM, Neil Toronto wrote: > Short version: the contract system doesn't allow `register-finalizer` to be > used in Typed Racket. > > Long version: consider the following Typed Racket program, in which instances > of `os-resource-wrapper` represent an operating system resource > `os-resource`, which itself is just a counter. It attempts to register a > finalizer for allocated wrappers, which decrements the counter. > > > #lang typed/racket > > (require/typed > ffi/unsafe > [register-finalizer (All (A) (-> A (-> A Any) Void))]) > > (: os-resource Integer) > (define os-resource 0) > > (struct os-resource-wrapper ()) > > (: alloc-os-resource (-> os-resource-wrapper)) > (define (alloc-os-resource) > (set! os-resource (add1 os-resource)) > (define w (os-resource-wrapper)) > (register-finalizer w (λ (w) (set! os-resource (sub1 os-resource > w) > > (define w (alloc-os-resource)) > (printf "os-resource = ~v~n" os-resource) > (collect-garbage) > (sleep 1) ; give finalizers a chance to run > (printf "os-resource = ~v~n" os-resource) > > > I get this output: > > os-resource = 1 > os-resource = 0 > > The finalizer is being run while the program still has a pointer to the > wrapper object. I think it's because the wrapper object is being impersonated > when it's sent across the contract barrier, and the *impersonator* is getting > the finalizer. (Or it's a chaperone, or an impostor, or a charlatan, or > whatever. Let's go with impersonator.) > > In my specific case, the OS resources are OpenGL objects; e.g. vertex object > arrays. The call to `register-finalizer` *must* be in Typed Racket code > because the wrapper contains an (Instance GL-Context<%>), which can't have a > contract put on it, so it can't pass from untyped to typed code. > > Is there any reason for `register-finalizer` to behave this way? Does it ever > make sense to register a finalizer on an impersonator? > > Neil ⊥ > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Performance. Higher-order function
[[ Switched mailing list ]] Being in the main repo is different from being in the distribution (and thus automatically installed). I think that OC should be there when you download the full bundle. -- Matthias On Aug 9, 2014, at 3:36 PM, Vincent St-Amour wrote: > It used to be. > > When we introduced the package system, it sounded like we were going to > split the distribution into multiple repositories (and have the main > distribution pulled from those multiple repositories). Optimization > Coach is one of the few packages that did the switch. The rest never > followed. > > It doesn't make sense to merge OC back to the main repo, assuming we > still plan to split it up. > > In the meantime, that does mean that installing the coach has an > additional barrier to entry, which is unfortunate. > > Vincent > > > > At Sat, 9 Aug 2014 12:50:46 -0400, > Greg Hendershott wrote: >> >> Why isn't Optimization Coach one of the automatically-installed packages? >> >> Racket Users list: >> http://lists.racket-lang.org/users > > Racket Users list: > http://lists.racket-lang.org/users _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Surprising behavior of for/fold. Bug?
This is syntactically brittle design. Argh. On Jul 29, 2014, at 4:50 PM, "J. Ian Johnson" wrote: > I forgot that aspect of #:when and #:unless. Sorry for the noise. > -Ian > - Original Message - > From: "Sam Tobin-Hochstadt" > To: "J. Ian Johnson" > Cc: "dev" > Sent: Tuesday, July 29, 2014 4:46:49 PM GMT -05:00 US/Canada Eastern > Subject: Re: [racket-dev] Surprising behavior of for/fold. Bug? > > `#:when` and `#:unless` introduce nesting, a la `for/fold*`. So yes, > you should expect this. > > Sam > > On Tue, Jul 29, 2014 at 1:23 PM, J. Ian Johnson wrote: >> This will eat all your memory, >> >> (for/list ([x '(0 1 2 3 4 5 6)] >> #:unless (= x 4) >> [i (in-naturals)]) >> x) >> >> and this won't. >> >> (for/list ([x '(0 1 2 3 4 5 6)] >> [i (in-naturals)] >> #:unless (= x 4)) >> x) >> >> Should we expect this behavior? I was really surprised by this. >> -Ian >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Release Announcement for v6.1
On Jul 28, 2014, at 2:33 PM, Ryan Culpepper wrote: > matthias: > - add check-random (aec84f4a) check-random is an addition to the preferred unit testing framework in the teaching languages. It enables the testing of students' functions that use random-number generation. (Thanks to David Van Horn (UMaryland) for proposing this idea.) ;;; --- Some grammatical suggestions the UNDEFINED issue: > Racket now raises ... Instead of the ubiquitous 'now' I'd prefer 'Racket v6.1 raises ...' ;;; --- .. in Robby's section: > - contracts: improved random generation for contracts; the contract > system can now easily find simple mistakes in data-structure > implementations (eg accidentally reversing a conditional in a heap > invariant check), given strong enough contracts - contracts: the contract system's random testing facility has been strengthened so that it can easily find mistakes in contracted data structure implementations (e.g. an accidental reverse of a conditional in a heap invariant check) > - redex: the semantics of mis-match patterns (variables followed by > _!_) inside ellipses has changed in a backwards incompatible way; they > semantics is now much clearer and now potentially even useful this change simplifies the patterns' semantics and increases the usefulness of these patterns ;;; +1 on plumbers, if only for the word :-) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #29062: master branch updated
Thanks for the extensive internal documentation. -- Matthias On Jul 19, 2014, at 7:07 PM, gcoo...@racket-lang.org wrote: > gcooper has updated `master' from 45306397cc to 2881b60536. > http://git.racket-lang.org/plt/45306397cc..2881b60536 > > =[ One Commit ]= > Directory summary: > 100.0% pkgs/frtime/ > > ~~ > > 2881b60 Gregory Cooper 2014-07-19 16:06 > : > | Rewrite the delay-by primitive so it's easier to understand. > | > | Also, add comments that attempt to explain how it's intended to work. > : > M pkgs/frtime/lang-ext.rkt | 139 > > =[ Overall Diff ]=== > > pkgs/frtime/lang-ext.rkt > > --- OLD/pkgs/frtime/lang-ext.rkt > +++ NEW/pkgs/frtime/lang-ext.rkt > @@ -3,6 +3,7 @@ > (only-in racket/list first second last-pair empty > empty?)) > (only-in racket/list first second cons? empty empty? rest last-pair) > (only-in racket/function identity) > + data/queue > (only-in frtime/core/frp super-lift undefined undefined? behavior? > do-in-manager-after do-in-manager proc->signal set-signal-thunk! register > unregister > signal? signal-depth signal:switching? signal-value > value-now signal:compound? signal:compound-content signal:switching-current > signal:switching-trigger > set-cell! snap? iq-enqueue value-now/no-copy event-receiver > event-set? proc->signal:switching set-signal-producers! set-signal-depth! > safe-signal-depth > @@ -403,46 +404,110 @@ > (set-signal-value! ret ((signal-thunk ret))) > ret)) > > -; XXX general efficiency fix for delay > -; signal[a] signal[num] -> signal[a] > -(define (delay-by beh ms-b) > - (letrec ([last (mcons (cons (if (zero? (value-now ms-b)) > - (value-now/no-copy beh) > - undefined) > - (current-inexact-milliseconds)) > -empty)] > - [head last] > - [consumer #f] > - [producer (proc->signal > - (lambda () > -(let* ([now (and (signal? consumer) > (current-inexact-milliseconds))] > - [ms (value-now ms-b)]) > - (let loop () > -(if (or (empty? (mcdr head)) > -(< now (+ ms (cdr (mcar (mcdr head)) > - (let ([val (car (mcar head))]) > -(if (event-set? val) > - (make-events-now (event-set-events val)) > - val)) > - (begin > -(set! head (mcdr head)) > -(loop)))]) > +;; signal[a] num -> signal[a] > +;; > +;; Returns a signal whose value at (approximately) time (+ t |delay-millis|) > is a (deep) snapshot > +;; of the value of |sig| at time t, for all times t from now on. For earlier > times, the value of the > +;; returned signal is undefined. > +;; > +;; Assumptions: (current-inexact-milliseconds) is monotonically > non-decreasing; |delay-millis| is > +;; positive and finite. > +(define (delay-by sig delay-millis) > + ;; Implementation strategy: > + ;; > + ;; Maintain a queue of pairs (snapshot . timestamp) of the observed signal > going back in > + ;; time for at least |delay-millis|. Start with (undefined . -inf.0) and > (current-value . now), so > + ;; there should always be at least one item (value . timestamp) in the > queue such that > + ;; (>= now (+ timestamp delay-millis)). > + ;; > + ;; |consumer| runs whenever |sig| changes and adds an item with the > observed value and current > + ;; time to the queue; schedules |producer| to run at |delay-millis| in > the future, by which > + ;; time it should be ready to take on that observed value. > + ;; > + ;; |producer| has no dependencies recorded in the dataflow graph and only > runs when scheduled > + ;; by the consumer. (This is what allows delay-by to break cycles.) It > traverses the queue > + ;; looking for the latest observation (value . timestamp) such that > + ;; (>= now (+ timestamp delay-millis)), and takes on the observed > value. |producer| is the > + ;; value returned by this procedure, so it stays alive as long as > anything cares about its > + ;; value. > + (let* ([queue (make-queue)] > + > + ;; finish : (a . num) a -> a > + ;; Puts |queue-item| back on the front of the queue and returns > |val|, updating the > + ;; occurrence timestamp if |val| represents an event set. > + ;; TODO(gcooper): We could avoid this if data/queue supported a > "peek" operation. > + [f
Re: [racket-dev] [plt] Push #29061: master branch updated
Ouch, This is precisely the kind of (imperative) change I didn't hope to see. I will look at the file in a moment but I'd hope you can do this with a lambda wrapper instead of a set!. -- Matthias On Jul 19, 2014, at 1:27 AM, gcoo...@racket-lang.org wrote: > pkgs/frtime/lang-ext.rkt > > --- OLD/pkgs/frtime/lang-ext.rkt > +++ NEW/pkgs/frtime/lang-ext.rkt > @@ -412,17 +412,7 @@ > (current-inexact-milliseconds)) > empty)] >[head last] > - [consumer (proc->signal > - (lambda () > -(let* ([now (current-inexact-milliseconds)] > - [new (deep-value-now beh empty)] > - [ms (value-now ms-b)]) > - (when (not (equal? new (car (mcar last > -(set-mcdr! last (mcons (cons new now) > - empty)) > -(set! last (mcdr last)) > -(schedule-alarm (+ now ms) producer > - beh ms-b)] > + [consumer #f] >[producer (proc->signal > (lambda () > (let* ([now (and (signal? consumer) > (current-inexact-milliseconds))] > @@ -437,7 +427,19 @@ > (begin > (set! head (mcdr head)) > (loop)))]) > -producer)) > +(begin > + (set! consumer (proc->signal > + (lambda () > +(let* ([now (current-inexact-milliseconds)] > + [new (deep-value-now beh empty)] > + [ms (value-now ms-b)]) > + (when (not (equal? new (car (mcar last > +(set-mcdr! last (mcons (cons new now) > + empty)) > +(set! last (mcdr last)) > +(schedule-alarm (+ now ms) producer > + beh ms-b)) > + producer))) > > (define (inf-delay beh) > (delay-by beh 0)) > @@ -451,8 +453,8 @@ > [last-time (current-inexact-milliseconds)] > [last-val (value-now b)] > [last-alarm 0] > - [producer (proc->signal (lambda () (and (signal? consumer) > accum)))] > - [consumer (proc->signal void b ms-b)]) > + [consumer (proc->signal void b ms-b)] > + [producer (proc->signal (lambda () (and (signal? consumer) > accum)))]) > (set-signal-thunk! >consumer >(lambda () _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #29023: master branch updated
Unfortunately, it is impossible to distinguish the two kinds of
contracts. Even if we introduced two different linguistic mechanisms,
we would simply confuse programmers more.
Let's try this experiment for a while and see what happens.
On Jul 14, 2014, at 9:46 AM, Sam Tobin-Hochstadt wrote:
> I think the vast majority of contract errors that Racket programmers
> see will be from contracts that the particular programmer didn't
> write. For example: standard library contracts, or contracts from
> packages they install, or contracts generated by Typed Racket, or
> other such.
>
> For example, here's a simple contract error:
>
> -> (require scribble/core)
> -> (part-parts 7)
> ; part-parts: contract violation
> ; expected: part?
> ; given: 7
> ; in: the 1st argument of
> ; (-> part? (listof part?))
> ; contract from:
> ; /scribble-lib/scribble/core.rkt
> ; blaming: top-level
> ;(assuming the contract is correct)
> ; at: /scribble-lib/scribble/core.rkt:164.2
>
> What does the "assuming the contract is correct" mean to the
> programmer here? They can't change the contract, and it's not obvious
> in what sense the contract being incorrect would change anything.
>
> In general, I think that your new message makes a lot of sense if
> programmers mostly experience contracts as strong invariants
> protecting complex components specified publicly -- the sort of thing
> you've talked about as a "marketplace of components". But I don't
> think that's how Racket programmers typically experience contracts --
> instead, they're more like the example above: simple specifications
> protecting small functions implemented privately and used as
> error-checking.
>
> Sam
>
> On Mon, Jul 14, 2014 at 9:30 AM, Robby Findler
> wrote:
>> I do not buy this argument: the user didn't write the compiler but they
>> wrote the contract.
>>
>> Robby
>>
>>
>> On Monday, July 14, 2014, Sam Tobin-Hochstadt wrote:
>>>
>>> This seems like a situation where the new error message is potentially
>>> more confusing, even though it's technically more correct. There are
>>> lots of other caveats we could add ("assuming there isn't a compiler
>>> bug", etc) but I think adding them would make Racket harder to use.
>>>
>>> Sam
>>>
>>> On Mon, Jul 14, 2014 at 9:11 AM, wrote:
robby has updated `master' from 737330deb6 to 1dda800ca2.
http://git.racket-lang.org/plt/737330deb6..1dda800ca2
=[ One Commit ]=
Directory summary:
100.0% racket/collects/racket/contract/private/
~~
1dda800 Robby Findler 2014-07-14 08:09
:
| add contract-correct caveat to contract violation error messages
:
M racket/collects/racket/contract/private/blame.rkt | 1 +
=[ Overall Diff ]===
racket/collects/racket/contract/private/blame.rkt
~
--- OLD/racket/collects/racket/contract/private/blame.rkt
+++ NEW/racket/collects/racket/contract/private/blame.rkt
@@ -320,6 +320,7 @@
from-line
on-line
blaming-line
+ " (assuming the contract is correct)"
at-line))
;; combine-lines : (->* #:rest (listof (or/c string? #f))) string?)
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] for loops with interleaved escape continuations
On Jul 2, 2014, at 2:26 PM, Neil Van Dyke wrote: > Loop syntax and sugar is fine. And having "#:continue" and "#:break" > keywords at the top of the form is sufficient warning of surprises ahead, > IMHO. > > I do have a minor ongoing concern that people coming from other languages > lately latch onto the "for" family of forms from the start, don't get enough > exposure to named-"let", and/or mutually/self-recursive procedures, and then > end up shoehorning problems into the "for" forms (with flag variables and > redundant checks and such). "break" and "continue" can be good shoehorns. > > I still half-seriously like the idea of having unlockable language feature > achievements, like unlockable equipment in video games. I might play with > that idea soon. Cute idea. It generalizes the teaching languages, which at some point we wanted to explore, too. We dubbed this HLI as in Human-Language Interface. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] for loops with interleaved escape continuations
Interestingly enough, I tried to explain this idea to the Imperative Advanced Placement crowd in the 1990s. With functional programming -- control from tail-recursive functions -- is more expressive than programming with limited loops because you can (1) break/resume/continue/foobar your 'loops' more easily (including loops that communicate actual values instead of void) and (2) you can write abstractions over these things once you have good use cases. Now we're in a position to do so and what John & Sam sketch out is finally a realization of this idea. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28945: master branch updated
On Jun 27, 2014, at 4:47 PM, Robby Findler wrote: > This effect is, I believe, one of the > main things people mean when they say that Redex's typesetting is ugly > (and it is indeed ugly in larger quantities). [[ Just now catching up ]] This is off topic in a sense but right on topic wrt the above quote. When people dislike Redex in scribble or latex document, they are saying that they chose some fonts (perhaps defaults) and that Redex fragments look different than their context because Redex chose a different font. Most latex users don't know much about fonts and certainly don't know how to adjust Redex so it uses their latex fonts. [[ I did some font loading and messing around in my TeX days and young LaTeX days and I am honestly glad I forgot those details. I am not looking forward to creating the .tex styles for 2e. ]] _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] for loops with interleaved escape continuations
In principle I like this #:ec idea, but I would feel more comfortable if you explored the whole range of for loops and their interactions with this new feature. -- Matthias On Jun 28, 2014, at 6:54 AM, Jay Kominek wrote: > On Fri, Jun 27, 2014 at 8:40 PM, J. Ian Johnson wrote: >> One is that #:when in for-clauses allows you to skip iterations, but you >> want it in the body. This is a cosmetic difference that you can get around >> by doing #:when (begin imperative-stuff-before-guard guard). If you want ecs >> to escape an entire for loop, that's what #:break is for. If you want ecs to >> escape even more for loops, well, that is an unplanned but a possibly useful >> feature for nested for loops. > > Yes, #:when gets frustratingly close, but if > imperative-stuff-before-guard does something expensive (fetches the > ith web page, or what have you), I've got to repeat it in the body if > I actually want to use the value. Same issue with #:break and all the > other guards. > > If I end up wanting #:when, #:break, and the body of the expression to > all make use of some expensive value, I'm stuck reproducing it. (Or > setting up some previous loop to make a bunch of promises that I can > force... bleh.) > > Would I have more luck selling folks on some sort of #:let [id > val-expr] construct that could mix in with the sequences? That'd get > me most of what I was going for, and it is probably(?) a lot more > obvious how it should behave. > >> The other is that this is not Rackety and thus not natively supported for >> the same reason there are no "return" statements. The for macros are so much >> more than Python's for - they can produce values. Don't throw everything >> into the void :) > > Sorry, I should've put more than a moment's effort into my example. I > specifically tried to ensure that this can do more than Python's break > & continue! In fact, this allows poor boring "for" who normally > produces nothing but void to produce a useful value. Here are some > more examples, again contrived because I'm trying to keep them short, > but hopefully making more apparent the advantage over simple break & > continue: > > (for (#:ec break > [x (in-range 0 10)]) > (when(= x 2) >(break "found it!")) > (printf "~a~n" x)) > > 0 > 1 > "found it!" > > > (for/fold ([x 0] [y 0]) > (#:ec break > [i (in-range0 10)] > #:eccontinue) > (when (= i 3) >(continue (+ x 1000) (+ y 1000))) > (when(= i 7) >(break (exact->inexact x) y)) > (values (add1 x) (add1 y))) > > 1006.0 > 1006 > > The inner escape continuation passes its values along to the next > iteration, while the outer one can return values for the entire > expression. And of course, it can be interleaved between sequences, > just like #:when and friends. > > I was allowing the use of the continuations without arguments so that > there'd be a more obvious translation from languages with wimpy > control statements, but they raise the issue of what values should be > used by default. > > (And to reiterate the current inadequacies, it doesn't behave at all > properly with for/list, for/vector or for/set.) > > Thanks for looking. > > -- > Jay Kominek > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] style was Re: 2htdp/image Feature Suggestion
Good choice :-) ;; --- I think Robby translated the recommendations of the style guide just right. BTW, I didn't think it mentions named let only let. Indeed, I can't find a recommendation of preferring defined over named let. ;; --- A comment on your commenting style. I tried to read your code and Robby's version of it, and I found that the large number of comments distracted me and weren't helpful at all. I'd recommend using variable and function names instead that convey the same idea as the comments. Try it out. -- Matthias On Jun 29, 2014, at 9:09 AM, Jos Koot wrote: > Thanks. > I always use DrRacket for editing racket code. > Jos. > >> -Original Message- >> From: Greg Hendershott [mailto:greghendersh...@gmail.com] >> Sent: domingo, 29 de junio de 2014 5:55 >> To: Jos Koot >> Cc: dev; jja.k...@gmail.com >> Subject: Re: [racket-dev] 2htdp/image Feature Suggestion >> >> On Mon, Jun 23, 2014 at 9:44 PM, Jos Koot wrote: >>> style. Writing this, the idea comes up in my mind that it >> should be possible >>> to do some transformations to the recommended style by >> means of redex. Or >>> may be by means of syntax-case while limiting the >> transformers to the >>> desired level of expansion. Both instuments are interesting >> enough for me to >>> give it a try. If I am able to do something usefull in this >> sense, you'll >>> hear of me, but give me some time, please. >> >> If you use Emacs, check out Ryan's sexp-rewrite mode. IIUC he's >> implemented `syntax-parse`-like functionality in Elisp: >> >> https://github.com/rmculpepper/sexp-rewrite >> >> >> p.s. In a similar spirit, but for Clojure, and IIUC implemented >> leveraging paredit: >> >> https://github.com/clojure-emacs/clj-refactor.el > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] 2htdp/image Feature Suggestion
On Jun 23, 2014, at 12:03 PM, Kevin Forchione wrote: > I’ve only skimmed the manual so far, but see it doesn’t address one of my > questions: whether and when to favor functions such as first/rest/empty?, > etc., over the Lisp-y car/cdr/null?, etc. I have noticed that some of these > functions are list-specific and perhaps they’re to be preferred when working > specifically with lists? Whenever naturally possible. (In syntax, you can't use them.) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] 2htdp/image Feature Suggestion
Thanks. We will need to figure out how to accommodate keywords in a teachpack. In the meantime, write frame like this: (define (frame-2 img #:frame-color (frame-color 'black) #:background-color (background-color 'transparent) #:frame-offset (frame-offset 0) #:frame-x-offset (frame-x-offset frame-offset) #:frame-y-offset (frame-y-offset frame-offset)) (define width (+ (image-width img) frame-x-offset)) (define height (+ (image-height img) frame-y-offset)) (overlay (rectangle width height 'outline frame-color) (center-crop width height img) (rectangle width height 'solid background-color))) Prefer define over let. -- Matthias On Jun 21, 2014, at 2:42 PM, Kevin Forchione wrote: > Hi guys, > I’ve been working with 2htdp/image and been struck by its monitor-oriented > coordinate system and its image-centric perspective, both of which have > proven a rich bed for new tools. I’ve found these two functions have been > useful to me and might be useful for others. I’ve particularly found them > useful as my racket sessions use the “white on black” color schemes, and with > my eyesight a pixel’s contrast makes a difference. > > The center-crop function facilitates the image-cntric perspective of the > library by centering the cropping rectangle on the image center. The frame > function replaces the library’s existing function with one that does the same > thing, but also provides parameters for setting the pixel frame coloring, > background coloring within the frame, and x/y offsets that work with > center-crop to expand or shrink the framing of the image. > > ;; center-crop: width height image -> image? > ;; crops image in a rectangle of width x height whose center is image center. > (define (center-crop width height img) > (crop (- (quotient (image-width img) 2) (quotient width 2)) >(- (quotient (image-height img) 2) (quotient height 2)) >width >height >img)) > > ;; frame: image frame-option ... -> image? > ;; Returns an image just like image, except with a frame-color'd, single > pixel frame > ;; around the bounding box of the image. The background-color indicates the > color > ;; inside the frame over which the image is laid. If an offset is provided it > ;; indicates a center-crop in that dimension. A positive value extends the > crop > ;; beyond the image bounding box, a negative value center-crops the image > within > ;; the bounding box. > (define (frame img > #:frame-color (frame-color 'black) > #:background-color (background-color 'transparent) > #:frame-offset (frame-offset 0) > #:frame-x-offset (frame-x-offset frame-offset) > #:frame-y-offset (frame-y-offset frame-offset)) > (let ([width (+ (image-width img) frame-x-offset)] >[height (+ (image-height img) frame-y-offset)]) >(overlay (rectangle width height 'outline frame-color) > (center-crop width height img) > (rectangle width height 'solid background-color > > -Kevin > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] outage
NEU CCIS suffered from a major power outage for all day yesterday (until early this morning). Our systems stuff described it with "the UPS that feeds the room had failed, could not be restarted, and could not be bypassed." Sorry for any inconveniences -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] fresh install ends in
> raco setup: package declares no dependencies: "txexpr" > raco setup: package declares no dependencies: "sugar" > hash-ref: no value found for key > key: "racket" > context...: >/Users/matthias/plt/racket/collects/setup/private/pkg-deps.rkt:227:8: > for-loop >/Users/matthias/plt/racket/collects/racket/private/map.rkt:21:13: map >/Users/matthias/plt/racket/collects/setup/private/pkg-deps.rkt:415:2: > for-loop >/Users/matthias/plt/racket/collects/setup/private/pkg-deps.rkt:24:0: > check-package-dependencies >/Users/matthias/plt/racket/collects/setup/setup-core.rkt:61:0: setup-core >/Users/matthias/plt/racket/collects/setup/setup-go.rkt: [running body] >/Users/matthias/plt/racket/collects/setup/main.rkt: [running body] >/Users/matthias/plt/racket/collects/raco/main.rkt: [running body] > make[1]: *** [plain-in-place] Error 1 > make: *** [in-place] Error 2 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Machinery for eliding contracts
I was thinking of associating the contract with the type from which it comes and no that's not hash-consing. And if it's slower, too bad. -- Matthias On Jun 10, 2014, at 12:47 PM, Eric Dobson wrote: > On Tue, Jun 10, 2014 at 6:15 AM, Matthias Felleisen > wrote: >> >> On Jun 9, 2014, at 6:02 PM, Eric Dobson wrote: >> >>>> >>>> Eric, are you talking about changing the proxy values that wrap HO/mutable >>>> contracted values? >>> Yes. I want the proxy values to include information about who agreed >>> to the contract in addition to the contract agreed to. >>> >>> I actually realize that I might need more than just the contract >>> agreed to because of how TR changes the generated contract to remove >>> checks for what it guarantees, so that info is not in the contract. >>> But I believe that can be added back as a structure property on the >>> contract. >> >> >> Would some form of hash-consing contracts work here? -- Matthias >> > > I don't think so. But not sure exactly what you are proposing. > > The issue is that there are 4 contracts here and 2 of them currently > do not exist at runtime. The 4 are TRs checks/promises on an > export/import. (Using import for a value flowing into an exported > function). The promise contracts do not currently exist as removing > them was my previous optimization (They never fail). What I want to do > is change the check on import from (array/c symbol?) to (if/c > (protected>? (array/c symbol?)) any/c (array/c symbol?)). Where > (protected>? x/c) checks if TR already promised something stronger > than x/c. > > I believe that you are proposing that we can use the identity of the > contract returned by value-contract to determine what the promised > contract would have been. This does not work as (Array Symbol) and > (Array Float) both get translated to (array/c any/c) for export, and > we would want to lookup different promised contracts for them. We > could use weak hash map as an extra field but that seems like it would > be slow. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Machinery for eliding contracts
On Jun 9, 2014, at 6:02 PM, Eric Dobson wrote: >> >> Eric, are you talking about changing the proxy values that wrap HO/mutable >> contracted values? > Yes. I want the proxy values to include information about who agreed > to the contract in addition to the contract agreed to. > > I actually realize that I might need more than just the contract > agreed to because of how TR changes the generated contract to remove > checks for what it guarantees, so that info is not in the contract. > But I believe that can be added back as a structure property on the > contract. Would some form of hash-consing contracts work here? -- Matthias smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Machinery for eliding contracts
On Jun 9, 2014, at 9:38 AM, Sam Tobin-Hochstadt wrote: > On Mon, Jun 9, 2014 at 3:19 AM, Eric Dobson wrote: >> >> It would be nice if the contract on the input to g could be elided. It >> seems like this could be done by using something like prop:contracted >> but that allowed accessing the parties that agreed to the contract. >> >> I'm imagining something like >> (lambda (v) (and (has-contract? v) (contracted-value-providing-side=? >> v 'the-typed-world) (contract-stronger? (value-contract v) >> new-contract))) >> >> One issue I see is that we need an unforgeable property that the value >> actually came from the typed world so we know that eliding the new >> contract is safe. >> >> Does this seem like a reasonable thing to support/do people see issues with >> it? > > It seems like this could be simplified a little just by allowing > contract parties to be compared. IOW, at the point where you're > writing that function, we have two contracts, and we need to know if > the negative party of one is the positive party of the other. Then > you don't need to worry about unforgeability, I think. Well some code could swap identities on such things. Not accidentally. Plus I think this would eliminate the anticipated benefits if there are chains of TR modules involved. I think Eric just needs to know whether something came out of the TR world and flows back w/o being touched. ;; --- Eric, are you talking about changing the proxy values that wrap HO/mutable contracted values? -- Matthias smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Apple today
This is the most nonsensical sentence I have seen in a long time. I should keep it around as a bad example. On Jun 2, 2014, at 8:45 PM, Danny Yoo wrote: > From the Ars Technica article, second paragraph: > > "Swift seems to get rid of Objective C's reliance on defined pointers; > instead, the compiler infers the variable type, just as many scripting > languages do." > > Is it just me, or is almost everything about this sentence technically > wrong, except the part about the compiler inferring the variable type? _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Apple today
.. announced Swift, its Objective C replacement (?): http://arstechnica.com/apple/2014/06/apple-shows-off-swift-its-new-programming-language/ https://developer.apple.com/swift/ https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ [see on Harvard PL list] _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28829: master branch updated
On Jun 2, 2014, at 2:06 AM, Jay McCarthy wrote: > Your research suggests that contracts are the only meaningful higher-order > assertions, so this thing is assert/higher-order and the contract DSL is the > right way to specify the condition. I am not sure I would go this far. Suppose you want to insert these 'assert' expressions for the sake of logical verification rather than actual checking. I just don't know whether our work is helpful. See Christos's TOPLAS paper. ;; --- I think the separation of assert from assert/ho is useful from a performance perspective. The former is cheap, the latter imposes a non-trivial, distributed cost. In contrast to contracts, assert/ho avoids the cost of blame calculations. All we need to know when it blows up is which assertion turned out to be wrong. While I am not sure how much cheaper it is to run assertions compared to contract, my hunch is that it is cheaper and that we should keep the option open to opt for this cheaper version. -- Matthias On Jun 2, 2014, at 2:06 AM, Jay McCarthy wrote: > Ok. I thought about what kinds of things might be different in the > future with more understanding and experience using assertions... > > How about this: Start an assert library with two exports, > assert/higher-order and assert. Your research suggests that contracts > are the only meaningful higher-order assertions, so this thing is > assert/higher-order and the contract DSL is the right way to specify > the condition. On the other hand, assert would be like the traditional > one that using expressions. Another name for a/ho would be > assert/contract which might be useful for using contracts for flat > values. (The name though, only communicates mechanism and not the > purpose like h-o.) > > Jay > > On Sun, Jun 1, 2014 at 6:14 PM, Robby Findler > wrote: >> (I must have missed that suggestion, sorry.) >> >> I don't object to the sentiment behind the name, but I feel like we >> have not figured out the best way to do assertions or invariants and >> so we should leave such a valuable name for a future >> contributor/insight and use the more "ugly" name for this one. >> >> Even if that name ends up in a different library, I wouldn't want an >> assertion/invariant library to conflict with racket/contract. >> >> Robby >> >> >> On Sun, Jun 1, 2014 at 6:57 PM, Matthias Felleisen >> wrote: >>> >>> I suggested exactly that name in a private message to Robby. >>> >>> >>> >>> On Jun 1, 2014, at 7:49 PM, Jay McCarthy wrote: >>> >>>> Based on this commit, I feel like "assert" would be a better name than >>>> "invariant-assertion". I can imagine putting these on various internal >>>> parts of a function where the self-blame would be justified. The >>>> (define id (assert ctc e)) pattern is just one common use. >>>> >>>> Jay >>>> >>>> On Sat, May 31, 2014 at 1:46 PM, wrote: >>>>> matthias has updated `master' from 9d94ef725e to 89dea63995. >>>>> http://git.racket-lang.org/plt/9d94ef725e..89dea63995 >>>>> >>>>> =[ One Commit ]= >>>>> Directory summary: >>>>> 84.2% pkgs/racket-pkgs/racket-doc/scribblings/reference/ >>>>> 11.0% racket/collects/racket/contract/private/ >>>>> 4.6% racket/collects/racket/contract/ >>>>> >>>>> ~~ >>>>> >>>>> 89dea63 Matthias Felleisen 2014-05-31 15:45 >>>>> : >>>>> | removed _contract_ language from _invariant-..._ as much as possible >>>>> | >>>>> | added a hint as to why the error message uses the inappropriate >>>>> contract language >>>>> : >>>>> M racket/collects/racket/contract/private/base.rkt | 4 ++-- >>>>> M racket/collects/racket/contract/region.rkt| 2 +- >>>>> M .../scribblings/reference/contracts.scrbl | 22 >>>>> ++-- >>>>> >>>>> =[ Overall Diff ]=== >>>>> >>>>> pkgs/racket-pkgs/racket-doc/scribblings/reference/contracts.scrbl >>>>> ~ >>>>> --- OLD/pkgs/racket-pkgs/racket-doc/scribblings/reference/contracts.scrbl >>>>> +++ NEW/pkgs/racket-pkgs/racket-doc/scribblings/reference/contrac
Re: [racket-dev] [plt] Push #28829: master branch updated
I suggested exactly that name in a private message to Robby.
On Jun 1, 2014, at 7:49 PM, Jay McCarthy wrote:
> Based on this commit, I feel like "assert" would be a better name than
> "invariant-assertion". I can imagine putting these on various internal
> parts of a function where the self-blame would be justified. The
> (define id (assert ctc e)) pattern is just one common use.
>
> Jay
>
> On Sat, May 31, 2014 at 1:46 PM, wrote:
>> matthias has updated `master' from 9d94ef725e to 89dea63995.
>> http://git.racket-lang.org/plt/9d94ef725e..89dea63995
>>
>> =[ One Commit ]=
>> Directory summary:
>> 84.2% pkgs/racket-pkgs/racket-doc/scribblings/reference/
>> 11.0% racket/collects/racket/contract/private/
>> 4.6% racket/collects/racket/contract/
>>
>> ~~
>>
>> 89dea63 Matthias Felleisen 2014-05-31 15:45
>> :
>> | removed _contract_ language from _invariant-..._ as much as possible
>> |
>> | added a hint as to why the error message uses the inappropriate contract
>> language
>> :
>> M racket/collects/racket/contract/private/base.rkt | 4 ++--
>> M racket/collects/racket/contract/region.rkt| 2 +-
>> M .../scribblings/reference/contracts.scrbl | 22
>> ++--
>>
>> =[ Overall Diff ]===
>>
>> pkgs/racket-pkgs/racket-doc/scribblings/reference/contracts.scrbl
>> ~
>> --- OLD/pkgs/racket-pkgs/racket-doc/scribblings/reference/contracts.scrbl
>> +++ NEW/pkgs/racket-pkgs/racket-doc/scribblings/reference/contracts.scrbl
>> @@ -1509,24 +1509,24 @@ The @racket[define-struct/contract] form only allows
>> a subset of the
>> (make-salmon #f 'pacific)
>> ]}
>>
>> -@defform[(invariant-contract contract-expr expr)]{
>> - Establishes an invariant of @racket[expr], determined by
>> @racket[contract-expr].
>> +@defform[(invariant-assertion invariant-expr expr)]{
>> + Establishes an invariant of @racket[expr], determined by
>> @racket[invariant-expr].
>>
>> - Unlike other ways to attach contracts to values, an
>> - @racket[invariant-contract] does not establish a boundary
>> - between two parties. Instead, it simply puts the contract
>> - on the value, treating the module containing the
>> - @racket[invariant-contract] expression as the party to be blamed
>> - for any violations of the contract.
>> + Unlike the specification of a contract, an
>> + @racket[invariant-assertion] does not establish a boundary
>> + between two parties. Instead, it simply attaches a logical assertion
>> + to the value. Because the form uses contract machinery to check the
>> + assertion, the surround module is treated as the party to be blamed
>> + for any violations of the assertion.
>>
>> - This means, for example, that the contract is checked on
>> + This means, for example, that the assertion is checked on
>> recursive calls, when an invariant is used on the right-hand
>> - side of a definition.
>> + side of a definition:
>>
>> @examples[#:eval
>> furlongs->feet-eval
>> (define furlongss->feets
>> - (invariant-contract
>> + (invariant-assertion
>>(-> (listof real?) (listof real?))
>>(λ (l)
>> (cond
>>
>> racket/collects/racket/contract/private/base.rkt
>>
>> --- OLD/racket/collects/racket/contract/private/base.rkt
>> +++ NEW/racket/collects/racket/contract/private/base.rkt
>> @@ -3,7 +3,7 @@
>> (provide contract
>> (rename-out [-recursive-contract recursive-contract])
>> current-contract-region
>> - invariant-contract)
>> + invariant-assertion)
>>
>> (require (for-syntax racket/base syntax/name syntax/srcloc)
>> racket/stxparam
>> @@ -89,7 +89,7 @@
>> (procedure-rename new-val vs-name)])]
>> [else new-val])))
>>
>> -(define-syntax (invariant-contract stx)
>> +(define-syntax (invariant-assertion stx)
>> (syntax-case stx ()
>> [(_ ctc e)
>> (quasisyntax/loc stx
>>
>> racket/collects/racket/contract/region.rkt
>> ~~
>> --- OLD/racket/collects/racket/contract/region.rkt
>> +++ NEW/racket/collects/racket/contract/region.rkt
>> @@ -4,7 +4,7 @@
>> define/contract
>> with-contract
>> current-contract-region
>> - invariant-contract)
>> + invariant-assertion)
>>
>> (require (for-syntax racket/base
>> racket/struct-info
>
>
>
> --
> Jay McCarthy
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28823: master branch updated
Could we please use the language of assertions here?
We have worked hard to get people to see contracts as special
boundary-associated assertions. And it's not clear whether we
are succeeding. But if we don't use language properly, nobody
will.
On May 30, 2014, at 10:06 PM, ro...@racket-lang.org wrote:
> robby has updated `master' from 2eef2ce409 to ddb7477494.
> http://git.racket-lang.org/plt/2eef2ce409..ddb7477494
>
> =[ One Commit ]=
> Directory summary:
> 70.1% pkgs/racket-pkgs/racket-doc/scribblings/reference/
> 25.1% racket/collects/racket/contract/private/
> 4.7% racket/collects/racket/contract/
>
> ~~
>
> ddb7477 Robby Findler 2014-05-30 21:01
> :
> | added invariant-contract
> |
> | Jay implemented this
> :
> M racket/collects/racket/contract/private/base.rkt | 15 ++--
> M racket/collects/racket/contract/region.rkt| 3 +-
> M .../scribblings/reference/contracts.scrbl | 38 ++--
>
> =[ Overall Diff ]===
>
> pkgs/racket-pkgs/racket-doc/scribblings/reference/contracts.scrbl
> ~
> --- OLD/pkgs/racket-pkgs/racket-doc/scribblings/reference/contracts.scrbl
> +++ NEW/pkgs/racket-pkgs/racket-doc/scribblings/reference/contracts.scrbl
> @@ -6,7 +6,7 @@
> @(define contract-eval
>(lambda ()
> (let ([the-eval (make-base-eval)])
> - (the-eval '(require racket/contract racket/contract/parametric))
> + (the-eval '(require racket/contract racket/contract/parametric
> racket/list))
>the-eval)))
>
> @title[#:tag "contracts" #:style 'toc]{Contracts}
> @@ -1430,6 +1430,7 @@ inside the @racket[body] will be protected with
> contracts that
> blame the context of the @racket[with-contract] form for the positive
> positions and the @racket[with-contract] form for the negative ones.}
>
> +@(define furlongs->feet-eval (contract-eval))
> @defform*[[(define/contract id contract-expr free-var-list init-value-expr)
> (define/contract (head args) contract-expr free-var-list body ...+)]]{
> Works like @racket[define], except that the contract
> @@ -1437,7 +1438,7 @@ Works like @racket[define], except that the contract
> definition of @racket[head] and @racket[args], see @racket[define].
> For the definition of @racket[free-var-list], see @racket[with-contract].
>
> -@examples[#:eval (contract-eval)
> +@examples[#:eval furlongs->feet-eval
> (define/contract distance (>=/c 0) 43.52)
> (define/contract (furlongs->feet fr)
> (-> real? real?)
> @@ -1508,6 +1509,39 @@ The @racket[define-struct/contract] form only allows a
> subset of the
> (make-salmon #f 'pacific)
> ]}
>
> +@defform[(invariant-contract contract-expr expr)]{
> + Establishes an invariant of @racket[expr], determined by
> @racket[contract-expr].
> +
> + Unlike other ways to attach contracts to values, an
> + @racket[invariant-contract] does not establish a boundary
> + between two parties. Instead, it simply puts the contract
> + on the value, treating the module containing the
> + @racket[invariant-contract] expression as the party to be blamed
> + for any violations of the contract.
> +
> + This means, for example, that the contract is checked on
> + recursive calls, when an invariant is used on the right-hand
> + side of a definition.
> +
> + @examples[#:eval
> +furlongs->feet-eval
> +(define furlongss->feets
> + (invariant-contract
> + (-> (listof real?) (listof real?))
> + (λ (l)
> + (cond
> + [(empty? l) empty]
> + [else
> +(if (= 327 (car l))
> +(furlongss->feets (list "wha?"))
> +(cons (furlongs->feet (first l))
> + (furlongss->feets (rest l]
> +
> +(furlongss->feets (list 1 2 3))
> +
> +(furlongss->feets (list 1 327 3))]
> +}
> +
> @defidform[current-contract-region]{
> Bound by @racket[define-syntax-parameter], this contains
> information about the current contract region, used by
>
> racket/collects/racket/contract/private/base.rkt
>
> --- OLD/racket/collects/racket/contract/private/base.rkt
> +++ NEW/racket/collects/racket/contract/private/base.rkt
> @@ -2,9 +2,10 @@
>
> (provide contract
> (rename-out [-recursive-contract recursive-contract])
> - current-contract-region)
> + current-contract-region
> + invariant-contract)
>
> -(require (for-syntax racket/base syntax/name)
> +(require (for-syntax racket/base syntax/name syntax/srcloc)
> racket/stxparam
> syntax/srcloc
> syntax/location
> @@ -88,6 +89,16 @@
> (procedure-rename n
Re: [racket-dev] [plt] Push #28817: master branch updated
>> (my-sequence-map add1 (vector 1 2 3)) >> (my-sequence-map add1 (list 1 2 3)) >> >> I would like this to be optimized to: >> (vector-map add1 (vector 1 2 3)) >> (map add1 (list 1 2 3)) >> >> I think this case of code will be very common if we move to a world >> where we work over generic sequences/datastructures, and specializing >> the call sites will be a big win. >> >> TR cannot do this optimization because it requires inlining. And the >> current version of racket cannot optimize this either because it >> becomes >> >> (let ((s (vector 1 2 3))) >> (if (vector? s) >> (vector-map add1 s) >> (map add1 s))) >> >> Which isn't optimized because when we see (vector? s) we don't know >> that s is a vector as Mathew's change only works if the constructor is >> inline (i.e. of the form (vector? (vector 1 2 3))). Cases like this >> make me think that we need something stronger than context free >> rewrite rules over the ast/bytecode. >> >> >> On Wed, May 28, 2014 at 6:36 PM, Matthias Felleisen >> wrote: >>> >>> Perhaps the right answer is to organize the optimizer >>> as a rewriting engine to which other devs can add rules >>> as they discover them (and their absence in the existing >>> rule set). -- Indeed, one could then even have programmers >>> extend the rule set for a specific program (though then >>> we have to worry about soundness). With syntax-* we should >>> have no problem formulating the mostly context-free rules >>> and we could figure out in addition how to keep track of >>> contexts. (This is the other half of what we used to call >>> the 'open compiler' idea at Rice.) >>> >>> -- Matthias >>> >>> >>> >>> >>> On May 28, 2014, at 9:25 PM, Sam Tobin-Hochstadt wrote: >>> >>>> On Thu, May 29, 2014 at 4:26 AM, wrote: >>>>> >>>>> | optimizer: ad hoc optimization of predicates applied to constructions >>>>> | >>>>> | This is probably more of a job for Typed Racket, but maybe it's >>>>> | useful to detect some obviously unnecessary allocations of lists, etc. >>>> >>>> I think this is a useful discussion to have. I think there are two >>>> questions to answer: >>>> >>>> 1. Do we want people to need to use a particular language for greater >>>> optimization, whether that's Typed Racket or some other optimizer? >>>> >>>> 2. How should we optimize the code that Typed Racket depends on? >>>> Since this is a finite amount, we could manually do this, but we might >>>> not want to. >>>> >>>> Of course, in the absence of other constraints, it would be great to >>>> have infinite optimizations at every level. But in our actual setting, >>>> I don't know what I think the answer to either of these questions is. >>>> >>>> Sam >>>> _ >>>> Racket Developers list: >>>> http://lists.racket-lang.org/dev >>> _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28817: master branch updated
Perhaps the right answer is to organize the optimizer as a rewriting engine to which other devs can add rules as they discover them (and their absence in the existing rule set). -- Indeed, one could then even have programmers extend the rule set for a specific program (though then we have to worry about soundness). With syntax-* we should have no problem formulating the mostly context-free rules and we could figure out in addition how to keep track of contexts. (This is the other half of what we used to call the 'open compiler' idea at Rice.) -- Matthias On May 28, 2014, at 9:25 PM, Sam Tobin-Hochstadt wrote: > On Thu, May 29, 2014 at 4:26 AM, wrote: >> >> | optimizer: ad hoc optimization of predicates applied to constructions >> | >> | This is probably more of a job for Typed Racket, but maybe it's >> | useful to detect some obviously unnecessary allocations of lists, etc. > > I think this is a useful discussion to have. I think there are two > questions to answer: > > 1. Do we want people to need to use a particular language for greater > optimization, whether that's Typed Racket or some other optimizer? > > 2. How should we optimize the code that Typed Racket depends on? > Since this is a finite amount, we could manually do this, but we might > not want to. > > Of course, in the absence of other constraints, it would be great to > have infinite optimizations at every level. But in our actual setting, > I don't know what I think the answer to either of these questions is. > > Sam > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28706: master branch updated
It was called option/c until we did option contracts. (All of this just shows that contracts are not written in the programming language proper, contrary to our propaganda.) On May 8, 2014, at 10:29 PM, Robby Findler wrote: > add1 is fine compared to (+ ... 1), imo, because the name tells you > what it is doing, but maybe/c doesn't. It just sends the signal "you > aren't in the club if you don't know what 'maybe' is". Maybe if there > was another name that made that meaning clear I would also be in > favor. > > Robby > > On Thu, May 8, 2014 at 7:34 PM, Matthias Felleisen > wrote: >> >> I think maybe signals a well-known functional idea. >> >> >> On May 8, 2014, at 8:03 PM, Robby Findler wrote: >> >>> (or/c #f x) >>> >>> seems better than maybe/c because it is nearly the same length and it >>> is one less thing to memorize (and it's not like single-point of >>> control applies here because this can never change). >>> >>> Robby >>> >>> On Thu, May 8, 2014 at 6:17 PM, Matthias Felleisen >>> wrote: >>>> >>>> (We have maybe/c somewhere, and I think we should use it.) >>>> >>>> >>>> On May 8, 2014, at 4:19 PM, sa...@racket-lang.org wrote: >>>> >>>>> samth has updated `master' from 98ae3d8b2d to e1ab2ffcf4. >>>>> http://git.racket-lang.org/plt/98ae3d8b2d..e1ab2ffcf4 >>>>> >>>>> =[ One Commit ]= >>>>> Directory summary: >>>>> 100.0% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/infer/ >>>>> >>>>> ~~ >>>>> >>>>> e1ab2ff Sam Tobin-Hochstadt 2014-05-08 16:18 >>>>> : >>>>> | Fix contract. >>>>> | >>>>> | First bug caught with new test. Thanks Robby! >>>>> : >>>>> M .../typed-racket-lib/typed-racket/infer/infer-unit.rkt | 2 +- >>>>> >>>>> =[ Overall Diff ]=== >>>>> >>>>> pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/infer/infer-unit.rkt >>>>> ~ >>>>> --- >>>>> OLD/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/infer/infer-unit.rkt >>>>> +++ >>>>> NEW/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/infer/infer-unit.rkt >>>>> @@ -360,7 +360,7 @@ >>>>> (Type/c Type/c . -> . (or/c #f cset?)) >>>>> (cgen V X Y S T)) >>>>> (define/cond-contract (cg/inv S T) >>>>> - (Type/c Type/c . -> . cset?) >>>>> + (Type/c Type/c . -> . (or/c #f cset?)) >>>>> (cgen/inv V X Y S T)) >>>>> ;; this places no constraints on any variables in X >>>>> (define empty (empty-cset X Y)) >>>> >>>> >>>> _ >>>> Racket Developers list: >>>> http://lists.racket-lang.org/dev >> _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28706: master branch updated
I think maybe signals a well-known functional idea. On May 8, 2014, at 8:03 PM, Robby Findler wrote: > (or/c #f x) > > seems better than maybe/c because it is nearly the same length and it > is one less thing to memorize (and it's not like single-point of > control applies here because this can never change). > > Robby > > On Thu, May 8, 2014 at 6:17 PM, Matthias Felleisen > wrote: >> >> (We have maybe/c somewhere, and I think we should use it.) >> >> >> On May 8, 2014, at 4:19 PM, sa...@racket-lang.org wrote: >> >>> samth has updated `master' from 98ae3d8b2d to e1ab2ffcf4. >>> http://git.racket-lang.org/plt/98ae3d8b2d..e1ab2ffcf4 >>> >>> =[ One Commit ]= >>> Directory summary: >>> 100.0% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/infer/ >>> >>> ~~ >>> >>> e1ab2ff Sam Tobin-Hochstadt 2014-05-08 16:18 >>> : >>> | Fix contract. >>> | >>> | First bug caught with new test. Thanks Robby! >>> : >>> M .../typed-racket-lib/typed-racket/infer/infer-unit.rkt | 2 +- >>> >>> =[ Overall Diff ]=== >>> >>> pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/infer/infer-unit.rkt >>> ~ >>> --- >>> OLD/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/infer/infer-unit.rkt >>> +++ >>> NEW/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/infer/infer-unit.rkt >>> @@ -360,7 +360,7 @@ >>> (Type/c Type/c . -> . (or/c #f cset?)) >>> (cgen V X Y S T)) >>> (define/cond-contract (cg/inv S T) >>> - (Type/c Type/c . -> . cset?) >>> + (Type/c Type/c . -> . (or/c #f cset?)) >>> (cgen/inv V X Y S T)) >>> ;; this places no constraints on any variables in X >>> (define empty (empty-cset X Y)) >> >> >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28706: master branch updated
(We have maybe/c somewhere, and I think we should use it.) On May 8, 2014, at 4:19 PM, sa...@racket-lang.org wrote: > samth has updated `master' from 98ae3d8b2d to e1ab2ffcf4. > http://git.racket-lang.org/plt/98ae3d8b2d..e1ab2ffcf4 > > =[ One Commit ]= > Directory summary: > 100.0% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/infer/ > > ~~ > > e1ab2ff Sam Tobin-Hochstadt 2014-05-08 16:18 > : > | Fix contract. > | > | First bug caught with new test. Thanks Robby! > : > M .../typed-racket-lib/typed-racket/infer/infer-unit.rkt | 2 +- > > =[ Overall Diff ]=== > > pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/infer/infer-unit.rkt > ~ > --- > OLD/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/infer/infer-unit.rkt > +++ > NEW/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/infer/infer-unit.rkt > @@ -360,7 +360,7 @@ >(Type/c Type/c . -> . (or/c #f cset?)) >(cgen V X Y S T)) > (define/cond-contract (cg/inv S T) > - (Type/c Type/c . -> . cset?) > + (Type/c Type/c . -> . (or/c #f cset?)) >(cgen/inv V X Y S T)) > ;; this places no constraints on any variables in X > (define empty (empty-cset X Y)) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] "lab notebook on learning process" (was: Re: Macros baffle me)
On May 6, 2014, at 2:02 PM, Jens Axel Søgaard wrote: > How about an extra button, a "Run Benchmark" button? +ω _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] make-empty-namespace vs make-base-empty-namespace; ie attaching racket/base does other "stuff"
I think improvements would be welcome. Start with a redex model. On Apr 29, 2014, at 3:15 PM, Stephen Chang wrote: > Thanks for the explanation. It all does make sense. > > I guess I'm still unsatisfied because it still feels like there's a > gap between the namespace "model" as presented by the docs and what > actually happens. For example, the docs give me the impression that > you can't require a module unless it's already declared [1]. > > In general, I feel that certain terms, eg, namespace, attach, declare, > instantiate, should have precise technical meanings but are used > imprecisely in the docs so that I can't form a proper mental model. > For example, is possible to say "makes it possible to load "m.rkt"" > using the terminology of the docs? Is there ever a state where "m.rkt" > is "declared" but not "instantiated"? > > I'm willing to work to improve these parts of the docs to make things > more consistent (if others agree that improvements are needed). > > [1]: > http://docs.racket-lang.org/reference/eval-model.html#%28part._module-eval-model%29 > > On Mon, Apr 28, 2014 at 8:06 PM, Matthew Flatt wrote: >> If you start with an empty namespace, then the handful of primitive >> modules needed to bootstrap `racket/base` are not there. Attaching >> `racket/base` doesn't make "m.rkt" available, but it makes it possible >> to load "m.rkt", after which "m.rkt" will be declared in the namespace. >> >> It's not a matter of initializing the module name resolver, which is >> not attached to a namespace. It's just a question of having the >> necessary primitive modules declared in a namespace. >> >> The `'#%builtin` module imports all the primitive modules needed to >> bootstrap `racket/base` --- that's its job --- while neither >> `'#%kernel` nor `'#%boot` reach all of the needed primitive modules. >> >> Ideally, you wouldn't be able to access any of those modules whose >> names start "'#%", because you shouldn't use them. I don't know how to >> hide the modules from you without also hiding them from `racket/base`. >> >> >> When I try >> >> (parameterize ([current-namespace (make-base-empty-namespace)]) >> (namespace-require "m.rkt") >> (module-declared? "m.rkt")) >> >> then I get #t back, so I'm not sure why you were getting #f... unless >> you tried >> >> (parameterize ([current-namespace (make-base-empty-namespace)]) >> (namespace-require "m.rkt")) >> (module-declared? "m.rkt") >> >> which would produce #f, because `module-declared?` consults the current >> namespace. >> >> At Mon, 28 Apr 2014 16:48:04 -0400, Vincent St-Amour wrote: >>> Extra bit of information, this works too: >>> >>>#lang racket >>>(define ns (make-empty-namespace)) >>>(namespace-attach-module (current-namespace) ''#%builtin ns) >>>(parameterize ([current-namespace ns]) >>> (namespace-require "m.rkt")) >>> >>> But replacing ''#%builtin with ''#%kernel or ''#%boot doesn't. Replacing >>> it with 'racket/base (to end up with the equivalent of >>> `make-base-empty-namespace') does work. >>> >>> Vincent >>> >>> >>> >>> At Mon, 28 Apr 2014 16:38:24 -0400, >>> Stephen Chang wrote: Motivated by some recent email threads, I decided to better understand how Racket namespaces work by re-reading some docs but I got confused. Paraphrasing the examples from this part of the guide: http://docs.racket-lang.org/guide/mk-namespace.html the following example fails because the module registry in the namespace is empty: (parameterize ([current-namespace (make-empty-namespace)]) (namespace-require "m.rkt")) ; error But the example works if make-base-empty-namespace is used instead: (parameterize ([current-namespace (make-base-empty-namespace)]) (namespace-require "m.rkt")) ; works (Assume the contents of m.rkt is "#lang racket/base" with nothing else.) According to the docs, make-base-empty-namespace "attaches" racket/base but why does this make "m.rkt" suddenly "available"? There seems to be an unexplained gap between to the two examples. (Adding to my confusion is that (module-declared? "m.rkt") evaluates to false, even in the 2nd case.) With help from Vincent, we investigated and speculate that perhaps attaching racket/base also runs "boot" from '#%boot, which populates current-module-name-resolver, but could not conclude anything definitively. Can someone explain what's happening? _ Racket Developers list: http://lists.racket-lang.org/dev >>> _ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] actionable items, was: comments on "comments on learning Racket"
Time to move it to a place easy to find? But why a macro? On Apr 28, 2014, at 1:10 PM, Ryan Culpepper wrote: > On 04/28/2014 10:08 AM, Laurent wrote: >> On Mon, Apr 28, 2014 at 3:47 PM, Matthias Felleisen >> mailto:matth...@ccs.neu.edu>> wrote: >> [...] >> >> Why not something like `apply->list` or `apply/list`? >> (personally I usually call it `cvl` for call/values->list, but that's >> because I often use it on the command line, which makes going from `(foo >> 'a 'b 'c)` to `(cvl foo 'a 'b 'c)` effortless) >> >> (define (nth-return-value i f . s) >> (call-with-values >>(lambda () (apply f s)) >>(lambda l (list-ref l i > > unstable/list has an unexported 'values->list' macro that takes an expression > and returns the list of values it produces. > > Ryan > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Refactoring Idea
This is one of those places where our desire to not include extra-linguistic mechanisms conflicts with our desire to support our programmers. I have had this idea many times, as I am sure have many others and Jens probably had it tons of times over the years. Even a package isn't enough because one might have client modules somewhere else. On Apr 28, 2014, at 11:03 AM, Robby Findler wrote: > I guess this would work best if DrRacket were given a package (and it > could infer the current package from the location of the file being > edited). > > So if someone wants to implement a function that, given a package spec > and a renaming and then does the work, I'd be happy to try to > integrate it into DrRacket proper. Also: "does the renaming" should > mean rewrite the files on the disk and rewrite the files that are open > in DrRacket and there is some interesting questions when the file is > open and the save file isn't up to date. DrRacket can easily supply a > list of text% objects that correspond to open files, however (and they > can be queried to find out if they are saved or what their content is, > etc). > > Robby > > On Mon, Apr 28, 2014 at 9:40 AM, Jens Axel Søgaard > wrote: >> From time to time the topic of refactoring pop up on the mailing list. >> >> Here is one feature I'd like: >>After renaming an exported identifier in a module foo, >>any references to the identifier in external modules need >>to be renamed too. DrRacket could after renaming in foo is done, >> ask for a folder in which to search for module that require foo and >> rename the identifier in those modules. >> >> >> -- >> Jens Axel Søgaard >> >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] actionable items, was: comments on "comments on learning Racket"
I withdraw my support for this item. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] actionable items, was: comments on "comments on learning Racket"
SAM: > Also, I think that in almost every course using DrRacket, the students > will need to learn how to choose languages, because they will switch > from one teaching language to the next. So I think this won't be > unfriendly. I am not sure this is true for simple high school courses or anyone who wants to run Bootstrap 2 off-line. LAURENT: > o Are you a student learning to program? > o Are you an experienced programmer learning to use Racket? > (why "/learning/ to use Racket"? I could well be that s/he's on a new > machine) > > Why not simply "Choose a language" and give a list of the usual ones with > explanations? 1. Yes, the second question is wrong. We need a better formulation, something like "Do you want to create a #lang module?" I like this question because (a) most students will obviously know not to say 'yes' here. I like it also because the 'know it all's among the students will be intrigued by #lang. 2. From what I recall, we popped up the "Choose a language" dialogue until we decided to go for the current solution. That didn't work. I think two simple, plain English questions will work best. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] actionable items, was: comments on "comments on learning Racket"
On Apr 28, 2014, at 9:51 AM, Robby Findler wrote: > So you are asking to go back to the way it was before we added the "not a > language" language? I don't think we asked simple questions like that. We popped up the dialogue itself, no? _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] actionable items, was: comments on "comments on learning Racket"
So far we have had two threads of reactions to my 'comments on comments.' They have produced requests that I consider actionable items though I have counter-proposal to some of them. The list below does not include other actionable items I had on my list that did not get comments. With credit: * SAM suggests to always start in #lang racket. Tell students to switch to #lang htdp/bsl or use Choose Language. I think this is plain unfriendly to our largest audience. Here is my counter-proposal: when drracket starts w/o a preference file, we pop up a radio menu: o Are you a student learning to program? o Are you an experienced programmer learning to use Racket? Depending on which bullet the person checks, drracket starts in BSL [#lang htdp/bsl, one day soon] or #lang racket. * LAURENT asks for: ~~ faster re-indentation of last files. Will pre-computations help or is the display on the screen the bottleneck? ~~ the language selection menu should also be available from the general preference dialog ~~ the following MV functions: ~~ what names should they receive? ~~ where should they and their tests go? ;; (X ... -> Y ...) X *-> [List-of Y] ;; gather the return MVs from (apply f s) in a list (module+ test (check-equal? (gather-return-values (lambda () (values 1 2))) (list 1 2)) (check-equal? (gather-return-values (lambda (x) (values 1 x)) 2) (list 1 2)) (check-equal? (gather-return-values (lambda (x y) (values y x)) 2 1) (list 1 2))) (define (gather-return-values f . s) (call-with-values (lambda () (apply f s)) list)) ;; Nat (X ... -> Y ...) X *-> Y ;; pick the i-th return value from a bunch of MVs (module+ test (check-equal? (nth-return-value 0 (lambda () (values 1 2))) 1) (check-equal? (nth-return-value 0 (lambda (x) (values 1 x)) 2) 1) (check-equal? (nth-return-value 0 (lambda (x y) (values y x)) 2 1) 1)) (define (nth-return-value i f . s) (call-with-values (lambda () (apply f s)) (lambda l (list-ref l i ~~ macros should come with 'meta information' such as indentation; sub-modules may enable this; probably a research topic (well, I no longer have a macrologist in the group) _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] comments on "comments on learning Racket"
I have been re-reading the notes on Artyom.me's site, taking notes. Few
question his comments, some suggest reactions that should come from us, others
are personal musings.
I know this is a bit of a brain dump but I find this person's thoughts
worthwhile for us (devs).
Notes on "Learning Racket" by Artyom
How to get a Haskellian like Artyom to fall in love with Racket at first sight.
;; -
** What does it mean to say ", or get guidance"?
Where should people get guidance? What about?
Avoid useless words.
** The REPL section in the Guide must open with (+ 1 1)
** tab completion must be faster
** can we force the help corner[1] to show up for "beginners"?
(the first five hours of using a raw DrRacket or you pay us 50 bucks.)
The WOW #2 should come right away.
** can we get the help corner to show up for things at the DrRacket repl?
** How can we get the help corner show anything about module-locally defined
identifiers ("defined in this module" would be a good start) or imported
identifiers ("imported from module X") and if it goes thru a contract-out,
the help corner may even say something ("with contract (-> integer?
integer?)")
?? I don't get the "Uniform syntax is harder to read" comment. More
highlighting, hmph?
** do we need to get across racket/base more quickly?
(so that a hello world program executable looks smaller.)
[:~/Tmp] matthias% du helloworld
1664helloworld
** "This chapter [1 of Guide] was small and boring. Next, please!"
We need to spice up the first chapter of
!! HAH! The Undefined value shows up in his blog, not even half way down.
** Should we provide a 'where' form?
** He wants an Arc-style lambda function. Hmph.
?? How did the kid get (apply and ...) to work? Was I asleep?
(( He doesn't know what type safety is. I understand that C++ers don't get
it. Why do Haskellians don't get it? ))
** People want overloading. (< "hello" "hello world") should work. Hmph.
** When we introduce for/list we should explain it directly, in words.
** I do get jealous when I see
[(i, j, k) | i <- [1..10], j <- [i..10], k <- [j..10], i^2 + j^2 == k^2]
vs
(for*/list ([i (range 1 20)] [j (range i 20)] [k (range j 20)] #:when (= (+
(sqr i) (sqr j)) (sqr k)))
(list i j k))
(using full width according to Racket style)
** The time-is-not-a-procedure thing is two misunderstandings in one:
-- we are in a by-value world
-- by the time were to reach the calls to factorial, it's evaluated
Show
(for ((f (list f1 f2 f3 f4)))
(time (f 1)))
early?
** Do we need to add these to our library?
;; (X ... -> Y ...) X *-> [List-of Y]
(define (gather-return-values f . s)
(call-with-values (lambda () (apply f s)) list))
;; Nat (X ... -> Y ...) X *-> Y
(define (nth-return-value i f . s)
(call-with-values (lambda () (apply f s)) (lambda l (list-ref l i
** Printing is brutally expensive in DrRacket. Is there a way to make it
cheaper?
** Why does he think "Performance sucks"?
** What is this about:
"Support for functional paradigm is somewhere in the middle. Everything
needed is there, but it's not very convenient to use. (I expect to stumble
upon goodies/fp or haskell-racket module one day, but for now I won't be
looking for it – I need to understand Racket's main paradigm before
allowing myself to consciously deviate from it.)"
I am thinking of Racket as FP.
** This
"Given that reading every chapter of TRG raises lots of questions and
provokes endless tinkering with not-quite-related concepts, I'll be
happy if I manage to read as much as chapter 2.4."
means the Guide is the wrong kind of introduction for a functional
Haskellian.
** quote and friends should not show up in whatever replaces Guide for
Functionalists
;; -
[1] What do we call the thing that shows up at the top right?
;; =
PART II
** "I see."
Some of our error messages are, well, real-world error messages. Like all
compilers, they assume complete knowledge of the languages so when a novice
makes a mistake, he gets, well, nothing out of it.
Should we try our hands on a staged approach to learning the API for our
world of syntax and compilation? (Old people would use the word 'macro'
here.)
** "Why, why must everything be Inferior By Default?"
We obviously need a 'syntax story' that takes readers directly from
define-syntax-rule to syntax-parse, bringing in hygiene only late, when it
truly matters to raise expressiveness
Further down he writes "But, but... It's wrong to spend a day hopping around
only to write this. It's unsatisfactory. Things like this turn people into
Hulks, y'know." Boy is he corr
Re: [racket-dev] pi, was: Re: [plt] Push #28592: master branch updated
Kate Bush's song contains more digits of PI than your commit. What does Bagger 288 do for Racket commits? :-) On Apr 22, 2014, at 1:55 PM, Neil Van Dyke wrote: > Matthias Felleisen wrote at 04/22/2014 01:37 PM: >> I think we should dedicate this commit to Kate Bush's PI song (or vice >> versa?): >> >> https://www.youtube.com/watch?v=kZSHr5E7fZY > > Are Kate Bush dedications a slippery slope? Software developers will tend to > work towards the metrics. Soon the canonical Kate Bush catalog gets > exhausted, and some desperate programmer winds up coding Bagger 288. > http://www.youtube.com/watch?v=azEvfD4C6ow > > Neil V. > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] pi, was: Re: [plt] Push #28592: master branch updated
On Apr 22, 2014, at 12:48 PM, ntoro...@racket-lang.org wrote: > racket/collects/racket/extflonum.rkt > > --- OLD/racket/collects/racket/extflonum.rkt > +++ NEW/racket/collects/racket/extflonum.rkt > @@ -6,10 +6,12 @@ > (for-syntax racket/base)) > > (provide (all-from-out '#%extfl) > - > + pi.t > in-extflvector for/extflvector for*/extflvector > extflvector-copy) > > +(define pi.t 3.1415926535897932385t0) > + I think we should dedicate this commit to Kate Bush's PI song (or vice versa?): https://www.youtube.com/watch?v=kZSHr5E7fZY _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Regular expression types [was Re: [racket-bug] all/14455: wrong type for hash]
Sorry guys, I had something different in mind. When I ask people to port my typical 'Hell' code, I tend to suggest that all XML-related code should stay in Untyped. In most cases this kind of S-expression manipulation is hairy from an ordinary TR pov but has a simple interface to the Typed world. It really is a case where typed-untyped cooperation shines. But eventually such pieces of code should/could be typed too. For those cases, the XML type systems that Sam mentioned are ideal and one day we may wish to develop a TR+XML (Xduce?) combination. On Apr 20, 2014, at 3:06 PM, Eric Dobson wrote: > Asumu has a rough draft of a commit that would allow this to work, I > don't know the current status though. > > https://github.com/plt/racket/pull/564 > > I was thinking about the problem and I think our current union types > and recursive types covers a lot of ground. > > For example as one user wanted to do, exactly one vector and bunch of > numbers: (Rec T (U (Cons (Vectorof Real) (Listof Real)) (Cons Real > T))). > > > On Sun, Apr 20, 2014 at 11:38 AM, Matthias Felleisen > wrote: >> >> This might be one of those areas where we could 'generalize' gradual typing. >> >> >> On Apr 19, 2014, at 7:37 PM, Sam Tobin-Hochstadt wrote: >> >>> On Sat, Apr 19, 2014 at 7:24 PM, Neil Toronto >>> wrote: >>>> Are there type systems that can? It seems like you could specify this type >>>> and similar ones using regular expressions. >>> >>> There is lots of work on types for XML specification that can handle >>> this sort of thing, I believe, but not specifically in the context of >>> function arguments. >>> >>> Note that TR can handle alternating types just fine in lists, for >>> example -- it's just that the function argument sequence is different. >>> >>> Sam >>> _ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev >> >> >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Regular expression types [was Re: [racket-bug] all/14455: wrong type for hash]
This might be one of those areas where we could 'generalize' gradual typing. On Apr 19, 2014, at 7:37 PM, Sam Tobin-Hochstadt wrote: > On Sat, Apr 19, 2014 at 7:24 PM, Neil Toronto wrote: >> Are there type systems that can? It seems like you could specify this type >> and similar ones using regular expressions. > > There is lots of work on types for XML specification that can handle > this sort of thing, I believe, but not specifically in the context of > function arguments. > > Note that TR can handle alternating types just fine in lists, for > example -- it's just that the function argument sequence is different. > > Sam > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Implementation question
Here is a more Racket-y version of this: #lang racket (define (ping hostname port-no personalip) (define c (make-custodian)) (define t (parameterize ((current-custodian c)) (thread (lambda () (with-handlers ((exn:fail:network? (lambda (x) (printf "~a:~a ~a\n" hostname port-no " NO" (define-values (in out) (tcp-connect hostname port-no)) (write "'ping" out) (write personalip out) (flush-output out) (printf "~a:~a ~a\n" hostname port-no (read in))) (sync/timeout 0.01 t) (custodian-shutdown-all c)) On Apr 20, 2014, at 10:41 AM, nicolas carraggi wrote: > Hey guys, > > Thanks a lot for your quick answers! > > My ping method now: > > (define (ping hostname port-no personalip) > (define t (thread > (lambda () >(with-handlers ((exn:fail:network? (lambda (x) (begin > (displayln (string-append hostname ":" (number->string port-no) " > NOO")) #f;(displayln (exn-message x) > (define-values (in out) (tcp-connect hostname port-no)) > (write "'ping" out) > (write personalip out) > (flush-output out) > (display (string-append hostname ":" (number->string > port-no) " ")) > (displayln (read in)) > (close-input-port in) > (close-output-port out) > #t > (sync/timeout 0.01 t) > (kill-thread t)) > > + > > This is the result when I do a multicast from 192.168.1.0 to 192.168.1.200. ( > a lot of these don't exist and that's why tcp-connect was taking ages to > throw an error.) Those returning a NO are existing network nodes where no > server is running. Pong is the answer from the server running on my laptop. > > > (multicast-ping "192.168.1.100" 8080 0 200) > 192.168.1.0:8080 NOO > 192.168.1.105:8080 NOO > 192.168.1.108:8080 pong > --- > Multicast finished! > > + > > > It's still test-code but it's working fine now, maybe the timout time is too > small but now it works well! > > Greetings, > Nicolas > > Subject: Re: [racket-dev] Implementation question > From: matth...@ccs.neu.edu > Date: Sat, 19 Apr 2014 09:25:27 -0400 > CC: nicocarra...@hotmail.com; dev@racket-lang.org > To: laurent.ors...@gmail.com > > > Let me recommend events instead: > > #lang racket > > ;; Nat -> Void > ;; wait for t seconds before connecting to google.com, then stop > (define (do-work t) > (thread >(lambda () > (with-handlers ((exn:fail:network? (lambda (x) (displayln (exn-message > x) >(sleep t) >(define-values (in out) (tcp-connect "google.com" 80)) >'done > > ;; returns #f if 3 seconds pass w/o the thread shutting down > (sync/timeout 3 (do-work (random 6))) > > > > On Apr 19, 2014, at 8:34 AM, Laurent wrote: > > One simpler possibility is to use `tcp-connect/enable-break` and run a timer > in parallel to break it after a shorter delay. > For example: > > (define-values (in out) (values #f #f)) > > (define connect-thread > (thread >(λ()(set!-values (in out) > (tcp-connect "www.google.com" 80) > > (sleep 3) > (unless in > (displayln "Connection not established. Breaking thread.") > (break-thread connect-thread)) > > The timer can also be place into its own thread if you need to set up several > connections in parallel. > > Hope this helps, > Laurent > > > On Thu, Apr 17, 2014 at 6:48 PM, nicolas carraggi > wrote: > Hello, > > I am actually using "Racket/tcp" for a project in Racket. > I'm creating a peer-to-peer network but now I encountered a small problem. > For a multicast I want to connect with each server on the same network. > For this I use "tcp-connect", but when i try to connect to an ip address > which is not hosting a server, throwing the error only happens after more > than 1 minute. So I would like to use a modified "tcp-connect" with a smaller > time-out. > > Where can I find the implementation of "tcp-connect"? > > I already found "tcp.rkt" but there it gets the "tcp-connect" method from > "'#%network" but I can't find this one... > > Greetings! > Nicolas > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
On Apr 19, 2014, at 5:57 PM, Sam Tobin-Hochstadt wrote: > On Sat, Apr 19, 2014 at 4:45 PM, Matthias Felleisen > wrote: >> >> Morally TR ought to report the type of this x as empty set, >> which would inform you that the else branch is unreachable: >> >> (letrec ([x : Integer (if #t 0 x)]) x) > > I don't think that's right -- the else branch is unreachable, but > that's not a fact about the type of `x` in particular, any more than > it's a fact about the type of `+` if it was used in the else branch. Correct! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
Morally TR ought to report the type of this x as empty set, which would inform you that the else branch is unreachable: (letrec ([x : Integer (if #t 0 x)]) x) One day we may wish to augment syntax check in TR so that programmers can read of the reconstructed types for interior expressions. -- Matthias On Apr 19, 2014, at 3:26 PM, Robby Findler wrote: > Ah. There are other approaches to this problem that result in > compile-time errors for such programs. Maybe the TR guys will adopt > one or figure out a better one! But for regular ole Racket, we're > stuck with a runtime error, I'm afraid. > > Robby > > On Sat, Apr 19, 2014 at 2:04 PM, Gustavo Massaccesi > wrote: >>>> (letrec ([x (if #t 8 x)]) x) ;==>8 >> >> It was a mistake. I thought that the “x: undefined; ...” error was an >> expansion-time error, not a run-time error. >> >> (I expected an error, because the x in the else part is “undefined”, >> even if it’s never accessed.) >> >> Gustavo >> >> >> On Sat, Apr 19, 2014 at 1:02 PM, Robby Findler >> wrote: >>> These seem correct to me. What were you expecting (and why?). >>> >>> Robby >>> >>> >>> On Saturday, April 19, 2014, Gustavo Massaccesi wrote: >>>> >>>> I found another problem with the optimizer and the new undefined behavior. >>>> >>>> (letrec ([x (if #t 8 x)]) x) ;==>8 >>>> >>>> I also consider this correct in a strange sense :). >>>> >>>> Gustavo >>>> >>>> >>>> Welcome to Racket v6.0.1.4. >>>>> (letrec ([x x]) x) >>>> x: undefined; >>>> cannot use before initialization >>>> context...: >>>> C:\Program Files\Racket-6.0.1.4\collects\racket\private\misc.rkt:87:7 >>>>> (letrec ([x 5]) x) >>>> 5 >>>>> (letrec ([x (if #t 8 x)]) x) >>>> 8 >>>>> (letrec ([x (if #f 8 x)]) x) >>>> x: undefined; >>>> cannot use before initialization >>>> context...: >>>> C:\Program Files\Racket-6.0.1.4\collects\racket\private\misc.rkt:87:7 >>>>> >>>> >>>> >>>> On Wed, Apr 16, 2014 at 10:09 AM, Matthias Felleisen >>>> wrote: >>>>> >>>>> Ah, too bad: >>>>> >>>>>> pkgs/racket-pkgs/racket-test/tests/racket/optimize.rktl >>>>>> ~~~ >>>>>> --- OLD/pkgs/racket-pkgs/racket-test/tests/racket/optimize.rktl >>>>>> +++ NEW/pkgs/racket-pkgs/racket-test/tests/racket/optimize.rktl >>>>>> @@ -3416,5 +3416,16 @@ >>>>>> (read (open-input-bytes (get-output-bytes o)) >>>>>> >>>>>> ;; >>>>>> +;; Check that an unsufe opertion's argument is >>>>>> +;; not "optimized" away if it's a use of >>>>>> +;; a variable before definition: >>>>>> + >>>>>> +(err/rt-test (let () >>>>>> + (unsafe-fx+ x 1) >>>>>> + (define x 3) >>>>>> + x) >>>>>> + exn:fail:contract:variable?) >>>>>> + >>>>>> +;; >>>>> >>>>> >>>>> :-) >>>>> >>>>> On Apr 16, 2014, at 9:02 AM, Matthias Felleisen >>>>> wrote: >>>>> >>>>>> >>>>>> On Apr 15, 2014, at 9:29 PM, Asumu Takikawa wrote: >>>>>> >>>>>>> On 2014-04-15 18:13:31 -0400, claire alvis wrote: >>>>>>>> The push below includes changes to letrec expressions, internal >>>>>>>> definitions, units, classes, and certain ill-formed shared >>>>>>>> expressions so >>>>>>>> that they no longer leak the `undefined' value. >>>>>>> >>>>>>> This is great! (especially happy that TR, even with classes, doesn't >>>>>>> have to worry about # anymore) >>>>>>> >>>>>>> BTW, I found this weird behavior: >>>>>>> >>>>>>> Welcome to Racket v6.0.1.3. >>>>>>> -> (require racket/unsafe/ops) >>>>>>> -> (let () (+ x 3) (define x 3) 5) >>>>>>> ; x: variable used before its definition [,bt for context] >>>>>>> -> (let () (unsafe-fx+ x 3) (define x 3) 5) >>>>>>> 5 >>>>>> >>>>>> >>>>>> I consider this correct in a strange sense. >>>>>> >>>>>> Interestingly enough, >>>>>> >>>>>>> (let () (displayln (unsafe-fx+ x 3)) (define x 3) 5) >>>>>> x: variable used before its definition >>>>>> context...: >>>>>> /Users/matthias/plt/racket/collects/racket/private/misc.rkt:87:7 >>>>>> >>>>>> which is good too. I don't know how Claire and Matthew did this, >>>>>> but it's good :-) >>>>>> _ >>>>>> Racket Developers list: >>>>>> http://lists.racket-lang.org/dev >>>>> >>>>> _ >>>>> Racket Developers list: >>>>> http://lists.racket-lang.org/dev >>>> _ >>>> Racket Developers list: >>>> http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Implementation question
Let me recommend events instead: #lang racket ;; Nat -> Void ;; wait for t seconds before connecting to google.com, then stop (define (do-work t) (thread (lambda () (with-handlers ((exn:fail:network? (lambda (x) (displayln (exn-message x) (sleep t) (define-values (in out) (tcp-connect "google.com" 80)) 'done ;; returns #f if 3 seconds pass w/o the thread shutting down (sync/timeout 3 (do-work (random 6))) On Apr 19, 2014, at 8:34 AM, Laurent wrote: > One simpler possibility is to use `tcp-connect/enable-break` and run a timer > in parallel to break it after a shorter delay. > For example: > > (define-values (in out) (values #f #f)) > > (define connect-thread > (thread >(λ()(set!-values (in out) > (tcp-connect "www.google.com" 80) > > (sleep 3) > (unless in > (displayln "Connection not established. Breaking thread.") > (break-thread connect-thread)) > > The timer can also be place into its own thread if you need to set up several > connections in parallel. > > Hope this helps, > Laurent > > > On Thu, Apr 17, 2014 at 6:48 PM, nicolas carraggi > wrote: > Hello, > > I am actually using "Racket/tcp" for a project in Racket. > I'm creating a peer-to-peer network but now I encountered a small problem. > For a multicast I want to connect with each server on the same network. > For this I use "tcp-connect", but when i try to connect to an ip address > which is not hosting a server, throwing the error only happens after more > than 1 minute. So I would like to use a modified "tcp-connect" with a smaller > time-out. > > Where can I find the implementation of "tcp-connect"? > > I already found "tcp.rkt" but there it gets the "tcp-connect" method from > "'#%network" but I can't find this one... > > Greetings! > Nicolas > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] class implementation and make-primitive-class
If a function takes 28 arguments, you probably overlooked a dozen or so. -- freely paraphrasing Perlis And you just made the best case for Typed Racket and the documentation argument :-) -- freely paraphrasing my own TR talk On Apr 17, 2014, at 2:49 PM, dfel...@ccs.neu.edu wrote: > For a course project I've been working on adding generators to contracts for > use with contract-random-generate, and I've been trying to construct classes > and objects from simple object/c contracts. When trying to find a way to > functionally create a class at runtime, I came across the > `make-primitive-class` function in class-internal.rkt. > > This function is exported, and available at a plain racket repl, but has no > documentation that I have been able to find and the comments about it in > class-internal.rkt seem to be incorrect. > > Trying to call it from the repl has problems also, for example (ignoring for > a moment that the arguments aren't of the expected types) > > -> (make-primitive-class #f #f 'foo object% null #f null null null null) > ; compose-class: arity mismatch; > ; the expected number of arguments does not match the given number > ; expected: 28 > ; given: 27 > > The definition is in terms of compose-class and is just missing a `null` > argument for the abstract-names, but even after fixing that in my local > branch there is a discrepancy with the comments regarding it's first argument > `make-struct:prim`. > > ; The `make-struct:prim' function takes prop:object, a class, > ; a preparer, a dispatcher function, an unwrap property, > ; an unwrapper, and a property assoc list, and produces: > ;* a struct constructor (must have prop:object) > ;* a struct predicate > ;* a struct type for derived classes (mustn't have prop:object) > ; > ; The supplied preparer takes a symbol and returns a num. > ; > ; The supplied dispatcher takes an object and a num and returns a method. > ; > ; The supplied unwrap property is used for adding the unwrapper > ; as a property value on new objects. > ; > ; The supplied unwrapper takes an object and returns the unwrapped > ; version (or the original object). > ; > ; When a primitive class has a superclass, the struct:prim maker > ; is responsible for ensuring that the returned struct items match > ; the supertype predicate. > > This suggests that make-struct:prim should take 7 arguments, but passing a > function of 7 arguments to it from the repl produces: > > -> (make-primitive-class (lambda (a b c d e f g) (values #f #f #f)) #f 'foo > object% null #f null null null null) > ; #: arity mismatch; > ; the expected number of arguments does not match the given number > ; expected: 7 > ; given: 5 > > Also as far as I can tell `make-primitive-class` is never used in the code > base, it is defined in class-internal.rkt, but can be commented out without > seeming to break anything else. Does anyone know if there is a purpose for > this function, or if there is documentation somewhere on the functions I need > to pass it in order to construct a class. I think I'm starting to get a > better idea of how it might work from reading more of class-internal.rkt and > how the class* macro expands, but any guidance would be appreciated. > > Thanks > Dan > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Fwd: [racket] canonical index of Racket courses? [was: Summer programs learning Racket for a student]
Would someone volunteer please to create and maintain such a page for Racket? Thanks -- Matthias Begin forwarded message: > From: j...@math.brown.edu > Subject: [racket] canonical index of Racket courses? [was: Summer programs > learning Racket for a student] > Date: April 16, 2014 4:45:30 PM EDT > To: Racket Users > > I recently asked here about in-person Racket courses available this summer > which I could recommend to a student I've been tutoring. (Thanks again to > everyone who let me know about their courses so far.) > > To make this info easier to find, I'm wondering if the racket-lang.org > maintainers would be interested in publishing a canonical index of Racket > courses (both online and in-person) linked off the "Community" or "Learning" > sections on the homepage, and inviting the community to add to it. > > (Similarly, linking to a canonical index of Racket meetup groups (à la > http://clojure.meetup.com/ and https://wiki.python.org/moin/LocalUserGroups) > would be great too. Google turned up http://racket.meetup.com/ but 2 of the 3 > results there are for racket sports.) > > Thanks, and looking forward to knowing how to become better plugged into the > Racket community! > > Racket Users list: > http://lists.racket-lang.org/users _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28550: master branch updated
TOOR is not in /unstable/. I am with Robby here. Make sure people know.
On Apr 16, 2014, at 6:15 PM, Sam Tobin-Hochstadt wrote:
> No, I think it's very much the same -- like unstable, changes to the
> type system for classes may cause programs that worked (accidentally)
> in 6.0.1 to stop working later. The situtation with `unstable` is in
> fact more unstable, since the interface may change or disappear
> entirely.
>
> Sam
>
> On Wed, Apr 16, 2014 at 6:12 PM, Matthias Felleisen
> wrote:
>>
>> This one's different, given our discussion while you were flying home.
>>
>>
>> On Apr 16, 2014, at 6:07 PM, Sam Tobin-Hochstadt
>> wrote:
>>
>>> That seems quite drastic. For the `unstable` collection, it's worked
>>> fine just having the warning at the top of each page.
>>>
>>> Sam
>>>
>>> On Wed, Apr 16, 2014 at 6:07 PM, Matthias Felleisen
>>> wrote:
>>>>
>>>> Can we make sure that some warning appears on the entire page so that
>>>> nobody loses track of this? A linked margin note every 10 lines would be
>>>> fine.
>>>>
>>>>
>>>> On Apr 16, 2014, at 2:59 PM, as...@racket-lang.org wrote:
>>>>
>>>>> asumu has updated `master' from d212fc7eba to d6a3d27e54.
>>>>> http://git.racket-lang.org/plt/d212fc7eba..d6a3d27e54
>>>>>
>>>>> =[ One Commit ]=
>>>>> Directory summary:
>>>>> 100.0%
>>>>> pkgs/typed-racket-pkgs/typed-racket-doc/typed-racket/scribblings/reference/
>>>>>
>>>>> ~~
>>>>>
>>>>> d6a3d27 Asumu Takikawa 2014-04-15 18:09
>>>>> :
>>>>> | Mark class support as experimental in the TR docs
>>>>> |
>>>>> | Please merge to v6.0.1
>>>>> :
>>>>> M .../typed-racket/scribblings/reference/typed-classes.scrbl | 5 +
>>>>>
>>>>> =[ Overall Diff ]===
>>>>>
>>>>> pkgs/typed-racket-pkgs/typed-racket-doc/typed-racket/scribblings/reference/typed-classes.scrbl
>>>>> ~~
>>>>> ---
>>>>> OLD/pkgs/typed-racket-pkgs/typed-racket-doc/typed-racket/scribblings/reference/typed-classes.scrbl
>>>>> +++
>>>>> NEW/pkgs/typed-racket-pkgs/typed-racket-doc/typed-racket/scribblings/reference/typed-classes.scrbl
>>>>> @@ -13,6 +13,11 @@
>>>>>
>>>>> @title{Typed Classes}
>>>>>
>>>>> +@bold{Warning}: the features described in this section are experimental
>>>>> +and may not work correctly. Some of the features will change by
>>>>> +the next release. In particular, typed-untyped interaction for classes
>>>>> +will not be backwards compatible so do not rely on the current semantics.
>>>>> +
>>>>> Typed Racket provides support for object-oriented programming with
>>>>> the classes and objects provided by the @racketmodname[racket/class]
>>>>> library.
>>>>
>>>>
>>>> _
>>>> Racket Developers list:
>>>> http://lists.racket-lang.org/dev
>>
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28550: master branch updated
This one's different, given our discussion while you were flying home.
On Apr 16, 2014, at 6:07 PM, Sam Tobin-Hochstadt wrote:
> That seems quite drastic. For the `unstable` collection, it's worked
> fine just having the warning at the top of each page.
>
> Sam
>
> On Wed, Apr 16, 2014 at 6:07 PM, Matthias Felleisen
> wrote:
>>
>> Can we make sure that some warning appears on the entire page so that nobody
>> loses track of this? A linked margin note every 10 lines would be fine.
>>
>>
>> On Apr 16, 2014, at 2:59 PM, as...@racket-lang.org wrote:
>>
>>> asumu has updated `master' from d212fc7eba to d6a3d27e54.
>>> http://git.racket-lang.org/plt/d212fc7eba..d6a3d27e54
>>>
>>> =[ One Commit ]=
>>> Directory summary:
>>> 100.0%
>>> pkgs/typed-racket-pkgs/typed-racket-doc/typed-racket/scribblings/reference/
>>>
>>> ~~
>>>
>>> d6a3d27 Asumu Takikawa 2014-04-15 18:09
>>> :
>>> | Mark class support as experimental in the TR docs
>>> |
>>> | Please merge to v6.0.1
>>> :
>>> M .../typed-racket/scribblings/reference/typed-classes.scrbl | 5 +
>>>
>>> =[ Overall Diff ]===
>>>
>>> pkgs/typed-racket-pkgs/typed-racket-doc/typed-racket/scribblings/reference/typed-classes.scrbl
>>> ~~
>>> ---
>>> OLD/pkgs/typed-racket-pkgs/typed-racket-doc/typed-racket/scribblings/reference/typed-classes.scrbl
>>> +++
>>> NEW/pkgs/typed-racket-pkgs/typed-racket-doc/typed-racket/scribblings/reference/typed-classes.scrbl
>>> @@ -13,6 +13,11 @@
>>>
>>> @title{Typed Classes}
>>>
>>> +@bold{Warning}: the features described in this section are experimental
>>> +and may not work correctly. Some of the features will change by
>>> +the next release. In particular, typed-untyped interaction for classes
>>> +will not be backwards compatible so do not rely on the current semantics.
>>> +
>>> Typed Racket provides support for object-oriented programming with
>>> the classes and objects provided by the @racketmodname[racket/class]
>>> library.
>>
>>
>> _
>> Racket Developers list:
>> http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28550: master branch updated
Can we make sure that some warning appears on the entire page so that nobody
loses track of this? A linked margin note every 10 lines would be fine.
On Apr 16, 2014, at 2:59 PM, as...@racket-lang.org wrote:
> asumu has updated `master' from d212fc7eba to d6a3d27e54.
> http://git.racket-lang.org/plt/d212fc7eba..d6a3d27e54
>
> =[ One Commit ]=
> Directory summary:
> 100.0%
> pkgs/typed-racket-pkgs/typed-racket-doc/typed-racket/scribblings/reference/
>
> ~~
>
> d6a3d27 Asumu Takikawa 2014-04-15 18:09
> :
> | Mark class support as experimental in the TR docs
> |
> | Please merge to v6.0.1
> :
> M .../typed-racket/scribblings/reference/typed-classes.scrbl | 5 +
>
> =[ Overall Diff ]===
>
> pkgs/typed-racket-pkgs/typed-racket-doc/typed-racket/scribblings/reference/typed-classes.scrbl
> ~~
> ---
> OLD/pkgs/typed-racket-pkgs/typed-racket-doc/typed-racket/scribblings/reference/typed-classes.scrbl
> +++
> NEW/pkgs/typed-racket-pkgs/typed-racket-doc/typed-racket/scribblings/reference/typed-classes.scrbl
> @@ -13,6 +13,11 @@
>
> @title{Typed Classes}
>
> +@bold{Warning}: the features described in this section are experimental
> +and may not work correctly. Some of the features will change by
> +the next release. In particular, typed-untyped interaction for classes
> +will not be backwards compatible so do not rely on the current semantics.
> +
> Typed Racket provides support for object-oriented programming with
> the classes and objects provided by the @racketmodname[racket/class]
> library.
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
Ah, too bad: > pkgs/racket-pkgs/racket-test/tests/racket/optimize.rktl > ~~~ > --- OLD/pkgs/racket-pkgs/racket-test/tests/racket/optimize.rktl > +++ NEW/pkgs/racket-pkgs/racket-test/tests/racket/optimize.rktl > @@ -3416,5 +3416,16 @@ > (read (open-input-bytes (get-output-bytes o)) > > ;; > +;; Check that an unsufe opertion's argument is > +;; not "optimized" away if it's a use of > +;; a variable before definition: > + > +(err/rt-test (let () > + (unsafe-fx+ x 1) > + (define x 3) > + x) > + exn:fail:contract:variable?) > + > +;; ;;;; :-) On Apr 16, 2014, at 9:02 AM, Matthias Felleisen wrote: > > On Apr 15, 2014, at 9:29 PM, Asumu Takikawa wrote: > >> On 2014-04-15 18:13:31 -0400, claire alvis wrote: >>> The push below includes changes to letrec expressions, internal >>> definitions, units, classes, and certain ill-formed shared expressions so >>> that they no longer leak the `undefined' value. >> >> This is great! (especially happy that TR, even with classes, doesn't >> have to worry about # anymore) >> >> BTW, I found this weird behavior: >> >> Welcome to Racket v6.0.1.3. >> -> (require racket/unsafe/ops) >> -> (let () (+ x 3) (define x 3) 5) >> ; x: variable used before its definition [,bt for context] >> -> (let () (unsafe-fx+ x 3) (define x 3) 5) >> 5 > > > I consider this correct in a strange sense. > > Interestingly enough, > >> (let () (displayln (unsafe-fx+ x 3)) (define x 3) 5) > x: variable used before its definition > context...: > /Users/matthias/plt/racket/collects/racket/private/misc.rkt:87:7 > > which is good too. I don't know how Claire and Matthew did this, > but it's good :-) > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Catching the undefined value
On Apr 15, 2014, at 9:29 PM, Asumu Takikawa wrote: > On 2014-04-15 18:13:31 -0400, claire alvis wrote: >> The push below includes changes to letrec expressions, internal >> definitions, units, classes, and certain ill-formed shared expressions so >> that they no longer leak the `undefined' value. > > This is great! (especially happy that TR, even with classes, doesn't > have to worry about # anymore) > > BTW, I found this weird behavior: > > Welcome to Racket v6.0.1.3. > -> (require racket/unsafe/ops) > -> (let () (+ x 3) (define x 3) 5) > ; x: variable used before its definition [,bt for context] > -> (let () (unsafe-fx+ x 3) (define x 3) 5) > 5 I consider this correct in a strange sense. Interestingly enough, > (let () (displayln (unsafe-fx+ x 3)) (define x 3) 5) x: variable used before its definition context...: /Users/matthias/plt/racket/collects/racket/private/misc.rkt:87:7 which is good too. I don't know how Claire and Matthew did this, but it's good :-) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28542: master branch updated
Yuck. On Apr 15, 2014, at 9:20 PM, as...@racket-lang.org wrote: > asumu has updated `master' from aa43797b63 to 9aaaf98b32. > http://git.racket-lang.org/plt/aa43797b63..9aaaf98b32 > > =[ One Commit ]= > Directory summary: > 97.6% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/ > > ~~ > > 9aaaf98 Asumu Takikawa 2014-04-15 21:15 > : > | Fix TR class support for new class expansion > | > | Also add a type for `check-not-unsafe-undefined` which shows > | up in the expanded code now. > : > M .../typed-racket/base-env/base-env.rkt| 4 + > M .../typed-racket/typecheck/check-class-unit.rkt | 100 --- > > =[ Overall Diff ]=== > > pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/base-env.rkt > ~~ > --- > OLD/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/base-env.rkt > +++ > NEW/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/base-env.rkt > @@ -6,6 +6,7 @@ > (for-template > (except-in racket -> ->* one-of/c class) > racket/unsafe/ops > + racket/unsafe/undefined > ;(only-in rnrs/lists-6 fold-left) > '#%paramz > "extra-procs.rkt" > @@ -2716,6 +2717,9 @@ > [unsafe-struct-set! top-func] > [unsafe-struct*-set! top-func] > > +;; Section 17.4 (Unsafe Undefined) > +[check-not-unsafe-undefined (-poly (a) (-> a -Symbol a))] > + > ;; Section 18.2 (Libraries and Collections) > [find-library-collection-paths (->opt [(-lst -Pathlike) (-lst -Pathlike)] > (-lst -Path))] > [collection-file-path (->* (list -Pathlike) -Pathlike -Path)] > > pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/check-class-unit.rkt > ~~~ > --- > OLD/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/check-class-unit.rkt > +++ > NEW/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/check-class-unit.rkt > @@ -151,7 +151,7 @@ > :make-methods-body > > (define-syntax-class class-expansion > - #:literals (let-values letrec-syntaxes+values #%plain-app) > + #:literals (let-values letrec-syntaxes+values #%plain-app quote) > #:attributes (superclass-expr > type-parameters > all-init-internals > @@ -176,13 +176,15 @@ > () > ((() ;; residual class: data >:internal-class-data)) > - (let-values (((superclass:id) superclass-expr) > - ((interfaces:id) interface-expr)) > -(#%plain-app > - compose-class:id > - internal:expr ... > - (~and make-methods :make-methods-class) > - (quote #f))) > + (#%plain-app > + compose-class:id > + name:expr > + superclass-expr:expr > + interface-expr:expr > + internal:expr ... > + (~and make-methods :make-methods-class) > + (quote :boolean) > + (quote #f)) > > ;; This is similar to `type-declaration` from "internal-forms.rkt", but > ;; the expansion is slightly different in a class so we use this instead. > @@ -517,15 +519,20 @@ > #:literals (:-augment) > ;; FIXME: this case seems too loose, many things can match this syntax > ;;we likely need to set a property or match against another > name > -[(let-values ([(obj:id) self]) > - (let-values ([(field:id) initial-value]) > - (#%plain-app setter:id _ _))) > +[(begin > + (quote ((~datum declare-field-assignment) _)) > + (let-values ([(obj:id) self]) > +(let-values ([(field:id) initial-value]) > + (#%plain-app setter:id _ _ > ;; only record the first one, which is the one that initializes > ;; the field or private field > (unless (dict-has-key? initializers #'setter) >(free-id-table-set! initializers #'setter #'initial-value)) > other-exprs] > -[:tr:class:super-new^ > +;; The second part of this pattern ensures that we find the actual > +;; initialization call, rather than the '(declare-super-new) in > +;; the expansion. > +[(~and :tr:class:super-new^ (#%plain-app . rst)) > (when super-new >(tc-error/delayed "typed classes must only call super-new a single > time")) > (set! super-new (find-provided-inits expr)) > @@ -830,8 +837,6 @@ > super-call-types > pubment-types augment-types inner-types)) > (values all-names all-types > - ;; FIXME: consider removing method names and types > - ;;from top-level environment to
Re: [racket-dev] Thank you DrDr, thank you!
+1 On Apr 15, 2014, at 4:32 PM, John Clements wrote: > This is a short thank-you note; thanks to DrDr, I caught a bug in the > interaction of the test-engine and the stepper two weeks ago, rather than at > release time. Thanks! CI is awesome. > > John > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Changing the default error display handler to use
I wonder whether we could collect the information on these parameters and nail down their interaction constraints somehow. (This could be a research project.) On Mar 13, 2014, at 9:34 PM, Matthew Flatt wrote: > At Wed, 12 Mar 2014 18:05:03 -0700, Eric Dobson wrote: >> A common issue I have is that the default error handler does not >> display error message's exn:srcloc if it has it [...] >> >> Is this reasonable to add to the default error handler, and if so do >> people have suggestions on the format? > > You mean the default error display handler, right? > > I think this change may be worth a try, but there are many > exception-generating, exception-handling, and exception-printing > parameters to worry about, both in their interactions and how they're > currently used. > > For example, does DrRacket use the default error display handler? If > so, it will start printing source locations that it's already showing a > different way, and I think that's not what you intend. Or some other > program harness might be worse off if the default display error handler > starts showing source locations. Then again, the whole point is that > you want to change the display of errors. Trying to change some things > and not changes others --- and having enough extension points to > accommodate certain combinations of changes and non-changes --- is why > the existing set of parameters and handlers is complex. I will not be > surprised if we end up with yet another parameter here. > > If the change makes sense, probably the handler should not print the > first returned source location for `exn:fail:read`, `exn:fail:syntax`, > and `exn:fail:contract:variable` exceptions --- because that location > is supposed to be built into the error-message text, unless the > `error-print-source-location` parameter has a false value. Awkward, I > know; see the previous paragraph. > > The right format is likely to print an extra ": ", > similar to the way that the default error display handler prints > context lines (if the `error-context-display-depth` parameter is not > 0). I imagine that the source-location lines should precede the context > lines, but follow the exception's error message. > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #28213: master branch updated
On Feb 21, 2014, at 7:42 AM, Sam Tobin-Hochstadt wrote: > Since Asumu didn't mention it, the first paper about this is here: > http://www.ccs.neu.edu/racket/pubs/oopsla12-tsdthf.pdf Yeah, but don't read this. We will share a draft paper that looks more practical if you want to try it out. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] xlsx file parser
Place it on http://pkgs.racket-lang.org/#(!main-distribution)(!main-tests) which is the new package server. It's particularly easy if you developed on Github. On Jan 30, 2014, at 10:38 PM, Chen Xiao wrote: > Hi, guys: > > I wrote a office xlsx file parser. I wonder where place it? Can I commit > it to racket core source? Or place it on planet? > > Chen Xiao > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] release notes draft
-- please no 'now's (every bullet in Vincent's wording includes it) -- didn't we say at some point we want to keep things short and point to longer on-line announcements? On Jan 13, 2014, at 5:04 PM, Robby Findler wrote: > Thanks! > > I didn't include the DrRacket one, since I have more plans for that and would > like to hold off announcing it until I get those things done (notably better > some color-blindness color schemes, but also other tweaks to make color > schemes just work better in general). > > Robby > > > On Mon, Jan 13, 2014 at 2:44 PM, Vincent St-Amour > wrote: > At Mon, 13 Jan 2014 12:25:06 -0600, > Robby Findler wrote: > > > > [1 ] > > On Mon, Jan 13, 2014 at 11:05 AM, Vincent St-Amour > > wrote: > > > > > These release notes look good to me, but maybe a bit short. > > > > > > Since this is our first release with new features since 5.3.4 last May, > > > I would have expected a longer list. For example, during the previous > > > release notes discussion, Jay and Neil had some bullets that I don't see > > > on this list. There also were a lot more things in Robby's original > > > email. > > > > > > > > I spoke with Neil privately about the changes and got some agreement and my > > list was not intended as a list of things that were all to be included. > > > > I probably just made a mistake: would you mind helping me fix it? A > > candidate bullet would be great! > > A few from your original list, in no particular order: > > * The `gen:set' generic interface extends set operations to work on > user-defined types that implement set methods, as well as on other > set-like built-in types, such as lists. > > * Picts can now be converted to the svg format. > > * Racket now provides desktop entries (.desktop files) for its graphical > executables. > > * The documentation now includes a style guide: "How to Program Racket". > > * DrRacket now provides support for color schemes. > > > > If we want to keep the announcement itself short, should we point to the > > > various HISTORY.txt files where users can get more details? > > > > > > > > I'm happy to do this too, but less excited about it, especially since we've > > now got a much better mechanism that we can use in the next release and > > we've not done this past releases. > > No problem. With the bullets above, I think we have enough. > > Vincent > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
