Re: [racket-dev] Racket Guide chapter on concurrency

[David T. Pierson]

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

Re: [racket-dev] Racket Guide chapter on concurrency

[David T. Pierson]

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] What can cause "Interactions disabled"?

[Robby Findler]

Probably the check box should make finer distinctions, yes (altho the
plumbing inside is the same, as it turns out).

And, FWIW setting it to #t will probably only say "you ran out of memory".
And at the command line, you don't have drracket hogging all that memory so
probably that's the best thing, regardless.

Robby


On Mon, Oct 7, 2013 at 5:14 PM, Neil Toronto  wrote:

> I have that preference set to #f, if this is what it looks like in the
> preferences file:
>
> (plt:framework-pref:drracket:**show-killed-dialog #f)
>
> Apparently, it got set to #f when I unchecked "Show this dialog next time"
> once after I hit Ctrl-K and DrRacket warned me that I couldn't use the REPL
> until I re-ran the program. At least, that's how I interpreted the message.
> Given my interpretation, that seems like an overloaded setting. My mental
> model of running programs differentiates Ctrl-K and an error, so I expect
> the message box for Ctrl-K to be different from the error message box. Is
> that wrong?
>
> I'll set it to #t and try the simulation in DrRacket again soon-ish. (For
> now, I need to use the command line because this is for a paper that's due
> on Friday.)
>
> Thanks for your help!
>
> Neil ⊥
>
>
> On 10/07/2013 11:41 AM, Robby Findler wrote:
>
>> Then I think that that means that the message came from
>> rep.rkt's no-user-evaluation-message function and that you either should
>> have gotten a dialog with an explanation for why it terminated, or you
>> have the preference 'drracket:show-killed-dialog set to #f. I think that
>> the only two explanations are that 'exit' was called or that your ran
>> out of memory, but it may also be the case that you'd get a dialog with
>> no explanation. This could happen with this program, for example:
>>
>> #lang racket
>> (custodian-shutdown-all (current-custodian))
>>
>> or this one:
>>
>> #lang racket
>> (kill-thread (current-thread))
>>
>>
>> Or, it may be the case that you'd get a dialog with no explanation when
>> you ran out of memory, if there's a bug (race-condition or something
>> possibly).
>>
>> I don't see how you'd get the yellow/black warning message without
>> getting a dialog, tho, unless you have that pref set.
>>
>> Not much help, I know. Sorry.
>>
>> Robby
>>
>>
>>
>> On Mon, Oct 7, 2013 at 10:52 AM, Neil Toronto > > wrote:
>>
>> Black on yellow.
>>
>>
>> On 10/07/2013 09:50 AM, Robby Findler wrote:
>>
>> Was it black on yellow or red?
>>
>> Robby
>>
>>
>> On Mon, Oct 7, 2013 at 10:32 AM, Neil Toronto
>> mailto:neil.toro...@gmail.com**>
>> >
>> __>> wrote:
>>
>>  I have a long-running random simulation that spits out debug
>>  messages. I extrapolated that it would take 20 hours to get
>>  5,000,000 samples, and let it run for a day. Here's what I
>> saw when
>>  I returned:
>>
>>
>>  Welcome to DrRacket, version
>> 5.90.0.9--2013-10-04(876995d5/**d) [3m].
>>
>>
>>  Language: typed/racket [custom]; memory limit: 1024 MB.
>>  starting...
>>  sample-search-tree returned failure
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  i = 100
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>
>>  [...]
>>
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #f
>>  i = 2605500
>>  refinement-sample-point returned #f
>>  refinement-sample-point returned #

Re: [racket-dev] What can cause "Interactions disabled"?

[Neil Toronto]

I have that preference set to #f, if this is what it looks like in the 
preferences file:


(plt:framework-pref:drracket:show-killed-dialog #f)

Apparently, it got set to #f when I unchecked "Show this dialog next 
time" once after I hit Ctrl-K and DrRacket warned me that I couldn't use 
the REPL until I re-ran the program. At least, that's how I interpreted 
the message. Given my interpretation, that seems like an overloaded 
setting. My mental model of running programs differentiates Ctrl-K and 
an error, so I expect the message box for Ctrl-K to be different from 
the error message box. Is that wrong?


I'll set it to #t and try the simulation in DrRacket again soon-ish. 
(For now, I need to use the command line because this is for a paper 
that's due on Friday.)


Thanks for your help!

Neil ⊥

On 10/07/2013 11:41 AM, Robby Findler wrote:

Then I think that that means that the message came from
rep.rkt's no-user-evaluation-message function and that you either should
have gotten a dialog with an explanation for why it terminated, or you
have the preference 'drracket:show-killed-dialog set to #f. I think that
the only two explanations are that 'exit' was called or that your ran
out of memory, but it may also be the case that you'd get a dialog with
no explanation. This could happen with this program, for example:

#lang racket
(custodian-shutdown-all (current-custodian))

or this one:

#lang racket
(kill-thread (current-thread))


Or, it may be the case that you'd get a dialog with no explanation when
you ran out of memory, if there's a bug (race-condition or something
possibly).

I don't see how you'd get the yellow/black warning message without
getting a dialog, tho, unless you have that pref set.

Not much help, I know. Sorry.

Robby



On Mon, Oct 7, 2013 at 10:52 AM, Neil Toronto mailto:neil.toro...@gmail.com>> wrote:

Black on yellow.


On 10/07/2013 09:50 AM, Robby Findler wrote:

Was it black on yellow or red?

Robby


On Mon, Oct 7, 2013 at 10:32 AM, Neil Toronto
mailto:neil.toro...@gmail.com>
__>> wrote:

 I have a long-running random simulation that spits out debug
 messages. I extrapolated that it would take 20 hours to get
 5,000,000 samples, and let it run for a day. Here's what I
saw when
 I returned:


 Welcome to DrRacket, version
5.90.0.9--2013-10-04(876995d5/d) [3m].

 Language: typed/racket [custom]; memory limit: 1024 MB.
 starting...
 sample-search-tree returned failure
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 i = 100
 refinement-sample-point returned #f
 refinement-sample-point returned #f

 [...]

 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 i = 2605500
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f
 refinement-sample-point returned #f

 Interactions disabled
 |

560157:0720.77MB


 Fear my ASCII art status bar.

 "720.77MB" is what I got after clicking the GC indicator.
(Before,
 it w

Re: [racket-dev] Racket Guide chapter on concurrency

[John Clements]

On Oct 6, 2013, at 1:30 PM, David T. Pierson wrote:

> 
> 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

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?

John


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Racket Guide chapter on concurrency

[Jens Axel Søgaard]

If you need examples, take a look at:
   The Little Book of Semaphores
   http://www.greenteapress.com/semaphores/downey05semaphores.pdf

/Jens Axel


2013/10/6 David T. Pierson :
>
> 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



-- 
--
Jens Axel Søgaard

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Racket Guide chapter on concurrency

[David Vanderson]

This is fantastic!  Thank you!  I learned a good deal reading it just 
now.  Comments below:


On 10/06/2013 04:30 PM, David T. Pierson wrote:

1) Should it be broken into separate pages?

I'd leave it as a single page for now.  Easier to update.

2) It starts out with the basics of threads.  Is this too trivial to cover?

Please keep that part.  It gives the reader confidence.

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?
I think the text you have is good already.  The Guide and Reference are 
going to repeat some information, which is good.  Your page offers a 
quick overview, which is perfect for the Guide.  It would be nice to 
have a prescriptive sentence for each feature giving some guidance on 
when to use which, but I don't have the experience to write those.

4) Some of the examples feel clumsy.  Contriving concurrency examples
that are both simple and meaningful was hard.  I'm not sure I succeeded.

They are better than nothing!

make-arithmetic-thread is missing a "(let loop ()" line.  Later in the 
same example "(match" should be "(match item".


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?


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.


Thanks,
Dave

_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] What can cause "Interactions disabled"?

[Robby Findler]

Then I think that that means that the message came from
rep.rkt's no-user-evaluation-message function and that you either should
have gotten a dialog with an explanation for why it terminated, or you have
the preference 'drracket:show-killed-dialog set to #f. I think that the
only two explanations are that 'exit' was called or that your ran out of
memory, but it may also be the case that you'd get a dialog with no
explanation. This could happen with this program, for example:

#lang racket
(custodian-shutdown-all (current-custodian))

or this one:

#lang racket
(kill-thread (current-thread))


Or, it may be the case that you'd get a dialog with no explanation when you
ran out of memory, if there's a bug (race-condition or something possibly).

I don't see how you'd get the yellow/black warning message without getting
a dialog, tho, unless you have that pref set.

Not much help, I know. Sorry.

Robby



On Mon, Oct 7, 2013 at 10:52 AM, Neil Toronto wrote:

> Black on yellow.
>
>
> On 10/07/2013 09:50 AM, Robby Findler wrote:
>
>> Was it black on yellow or red?
>>
>> Robby
>>
>>
>> On Mon, Oct 7, 2013 at 10:32 AM, Neil Toronto > > wrote:
>>
>> I have a long-running random simulation that spits out debug
>> messages. I extrapolated that it would take 20 hours to get
>> 5,000,000 samples, and let it run for a day. Here's what I saw when
>> I returned:
>>
>>
>> Welcome to DrRacket, version 5.90.0.9--2013-10-04(876995d5/**__d)
>> [3m].
>>
>> Language: typed/racket [custom]; memory limit: 1024 MB.
>> starting...
>> sample-search-tree returned failure
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> i = 100
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>>
>> [...]
>>
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> i = 2605500
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>> refinement-sample-point returned #f
>>
>> Interactions disabled
>> |
>>
>>560157:0720.77MB
>>
>>
>> Fear my ASCII art status bar.
>>
>> "720.77MB" is what I got after clicking the GC indicator. (Before,
>> it was about 300MB.) There were no command-line messages from
>> DrRacket.
>>
>> I don't think this is an out-of-memory problem. DrRacket has been
>> good about asking for more during other simulations, my limit is set
>> to 1024MB, and I really doubt I'm allocating a 304MB temporary object.
>>
>> I wrote a small program to print 60 debug messages, thinking it
>> was a limit on the number of lines in the REPL, and it ran to
>> completion.
>>
>> For full disclosure: I paused and restarted DrRacket from the
>> command line (fg; ctrl-z; bg) a few times while the simulation was
>> running, so I could use my laptop unplugged without draining the
>> battery.
>>
>> Besides running out of memory, what else could cause a program to
>> halt with "Interactions disabled", and how can I avoid it?
>>
>> Neil ⊥
>> _
>>   Racket Developers list:
>> http://lists.racket-lang.org/_**_dev<
>> http://lists.racket-lang.org/**dev >
>>
>>
>>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] What can cause "Interactions disabled"?

[Neil Toronto]

Black on yellow.

On 10/07/2013 09:50 AM, Robby Findler wrote:

Was it black on yellow or red?

Robby


On Mon, Oct 7, 2013 at 10:32 AM, Neil Toronto mailto:neil.toro...@gmail.com>> wrote:

I have a long-running random simulation that spits out debug
messages. I extrapolated that it would take 20 hours to get
5,000,000 samples, and let it run for a day. Here's what I saw when
I returned:


Welcome to DrRacket, version 5.90.0.9--2013-10-04(876995d5/__d) [3m].
Language: typed/racket [custom]; memory limit: 1024 MB.
starting...
sample-search-tree returned failure
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
i = 100
refinement-sample-point returned #f
refinement-sample-point returned #f

[...]

refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
i = 2605500
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f

Interactions disabled
|

   560157:0720.77MB


Fear my ASCII art status bar.

"720.77MB" is what I got after clicking the GC indicator. (Before,
it was about 300MB.) There were no command-line messages from DrRacket.

I don't think this is an out-of-memory problem. DrRacket has been
good about asking for more during other simulations, my limit is set
to 1024MB, and I really doubt I'm allocating a 304MB temporary object.

I wrote a small program to print 60 debug messages, thinking it
was a limit on the number of lines in the REPL, and it ran to
completion.

For full disclosure: I paused and restarted DrRacket from the
command line (fg; ctrl-z; bg) a few times while the simulation was
running, so I could use my laptop unplugged without draining the
battery.

Besides running out of memory, what else could cause a program to
halt with "Interactions disabled", and how can I avoid it?

Neil ⊥
_
  Racket Developers list:
http://lists.racket-lang.org/__dev 




_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] What can cause "Interactions disabled"?

[Robby Findler]

Was it black on yellow or red?

Robby


On Mon, Oct 7, 2013 at 10:32 AM, Neil Toronto wrote:

> I have a long-running random simulation that spits out debug messages. I
> extrapolated that it would take 20 hours to get 5,000,000 samples, and let
> it run for a day. Here's what I saw when I returned:
>
>
> Welcome to DrRacket, version 5.90.0.9--2013-10-04(876995d5/**d) [3m].
> Language: typed/racket [custom]; memory limit: 1024 MB.
> starting...
> sample-search-tree returned failure
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> i = 100
> refinement-sample-point returned #f
> refinement-sample-point returned #f
>
> [...]
>
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> i = 2605500
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
> refinement-sample-point returned #f
>
> Interactions disabled
> |
>
>   560157:0720.77MB
>
>
> Fear my ASCII art status bar.
>
> "720.77MB" is what I got after clicking the GC indicator. (Before, it was
> about 300MB.) There were no command-line messages from DrRacket.
>
> I don't think this is an out-of-memory problem. DrRacket has been good
> about asking for more during other simulations, my limit is set to 1024MB,
> and I really doubt I'm allocating a 304MB temporary object.
>
> I wrote a small program to print 60 debug messages, thinking it was a
> limit on the number of lines in the REPL, and it ran to completion.
>
> For full disclosure: I paused and restarted DrRacket from the command line
> (fg; ctrl-z; bg) a few times while the simulation was running, so I could
> use my laptop unplugged without draining the battery.
>
> Besides running out of memory, what else could cause a program to halt
> with "Interactions disabled", and how can I avoid it?
>
> Neil ⊥
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/**dev 
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] What can cause "Interactions disabled"?

[Neil Toronto]

I have a long-running random simulation that spits out debug messages. I 
extrapolated that it would take 20 hours to get 5,000,000 samples, and 
let it run for a day. Here's what I saw when I returned:



Welcome to DrRacket, version 5.90.0.9--2013-10-04(876995d5/d) [3m].
Language: typed/racket [custom]; memory limit: 1024 MB.
starting...
sample-search-tree returned failure
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
i = 100
refinement-sample-point returned #f
refinement-sample-point returned #f

[...]

refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
i = 2605500
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f
refinement-sample-point returned #f

Interactions disabled
|

  560157:0720.77MB


Fear my ASCII art status bar.

"720.77MB" is what I got after clicking the GC indicator. (Before, it 
was about 300MB.) There were no command-line messages from DrRacket.


I don't think this is an out-of-memory problem. DrRacket has been good 
about asking for more during other simulations, my limit is set to 
1024MB, and I really doubt I'm allocating a 304MB temporary object.


I wrote a small program to print 60 debug messages, thinking it was 
a limit on the number of lines in the REPL, and it ran to completion.


For full disclosure: I paused and restarted DrRacket from the command 
line (fg; ctrl-z; bg) a few times while the simulation was running, so I 
could use my laptop unplugged without draining the battery.


Besides running out of memory, what else could cause a program to halt 
with "Interactions disabled", and how can I avoid it?


Neil ⊥
_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] package system, minimal builds and more

[Tobias Hammer]

All in one answer

On Tue, 01 Oct 2013 15:30:11 +0200, Neil Toronto   
wrote:

On 10/01/2013 09:20 AM, Tobias Hammer wrote:

* monolithic math
currently math is one big package and installing it pulls in nearly
everything through the docs. Is it planned to split it into -lib and  
-doc?


We were waiting for a reason. This is one. I'll try it on my flight home  
tonight. (Never done any package management before.)


Thanks for tackling this. I think its worth the effort.

I suppose this is a good rule of thumb: if your docs make pictures, put  
them in a separate package.


Yes, thats a good minimum requirement. For standalone builds or for small  
devices it
would be even better if it's possible to build everything that might be  
useful in

this setting without a single doc.


On Thu, 03 Oct 2013 17:26:08 +0200, Robby Findler  
 wrote:



These two are fixed now (with the snapshot build
http://plt.eecs.northwestern.edu/snapshots/20131003-154d940/).


Thanks, will try as soon as possible.


On Wed, 02 Oct 2013 16:39:42 +0200, Sam Tobin-Hochstadt  
 wrote:



* raco pkg warnings
On every command i get
warning: tool "pkg" registered twice: "pkg" and
#
warning: tool "setup" registered twice: "setup" and
#
warning: tool "link" registered twice: "link" and
#
 /home/hamm_to/tmp/racket/_tmp/racket-5.90.0.9/ is the used installation.


What command did you run to get this error? I haven't been able to  
replicate it.


It seems to only happen if i have "PLTCOLLECTS=:", not if it's set to  
anything else to unset.

Then a "raco pkg" is enough to trigger it.



You can see these with `raco pkg show`.  Is that what you're looking for?


Exactly what i was looking for (raco pkg show -a -d). Thanks.


On Wed, 02 Oct 2013 18:32:51 +0200, Jay McCarthy   
wrote:



I think I need more details.

If you have pkg A installed, then it should only download a small
checksum to see if A needs to be updated. If this is broken, then it
is an error.


That works as supposed.


If you do NOT have pkg A installed, then it will download the full
file. If that install fails, then 'raco pkg' cleans up after itself
and deletes the things it downloaded. Apt does not do this and saves
everything in a temporary directory that must be manually cleaned. I
did not implement that because it feels wrong to run a command like
'raco pkg clean-old-tmp-files' or something. But it sounds like you
want that?


Yes, that's what i had in mind because I'm used to this behavior and i was
wondering why raco downloaded the files over and over on a _failed_ install
(Only noticed it because it was a relatively large install). But the  
temporary
files are a good point that i completely forgot. I think, in hope that  
installs

(hopefully) rarely fail it's better as it is now.

Tobias
_
 Racket Developers list:
 http://lists.racket-lang.org/dev