Re: [racket-dev] Interactive Tutorial

2012-03-23 Thread Stephen Bloch

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


Re: [racket-dev] [plt] Push #24082: master branch updated

2012-03-23 Thread Jay McCarthy
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  wrote:
> On 03/22/2012 03:27 PM, Jay McCarthy wrote:
>> Someone else noticed this warning.
>>
>> http://bugs.racket-lang.org/query/?cmd=view&pr=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 
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] [racket] nightly build available as a ppa

2012-03-23 Thread Sam Tobin-Hochstadt
[on dev@]

On Fri, Mar 23, 2012 at 12:24 PM, Jon Rafkind  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] Oversight in type for path-string?

2012-03-23 Thread Sam Tobin-Hochstadt
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  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"  wrote:
>>
>>
>> On Mar 21, 2012, at 3:20 PM, Sam Tobin-Hochstadt wrote:
>>
>> > On Wed, Mar 21, 2012 at 5:36 PM, John Clements
>> >  wrote:
>> >> It looks like 'path-string?' is not labeled as a discriminator type.
>> >>
>> >>> path-string?
>> >> - : (Any -> Boolean)
>> >> #
>> >>>
>> >>
>> >> 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] Oversight in type for path-string?

2012-03-23 Thread Eric Dobson
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"  wrote:

>
> On Mar 21, 2012, at 3:20 PM, Sam Tobin-Hochstadt wrote:
>
> > On Wed, Mar 21, 2012 at 5:36 PM, John Clements
> >  wrote:
> >> It looks like 'path-string?' is not labeled as a discriminator type.
> >>
> >>> path-string?
> >> - : (Any -> Boolean)
> >> #
> >>>
> >>
> >> 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] submodules

2012-03-23 Thread Matthew Flatt
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] [plt] Push #24082: master branch updated

2012-03-23 Thread Ryan Culpepper

On 03/22/2012 03:27 PM, Jay McCarthy wrote:

Someone else noticed this warning.

http://bugs.racket-lang.org/query/?cmd=view&pr=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