Re: [racket-dev] Testing for Racket v6.0
On Fri, Feb 14, 2014 at 03:55:59PM -0500, Ryan Culpepper wrote: If you are interested in helping, please reply to this message to the mailing list and include the configuration(s) you are willing to test. OK, of what seems to be remaining... I can do the Windows 32-bit, if it is acceptable to do on a 64-bit Windows. If not, I can do the OS X 32-bit, if it is acceptable to do on OS X 10.5 (oldish). If not, I can do the unix-style build + install on Linux, if it is acceptable to do with something like --prefix=$HOME (non-root). Sorry for all the qualifications, I just want it to be clear in case I don't fit what you need. David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Testing for Racket v6.0
On Fri, Feb 14, 2014 at 03:55:59PM -0500, Ryan Culpepper wrote: We would like to test the release candidate on the following configurations: If I find the time to help here, where would I get the official release candidate? Sorry if this should be obvious. David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] building from a git checkout into a separate BUILD directory
On Sun, Nov 03, 2013 at 11:28:46AM -0700, Matthew Flatt wrote: But how well does it work to use bin/raco pkg install -i --auto main-distribution at the end of the commands above? Use `raco pkg install` pulls packages from the network, instead of from Hmm, I think that will not work for me since my intention is to actually try doing some development work on the packages. For now at least I'll work with the normal in-place configuration. Thanks for the response. David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] how to test rackunit
On Sat, Nov 02, 2013 at 10:48:39PM -0600, Jay McCarthy wrote: http://drdr.racket-lang.org/27688/pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/run-tests.rkt One thing that you will see is that as part of testing there are some failing tests to see what happens, but the tests deliberately switch current-error-port with current-input-port so that it does not result in STDERR output that DrDr would count as a failure. Jay, thanks for the information. Reading about DrDr [1] was enlightening. I'm not sure this was your intention, but it confirmed for me that I should be capturing the (standard error) output of the 'raco test ...' command before and after my changes to make sure the only changes are those I intend. David [1] http://drdr.racket-lang.org/help _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] how to test rackunit
What is the correct way to run the tests which test rackunit? I am running the following after building with a clean tree: $ racket/bin/raco test pkgs/rackunit-pkgs/rackunit-test/tests/rackunit This seems to show several failures, though since it is testing rackunit I'm pretty sure most if not all are intentional (to verify that things which should fail do fail.) The full output is below [*]. What is not clear is how do people run this and determine whether they have any unintentional failures? Is there a separate command I should be using? Perhaps people just diff the output from a clean tree vs the output with their changes? BTW, I have read: http://blog.racket-lang.org/2012/11/tutorial-contributing-to-racket.html which has been very helpful since Joe's example was a change to rackunit, but I didn't see anything addressing this problem. For additional context: my motivation for running these tests is to improve check-exn so it no longer passes when given a non-thunk. I think it should raise an error instead. I already have a patch for this but running the tests has me thinking I'm not using the correct command to test rackunit. David [*] Here is the output from the above 'raco test ...' command, with stdout and stderr redirected to a file. Note the redirection changes the ordering of some lines compared to the terminal output. raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/all-rackunit-tests.rkt raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/base-test.rkt raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/check-info-test.rkt raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/check-test.rkt raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/counter-test.rkt raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/format-test.rkt raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/hash-monad-test.rkt raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/location-test.rkt raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/log.rkt FAILURE name: check-true location: (#path:/home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/log.rkt 38 2 1185 15) expression: (check-true #f) params: (#f) Check failure raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/monad-test.rkt raco test: pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/pr10950.rkt 1 test ERROR Outta here! context...: /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/check.rkt:133:29 /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/check.rkt:58:0: top-level-check-around /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-lib/rackunit/private/check.rkt:119:21: check-pred492750 /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/standalone-check-test.rkt: [running body] f88 loop loop loop f88 /home/dtp/src/dtp-racket/pkgs/compiler-pkgs/compiler-lib/compiler/commands/test.rkt: [running body] /home/dtp/src/dtp-racket/racket/collects/raco/raco.rkt: [running body] /home/dtp/src/dtp-racket/racket/collects/raco/main.rkt: [running body] FAILURE name: check location: (#path:/home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/standalone-check-test.rkt 44 0 1344 17) expression: (check = 1 2) params: (#procedure:= 1 2) message:0.0 Check failure ERROR First Outta here! context...: /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/standalone-test-case-test.rkt: [running body] f88 loop loop loop f88 /home/dtp/src/dtp-racket/pkgs/compiler-pkgs/compiler-lib/compiler/commands/test.rkt: [running body] /home/dtp/src/dtp-racket/racket/collects/raco/raco.rkt: [running body] /home/dtp/src/dtp-racket/racket/collects/raco/main.rkt: [running body] error ERROR Second Outta here! context...: /home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/standalone-test-case-test.rkt: [running body] f88 loop loop loop f88 /home/dtp/src/dtp-racket/pkgs/compiler-pkgs/compiler-lib/compiler/commands/test.rkt: [running body] /home/dtp/src/dtp-racket/racket/collects/raco/raco.rkt: [running body] /home/dtp/src/dtp-racket/racket/collects/raco/main.rkt: [running body] FAILURE actual: 1 expected: 2 name: check-eq? location: (#path:/home/dtp/src/dtp-racket/pkgs/rackunit-pkgs/rackunit-test/tests/rackunit/standalone-test-case-test.rkt 19 12 520 15) expression: (check-eq? 1 2) Check failure failure FAILURE actual: 1 expected: 2 name: check-eq? location:
[racket-dev] accessing @deftech terms in the reference from the guide
Are terms defined via @deftech in the Racket reference supposed to be
accessible via @tech from the Racket guide?
In pkgs/racket-pkgs/racket-doc/scribblings/reference/evts.scrbl there
exists a line that looks like:
... @deftech{synchronizable event} ...
In my pkgs/racket-pkgs/racket-doc/scribblings/guide/concurrency.scrbl I
have:
... @tech{synchronizable event}s. ...
When I build, I get:
raco setup: --- building documentation ---
raco setup: WARNING: undefined tag in
pkgs/racket-doc/scribblings/guide/guide.scrbl:
raco setup: (tech synchronizable event)
I'm guessing only the @deftech terms defined in the guide are accessible? This
is not a big deal, I just wanted to be sure I wasn't doing something
incorrectly.
Thanks.
David
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] building from a git checkout into a separate BUILD directory
I am building from a (relatively recent) git checkout. I have been using the in-place make target which installs in ./racket, but I'd like to have everything built and installed in a separate BUILD directory. My motivations are to have a single directory to rm -r when I want to start over and secondly to have a single directory to exclude from my nightly backups. I can get the base built with: mkdir BUILD cd BUILD ../racket/src/configure --prefix=$PWD make make install but then I need to deal with packages. I was able to hack the link-all.rkt to kinda work but the subsequent raco setup didn't seem to do anything significant. I'm pretty sure my hack was the wrong approach anyway, so I won't detail my steps with that. Is there an easy way to do what I want? Thanks for any help. David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket Guide chapter on concurrency
On Tue, Oct 08, 2013 at 03:42:56AM -0500, Robby Findler wrote: You can use things like @interaction[] to run and typeset examples; does that help? http://docs.racket-lang.org/scribble/eval.html?q=interaction#%28form._%28%28lib._scribble%2Feval..rkt%29._interaction%29%29 That's not exactly what I was looking for, but it could be helpful at some point. Thanks for the suggestion. What I was imagining was a way to load a scribble doc and run the racketblocks individually (perhaps automatically) and show the output (but not include it in the generated doc). But upon further thought, my racketblocks aren't all standalone anyway. David _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] git rebase/squash my commits before submitting a pull request?
Thank you to everyone who provided feedback on my Guide chapter on concurrency. I think I've addressed everyone's suggestions in my latest version [1]. My question at this point is whether to rebase before submitting a pull request. If the initial commit had not been made public I would obviously want to rebase and squash. But since it was publicized here and people commented, should I leave it as is? Since this is a relatively minor patch, perhaps it doesn't matter so much for this time. But it would be good to know whether there is a general rule for when not to rebase/squash. David [1] https://github.com/davidtpierson/racket/tree/concurrency-docs _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket Guide chapter on concurrency
On Mon, Oct 07, 2013 at 02:21:26PM -0700, John Clements wrote: Isn't this early example: +@racketblock[ +(define worker (thread (lambda () + (let loop () + (displayln Working...) + (loop) +(sleep 2.5) +(kill-thread worker) +] ... going to generate a *heck of a lot* of output in 2.5 seconds? How about something like (sleep 0.1) in the display loop? Good point. I'll fix that in the next commit. Thanks for looking at it. David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket Guide chapter on concurrency
On Mon, Oct 07, 2013 at 04:08:27PM -0400, David Vanderson wrote: This is fantastic! Thank you! I learned a good deal reading it just now. Comments below: Great! Thanks for checking it out and commenting. make-arithmetic-thread is missing a (let loop () line. Later in the same example (match should be (match item. Ugh, that's sloppy of me. Thanks for catching these. I wonder if there is an easy way to run individual examples from a scribble doc without copying to and from different buffers. (I'm assuming I messed up a copy paste at some point.) In the channel example, could you have the worker threads return some text when they are done? It makes running the example clearer. I don't understand the note below this example about the lack of synchronization. I don't see how that can happen, can you explain it to me? Darn. I had fixed that lack of synchronization by adding the DONE items, but neglected to remove the note. The note does apply to the next example though, so I moved it down. An update is at: https://github.com/davidtpierson/racket/commit/ba1caddb9964c85740e2beb92477d25519a2ba7d Even after reading the reference on wrap-evt and handle-evt, I don't understand when I would use wrap-evt. It seems like handle-evt is better? For the guide, I suggest cutting the wrap-evt example, and only show handle-evt. Hmm, the advantage of wrap-evt over handle-evt is that wrap-evt disables breaks before calling the handler. I'll either incorporate that info or remove the example, but first I need to learn a bit more about breaks. David _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Racket Guide chapter on concurrency
Hi all, At the hackathon Asumu helped me work on a Guide chapter on concurrency. Thanks Asumu! Since then I've fleshed it out some more and pushed a commit to github. https://github.com/davidtpierson/racket/commit/d2fb857efec8ce508ac6f76afa845d788edab4c1 It probably needs more work. I would love some feedback before I dare to submit a pull request. Some of my concerns, in no particular order: 1) Should it be broken into separate pages? 2) It starts out with the basics of threads. Is this too trivial to cover? 3) There are lots of ways to synchronize Racket threads. I try to cover them broadly, but don't really delve into which ones are best. Parts seem like they are just restating information from the reference. Should there be more prescriptive text? 4) Some of the examples feel clumsy. Contriving concurrency examples that are both simple and meaningful was hard. I'm not sure I succeeded. Thanks for any feedback (on the above issues or anything else.) David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revising Racket's home page
On Mon, Aug 19, 2013 at 05:39:54PM -0400, Sam Tobin-Hochstadt wrote: Recently I (with assistance from Asumu) have spent some time drafting a revised home page for Racket. A revised web page will nicely complement the big upcoming release, I hope. You can see the draft here, which is ready for people to try out: http://homes.soic.indiana.edu/samth/new-web/ I think the header should include Racket, probably to the right of the logo. 1. It works well on small devices, which our current page doesn't. Try it out on a phone or a tablet. I tried it on an iPhone running an oldish iOS (5.1.1 it seems). The text size is more readable, but the organization/layout needs work. For example, after the top header I see headings and sections in the following order (note the News heading): Racket: A programmable programming language Racket is a wide-spectrum ... Start Quickly News (sample program) Racket version 5.3.5 has been released. Racket videos are now available. ... The subsequent headings/sections seem ordered ok, but the sections themselves could be more clearly set apart from each other. Also, the book cover images take up a lot of screen space (full width of the page) on the phone. David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
On Thu, May 03, 2012 at 03:48:17PM -0400, Eli Barzilay wrote: With the trend of having shorter names, I'll try suggesting it again. Looking at some random slides (the ones from Matthew's talk), one thing that is -- still -- very strikingly inconvenient is code like (parameterize ([current-error-port (current-output-port)]) ...) IMO, anyone who is not coming from some kind of Scheme background would view this as ridiculously long. If they're renamed to the usual names, things look much better: (parameterize ([stderr (stdout)]) My first thought is that the names current-error-port and stderr suggest different concepts. stderr is the standard error stream corresponding to POSIX file descriptor 2. current-error-port is an abstraction mechanism that allows you to control where error messages are directed. If stderr were to be bound in #lang racket, based on the above I'd expect it to be bound to a port corresponding to the standard error stream, not bound to a parameter controlling which port error messages go to. I realize such a stderr binding would not be particularly useful for most Racket programs, so I'm not advocating having such a binding. I'm just saying the name stderr implies something different than current-error-port, that current-error-port better denotes the purpose of the parameter, and that in this case I like the more accurate name is better than the short name. If parameterize forms like your example are the main motivation, perhaps a new function or syntax would be more to the point? e.g. something called with-errors-to-output... Also, I see that these names appear to already be available as proposed via the preprocessor/mzpp and preprocessor/mztext modules. Finally, It occurs to me that this is the second time in several weeks I'm responding to a thread about changing names. Hopefully my comments are thoughtful and not just reactionary. David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new logo
Hi all, Graphic design is not a strength of mine, but I had an idea that I don't think I've seen incorporated into any of the designs so far. Maybe someone will want to take it further. http://i.imgur.com/ExgM6.png A couple of points: My original idea was simply an italicized R and a λ. Then I noticed the λ is suggestive of an A, so I added the CKET at a smaller size. I am not really fond of Rλ by itself, at least with my attempts at it. Also, the λ/A could be an actual combination of λ and A, like: http://i.imgur.com/50Df8.png David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Missing pregexp syntax in Racket
On Mon, Nov 28, 2011 at 12:02:46AM -0800, Pauan wrote: Yes that is exactly it. The rationale is as ozzloy said: right now you needto use something like #px\\d to match the string \\5. That's a lot ofbackslashes! In other languages that support regexps, there's usually a way of specifyingthem so it requires less backslashes. For instance, in JavaScript you can saythis: /\\\d/ But before we can even consider such a syntax, we first need to add in theabove mentioned regexp syntaxes. Because otherwise #px/\n/ would compile into(pregexp \\n) which would then throw an error, as you noted. So this is thefirst step in enabling such a syntax. OK, I think I understand your rationale. And I think that #px/\d/ could be useful. But my first impression is that such a new #px reader syntax should translate into the existing pregexp syntax, not extend it. It seems odd to me that #px/\n/ would mean #px\\n and that that would be equivalent to #px\n. I'm curious what others think so I'll try to find the irc conversation. David _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Missing pregexp syntax in Racket
On Sat, Nov 26, 2011 at 10:35:57PM -0800, Pauan wrote: It was brought up that my explanation was confusing, and I agree it is. So I'll try again. The following should return #t: ... (regexp-match? \\n \n) I am confused about a number of things in your emails, so for simplicity I'm focusing on the above expression only. Your email subject mentions pregexp, but your pattern is a string literal, which AFAICT will be compiled into a regular expression using regexp not pregexp. Therefore it isn't clear whether you are suggesting a change to regexp syntax or pregexp syntax. Currently, #rx\\n matches like #rxn and #px\\n is an error: (regexp-match? #rx\\n n) #t #px\\n readline-input::569: read: bad pregexp string: illegal alphabetic escape Both of these behaviors agree with the syntax documented at http://docs.racket-lang.org/reference/regexp.html?q=regexp-match%3F#(part._regexp-syntax) To add to my confusion, your original email mentioned #pxn, which currently matches a backslash followed by an 'n'. Perhaps you are suggesting that #px\\n should mean the same as #px\n rather than being an error? I don't see a need for this but perhaps you have a rationale in mind? David _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Question about round
Hi all, I'm hoping that non-developers [of Racket itself] are welcome to post here. On Fri, Sep 30, 2011 at 11:59:25AM -0400, Vincent St-Amour wrote: Here's a proposal: `integer?' becomes the same as `exact-integer?' (which is kept for backwards compatibility). It is not clear to me from the responses to this proposal whether it is still being considered. If so I feel motivated to question it. Quoting the original poster in his follow-up email: On Fri, Sep 30, 2011 at 09:18:26AM -0700, Mark Engelberg wrote: When I saw in the docs for round that it returns an integer, and I was getting an inexact number, I was sure it was a mistake. So the original confusion was due to round returning an inexact? number. The above proposal does not address that confusion, but instead makes integer? return #f for inexact? inputs. So: (integer? 1.0) ; would be #f Are Racket users confused by the current result of (integer? 1.0) = #t? The original poster explicitly wrote that he expected #t from (integer? (round (sin 30))). It seems to me this proposed change would increase confusion. Maybe the concern is that integer? is unreliable for inexacts, so the proposed changes are safer? As Vincent pointed out in a follow-up email, if (integer? 1.0) should be #f then (rational? 1.0) should also be #f. Essentially integer? becomes useless for inexacts and rational? becomes a synonym for exact?. The utility of both functions decreases. It seems to me that the appropriate response to the original confusion is education/documentation, not a change in the semantics of the language which decreases utility and breaks backward compatibility. David _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
