Re: [racket-dev] [plt] Push #24082: master branch updated
On 03/22/2012 03:27 PM, Jay McCarthy wrote:
Someone else noticed this warning.
http://bugs.racket-lang.org/query/?cmd=viewpr=12443
As the comment below mentions, I don't actually know how to get rid of
the warning, but it doesn't cause problems anymore.
Does anyone have any ideas or thoughts?
Based on my testing, the call to 'thread' that sometimes fails is the
one labeled Clean-up and timeout thread. My guess is that the handler
thread (the one that calls 'handler') ends by calling
'custodian-shutdown-all' on its current custodian ('c'), and
occasionally that shutdown occurs before the cleanup thread is even created.
One way to fix it is to delay the handler thread's execution until the
cleanup thread has been created (eg, have the handler thread wait on a
semaphore that isn't posted until after the cleanup thread is created).
Another way would be to create the cleanup thread first, but that
requires both synchronization and mutation, because it needs to refer to
the handler thread.
Ryan
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] submodules
At Fri, 9 Mar 2012 17:21:26 -0700, Matthew Flatt wrote: At Fri, 9 Mar 2012 15:58:11 -0700, Jay McCarthy wrote: I just pushed... - module** Like module* but combines multiple occurrences of the same submodule name into one module* I like this direction --- and like everyone, I wish for a better name. As you probably noticed, we're currently trying out `module+'. I tried out several alternatives, including `submodule', `slice', `facet', `segment', `section', `.section', `at-module', and even `p.s.'; `module+' is the best so far. One big advantage of `module+' is that it avoids inventing a new term, and I think `+' is suggestive of combining multiple bodies into one. Meanwhile, `(submod ..)' is now allowed as a shorthand for `(submod . ..)'. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Oversight in type for path-string?
Actually I don't think this is an over sight. The null string is a String. And Path-String is Path U String, but (path-string? (string #\null)) = #f. Sent from a mobile device. On Mar 21, 2012 5:14 PM, John Clements cleme...@brinckerhoff.org wrote: On Mar 21, 2012, at 3:20 PM, Sam Tobin-Hochstadt wrote: On Wed, Mar 21, 2012 at 5:36 PM, John Clements cleme...@brinckerhoff.org wrote: It looks like 'path-string?' is not labeled as a discriminator type. path-string? - : (Any - Boolean) #procedure:path-string? Is this just an oversight? Yes, that's just an oversight, although it's slightly more complicated than you'd think (because `(path-string? (string #\null))' is #f). Well, I just made do with (define-predicate ps? Path-String?), so this certainly isn't a major problem. John _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Oversight in type for path-string?
That's true, which is why it has to have a more complex filter than you'd expect. But if a value isn't `path-string?', then it is definitely not a `Path', and if it *is* `path-string?' then it's either a `String' or a `Path'. So we can express an approximation of it's behavior in the type. On Fri, Mar 23, 2012 at 12:09 PM, Eric Dobson eric.n.dob...@gmail.com wrote: Actually I don't think this is an over sight. The null string is a String. And Path-String is Path U String, but (path-string? (string #\null)) = #f. Sent from a mobile device. On Mar 21, 2012 5:14 PM, John Clements cleme...@brinckerhoff.org wrote: On Mar 21, 2012, at 3:20 PM, Sam Tobin-Hochstadt wrote: On Wed, Mar 21, 2012 at 5:36 PM, John Clements cleme...@brinckerhoff.org wrote: It looks like 'path-string?' is not labeled as a discriminator type. path-string? - : (Any - Boolean) #procedure:path-string? Is this just an oversight? Yes, that's just an oversight, although it's slightly more complicated than you'd think (because `(path-string? (string #\null))' is #f). Well, I just made do with (define-predicate ps? Path-String?), so this certainly isn't a major problem. John _ Racket Developers list: http://lists.racket-lang.org/dev -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] nightly build available as a ppa
[on dev@] On Fri, Mar 23, 2012 at 12:24 PM, Jon Rafkind rafk...@cs.utah.edu wrote: I'm not quite sure what will happen if you have both the racket ppa and the racket-nightly ppa but probably you shouldn't try it :p. This setup is quite new (as of this week) so let me know if anything doesn't work. You can set the packages up to conflict with each other, so that people don't accidentally do this. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24082: master branch updated
Awesome Ryan, thanks for looking into it. I now feel stupid that I
didn't see that before.
I found a really simple solution too.
Jay
On 3/22/12, Ryan Culpepper r...@cs.utah.edu wrote:
On 03/22/2012 03:27 PM, Jay McCarthy wrote:
Someone else noticed this warning.
http://bugs.racket-lang.org/query/?cmd=viewpr=12443
As the comment below mentions, I don't actually know how to get rid of
the warning, but it doesn't cause problems anymore.
Does anyone have any ideas or thoughts?
Based on my testing, the call to 'thread' that sometimes fails is the
one labeled Clean-up and timeout thread. My guess is that the handler
thread (the one that calls 'handler') ends by calling
'custodian-shutdown-all' on its current custodian ('c'), and
occasionally that shutdown occurs before the cleanup thread is even created.
One way to fix it is to delay the handler thread's execution until the
cleanup thread has been created (eg, have the handler thread wait on a
semaphore that isn't posted until after the cleanup thread is created).
Another way would be to create the cleanup thread first, but that
requires both synchronization and mutation, because it needs to refer to
the handler thread.
Ryan
--
Jay McCarthy j...@cs.byu.edu
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
The glory of God is Intelligence - DC 93
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Interactive Tutorial
On Mar 21, 2012, at 3:34 PM, Nick Shelley wrote: My brother has been interested in learning to program, but not super motivated. I've tried to get him into HtDP 2e, but for him there's too much reading and not enough doing (and when he comes to the exercises he usually skips them anyway...). However, he recently started doing some codecademy exercises and really enjoys it. It seems like it wouldn't be too hard to turn the Quick guide into something similar by using something like WeScheme. I also know of several people who have expressed interest in learning to program but definitely don't have the motivation to go through HtDP. It seems like the codecademy approach is ideal for those types of people (the people who would like to dip their feet before diving in). Depending on what motivates the person, _Picturing Programs_ might work. It starts with graphics on page 1, and starts building event-driven GUI programs before you ever see an arithmetic operator. See picturingprograms.org . On the other hand, if your brother is the sort to want to absorb a lot of material quickly, Picturing Programs probably isn't ideal: it goes more slowly than HtDP. Stephen Bloch sbl...@adelphi.edu _ Racket Developers list: http://lists.racket-lang.org/dev
