[racket-dev] Fwd: [racket] Why experienced programmers don’t use comments?
What is our answer? Begin forwarded message: > From: Ben Duan > Subject: [racket] Why experienced programmers don’t use comments? > Date: July 8, 2013 9:41:10 PM EDT > To: us...@racket-lang.org > > Dear All, > > I have a question here. There’s an extensive use of comments in HtDP. But > there are few comments in experienced programmers’ code, for example in > racket’s source code. Why is that? > > Thanks, > Ben > > Racket Users list: > http://lists.racket-lang.org/users smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] sticky: bad
The new makefile target to re-use the previous `PKGS' value is `again'. At Mon, 8 Jul 2013 08:28:40 -0400, Sam Tobin-Hochstadt wrote: > What about a `make` target (maybe named `rebuild`) that remembers the > previous PKGS setting? That seems a little less stateful, and would be > perfect for the reasons that led me to ask for sticky mode. > > Sam > > On Mon, Jul 8, 2013 at 8:24 AM, Matthew Flatt wrote: > > I'm happy to enable sticky mode only when the `make' line is something > > like > > > > make PKGS="..." STICKY_MODE=on > > > > Any objections? > > > > At Sat, 6 Jul 2013 09:43:46 -0500, Robby Findler wrote: > >> I just got horribly confused because somehow I messed up passing a manual > >> command-line to link-all.rkt and then nothing was working right. (It took > >> me embarrassingly long to remember this sticky thing and then get > >> unsticky.) > >> > >> So, can we change things so that "make" in the top-level doesn't use > >> stickyness? Maybe add a new target "make stuck" or something that people > >> who like this can use and so we avoid unexpected state? > >> > >> Robby > >> _ > >> 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] making DrRacket.app
Repairs pushed --- thanks for the report!
At Mon, 8 Jul 2013 09:39:27 -0600, Matthew Flatt wrote:
> Offhand, I see one problem: `make' creates links with absolute paths to
> the packages in "pkgs". I'll fix that and check for other problems.
>
> It's possible that
>
> make pkg-links
>
> in the new place will fix your problem.
>
> If not, you may have to move before building, or try a snapshot from
>
> http://www.cs.utah.edu/plt/snapshots/
>
>
> At Mon, 8 Jul 2013 10:28:12 -0500, "Geoffrey S. Knauth" wrote:
> > I admit I have not built DrRacket in a couple of months. I just did a git
> > pull, rebuilt ("make"), and now if I open:
> >
> > ~/test/plt/git/plt/racket/DrRacket.app
> >
> > it runs, but if I move the racket directory to where I used to put it
> > (/usr/local) and try running:
> >
> > /usr/local/racket/DrRacket.app
> >
> > it doesn't start up. I'm guessing this happened because "make" is the same
> as
> > "make in-place" and I may have some kind of hard-coded path now in the
> build.
> > Should I have built with a prefix /usr/local ("--prefix=/usr/local" ?). I
> > want "racket" directory built to end up in /usr/local .
> >
> > I used to do "make" and then "make install". In between I would move
> > /usr/local/racket to /usr/local/racket-old in case something went wrong and
> > I
> > needed to go back to the last successful build.
> >
> > Thanks,
> > Geoff
>
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27112: master branch updated
At Mon, 8 Jul 2013 17:01:24 -0400, Sam Tobin-Hochstadt wrote: > On Mon, Jul 8, 2013 at 2:39 PM, wrote: > > > --- > OLD/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/tc-toplevel.r > kt > > +++ > NEW/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/tc-toplevel.r > kt > > @@ -392,7 +392,8 @@ > > (match a > > [(list from to) > >#`(add-alias (quote-syntax #,from) (quote-syntax > #,to))] > > - (begin-for-syntax (add-mod! (quote-module-path > > + (begin-for-syntax (add-mod! > > (variable-reference->module-path-index > > + (#%variable-reference) > >#`(begin > >#,(if (null? (syntax-e #'(new-provs ...))) > > #'(begin) > > One thing I liked about the old code here is that > `(quote-module-path)` has easier-to-explain semantics. Should it be > changed, or should there be some other form in `syntax/location` that > does what you've done here? I don't think that `(quote-module-path)' should change. A new form in `syntax/location' or some other library would make sense. I didn't add `(quote-module-path-index)', because a module-path index cannot be marshaled in the same way as the other `(quote-)' results, and so I wasn't sure that it belonged there or what it should be called. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27112: master branch updated
On Mon, Jul 8, 2013 at 2:39 PM, wrote: > --- > OLD/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/tc-toplevel.rkt > +++ > NEW/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/tc-toplevel.rkt > @@ -392,7 +392,8 @@ > (match a > [(list from to) >#`(add-alias (quote-syntax #,from) (quote-syntax > #,to))] > - (begin-for-syntax (add-mod! (quote-module-path > + (begin-for-syntax (add-mod! (variable-reference->module-path-index > + (#%variable-reference) >#`(begin >#,(if (null? (syntax-e #'(new-provs ...))) > #'(begin) One thing I liked about the old code here is that `(quote-module-path)` has easier-to-explain semantics. Should it be changed, or should there be some other form in `syntax/location` that does what you've done here? Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] making DrRacket.app
Offhand, I see one problem: `make' creates links with absolute paths to
the packages in "pkgs". I'll fix that and check for other problems.
It's possible that
make pkg-links
in the new place will fix your problem.
If not, you may have to move before building, or try a snapshot from
http://www.cs.utah.edu/plt/snapshots/
At Mon, 8 Jul 2013 10:28:12 -0500, "Geoffrey S. Knauth" wrote:
> I admit I have not built DrRacket in a couple of months. I just did a git
> pull, rebuilt ("make"), and now if I open:
>
> ~/test/plt/git/plt/racket/DrRacket.app
>
> it runs, but if I move the racket directory to where I used to put it
> (/usr/local) and try running:
>
> /usr/local/racket/DrRacket.app
>
> it doesn't start up. I'm guessing this happened because "make" is the same
> as
> "make in-place" and I may have some kind of hard-coded path now in the build.
>
> Should I have built with a prefix /usr/local ("--prefix=/usr/local" ?). I
> want "racket" directory built to end up in /usr/local .
>
> I used to do "make" and then "make install". In between I would move
> /usr/local/racket to /usr/local/racket-old in case something went wrong and I
> needed to go back to the last successful build.
>
> Thanks,
> Geoff
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] making DrRacket.app
I admit I have not built DrRacket in a couple of months. I just did a git
pull, rebuilt ("make"), and now if I open:
~/test/plt/git/plt/racket/DrRacket.app
it runs, but if I move the racket directory to where I used to put it
(/usr/local) and try running:
/usr/local/racket/DrRacket.app
it doesn't start up. I'm guessing this happened because "make" is the same as
"make in-place" and I may have some kind of hard-coded path now in the build.
Should I have built with a prefix /usr/local ("--prefix=/usr/local" ?). I want
"racket" directory built to end up in /usr/local .
I used to do "make" and then "make install". In between I would move
/usr/local/racket to /usr/local/racket-old in case something went wrong and I
needed to go back to the last successful build.
Thanks,
Geoff
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27090: master branch updated
On Jul 7, 2013, at 12:08 AM, Eli Barzilay wrote: > It would be nice to have some way of doing it with contracts, but > that's obviously impractical -- so I think that a good way to solve it > and other such problems is to add a parameter for the name used in > read errors, and making `raise-read-error' behave in a similar way to > `raise-syntax-error' with the parameter used as the `foo:' part of the > error message. Boy I like this. I can't remember how often I have code up something like '#:function' and thought this is a general problem worthy of a solution. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Package compatibility
Just now, Jay McCarthy wrote: > The problem with that is that there is no way to ensure that there > is only one package named "data/red-black-tree" There's no need to ensure such a thing -- and IIUC, the current system doesn't do that neither modulo a bunch of blessed packages. > and there can be two mutually incompatible universes of packages for > Carl's rbts and mine, for instance. This is also something that could happen now in the same way. But I don't see anything wrong with having this ability: I can hack my own racket/list to do whatever I want, and therefore I should be able to make a package that has this hacked version of the file. I'd be mostly living in my own world whether this hack is done with a package system or directly. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Package compatibility
The problem with that is that there is no way to ensure that there is only one package named "data/red-black-tree" and there can be two mutually incompatible universes of packages for Carl's rbts and mine, for instance. Furthermore, it has the internal linking problem. On Mon, Jul 8, 2013 at 7:11 AM, Eli Barzilay wrote: > Yesterday, Jay McCarthy wrote: >> Planet attempts to solve this problem technically by (a) having all >> collections be prefixed by / and (b) mandating >> a centralized server that enforces unique s and unique >> s per author. Since Racket packages don't have a >> mandated central server we can't enforce uniqueness like that. (i.e. >> even if we mandated the prefix by , there's no way to >> enforce unique package names across the universe without a central >> server.) Furthermore, bringing s in to the code would >> give us /internal linking/ which Racket packages are designed to >> avoid for other reasons. >> >> Since technical solutions to this problem are lacking, > > An easy way to make it a non problem would be to eliminate the extra > indirection that is in package names: if the package that Carl is > asking about is *named* "data/red-black-tree" then it clearly > conflicts with another package with the same name. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! -- 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] What command should DrDr run by default?
Yesterday, Robby Findler wrote: > Raco test runs the file if there is not test sub module. Fwiw. That's what I thought first, with "run" being the same as what racket does. But it doesn't: it just runs the toplevel module as usual when the file is required (and does so unconditionally, of course), and then runs a `test' submodule if there is one. In the files in question, the tests are running in the `main' module, and raco test was therefore not running them. This seems like a fine behavior for raco test, but for drdr, it *should* run a `main' module if there is one, and if there is no `test' module. This avoids the need to abuse a `test' submodule as some semi-drdr-flag-thing, since files in some "tests" path shouldn't be required to have a `test' submodule. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Package compatibility
Yesterday, Jay McCarthy wrote: > Planet attempts to solve this problem technically by (a) having all > collections be prefixed by / and (b) mandating > a centralized server that enforces unique s and unique > s per author. Since Racket packages don't have a > mandated central server we can't enforce uniqueness like that. (i.e. > even if we mandated the prefix by , there's no way to > enforce unique package names across the universe without a central > server.) Furthermore, bringing s in to the code would > give us /internal linking/ which Racket packages are designed to > avoid for other reasons. > > Since technical solutions to this problem are lacking, An easy way to make it a non problem would be to eliminate the extra indirection that is in package names: if the package that Carl is asking about is *named* "data/red-black-tree" then it clearly conflicts with another package with the same name. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] sticky: bad
Thanks. Robby On Mon, Jul 8, 2013 at 7:28 AM, Sam Tobin-Hochstadt wrote: > What about a `make` target (maybe named `rebuild`) that remembers the > previous PKGS setting? That seems a little less stateful, and would be > perfect for the reasons that led me to ask for sticky mode. > > Sam > > On Mon, Jul 8, 2013 at 8:24 AM, Matthew Flatt wrote: > > I'm happy to enable sticky mode only when the `make' line is something > > like > > > > make PKGS="..." STICKY_MODE=on > > > > Any objections? > > > > At Sat, 6 Jul 2013 09:43:46 -0500, Robby Findler wrote: > >> I just got horribly confused because somehow I messed up passing a > manual > >> command-line to link-all.rkt and then nothing was working right. (It > took > >> me embarrassingly long to remember this sticky thing and then get > unsticky.) > >> > >> So, can we change things so that "make" in the top-level doesn't use > >> stickyness? Maybe add a new target "make stuck" or something that people > >> who like this can use and so we avoid unexpected state? > >> > >> Robby > >> _ > >> 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] sticky: bad
What about a `make` target (maybe named `rebuild`) that remembers the previous PKGS setting? That seems a little less stateful, and would be perfect for the reasons that led me to ask for sticky mode. Sam On Mon, Jul 8, 2013 at 8:24 AM, Matthew Flatt wrote: > I'm happy to enable sticky mode only when the `make' line is something > like > > make PKGS="..." STICKY_MODE=on > > Any objections? > > At Sat, 6 Jul 2013 09:43:46 -0500, Robby Findler wrote: >> I just got horribly confused because somehow I messed up passing a manual >> command-line to link-all.rkt and then nothing was working right. (It took >> me embarrassingly long to remember this sticky thing and then get unsticky.) >> >> So, can we change things so that "make" in the top-level doesn't use >> stickyness? Maybe add a new target "make stuck" or something that people >> who like this can use and so we avoid unexpected state? >> >> Robby >> _ >> 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] sticky: bad
I'm happy to enable sticky mode only when the `make' line is something like make PKGS="..." STICKY_MODE=on Any objections? At Sat, 6 Jul 2013 09:43:46 -0500, Robby Findler wrote: > I just got horribly confused because somehow I messed up passing a manual > command-line to link-all.rkt and then nothing was working right. (It took > me embarrassingly long to remember this sticky thing and then get unsticky.) > > So, can we change things so that "make" in the top-level doesn't use > stickyness? Maybe add a new target "make stuck" or something that people > who like this can use and so we avoid unexpected state? > > Robby > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Using Travis CI for Racket
On Tue, Jul 2, 2013 at 7:04 PM, Sam Tobin-Hochstadt wrote: > I've just committed support for building Racket automatically on the > Travis continuous integration service. See > https://travis-ci.org/samth/racket/ for the current build state. This > doesn't track the actual `plt/racket` repository yet [1], This is now working -- thanks Eli. You can see the current status here: https://travis-ci.org/plt/racket If you'd like to be notified about tests, let me know. Unfortunately, some combination of the Travis configuration and recent changes to Racket mean that a few of the tests for `subprocess` are failing. Matthew thinks that the tests are the problem here, and I hope to look into this soon. > Currently, it runs tests for the following: > > - everything in `tests/racket/` > - `json` > - `xml` This list now includes `net`, `openssl`, `db`, `match` and the tests of embedded paths in zo files. Still not set up are: `pkg`, `launcher`, the relevant SRFIs, and a few other things. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
