Hi Roman
> I think, Alejandro wanted to add clauses in different places (generic in
one module, added method in another, for example).
Quite possibly, or perhaps not! ;-)
Alejandro gave an example of one declaration mechanism that he'd seen in
CL. Hard to tell whether that's optimal for his cont
A different way of putting this might be that the Emacs way is to be a
lighter-weight environment, and to rely on process mechanisms more than
DrRacket does. I personally like that break always works in DrRacket, but
I can also see taking the other side of these tradeoffs.
Sam
On Apr 5, 2014 5:15
Also (and again FWIW), I see what you are saying as "the OS is also good at
killing things" which is certainly true. You could just do it that way all
the time in fact!
Robby
On Saturday, April 5, 2014, Robby Findler
wrote:
> It is not a difficult change to the code I saw to get this to always
It is not a difficult change to the code I saw to get this to always work.
FWIW.
On Saturday, April 5, 2014, Greg Hendershott
wrote:
> > What if you do this:
> >
> > (let l () (with-handlers ([void (l)]) (l)))
> >
> > This catches `exn:break` (and everything else) and calls `l`.
>
> Then I w
> What if you do this:
>
> (let l () (with-handlers ([void (l)]) (l)))
>
> This catches `exn:break` (and everything else) and calls `l`.
Then I would type C-c C-k yes to kill the buffer. :)
And then I would re-read the documentation for `with-handlers`, which
recommends not to do that. :)
Se
On Sat, Apr 5, 2014 at 3:20 PM, Spencer Florence wrote:
> In xrepl that program catches breaks as well, so that behavior is probably
> fine and unavoidable.
>
> Although somehow drracket's repl managed to break out of that program. I
> wonder how it does that...
Robby's answers in this thread are
In xrepl that program catches breaks as well, so that behavior is probably
fine and unavoidable.
Although somehow drracket's repl managed to break out of that program. I
wonder how it does that...
On Sat, Apr 5, 2014 at 3:00 PM, Sam Tobin-Hochstadt wrote:
> What if you do this:
>
> (let l (
What if you do this:
(let l () (with-handlers ([void (l)]) (l)))
This catches `exn:break` (and everything else) and calls `l`.
Sam
On Sat, Apr 5, 2014 at 2:54 PM, Greg Hendershott
wrote:
>> thread cells are subject to GC and that's fine. The real issue is that I
>> might write a program th
> thread cells are subject to GC and that's fine. The real issue is that I
> might write a program that does (effectively) this:
>
> > (let l()(l))
>
> and then I'm stuck.
Good point, but that's not a problem. A break returns to read-eval-print-loop.
Example transcript:
> (let l () (l))
C-cC-c
This won't work I don't think.
You can't move a computation to another thread like that unless the
computation is willing to be moved (and random Racket programs will not
have set themselves up to be moved).
If you're not worried about running in unix headless contexts, then I think
all you need
thread cells are subject to GC and that's fine. The real issue is that I
might write a program that does (effectively) this:
> (let l()(l))
and then I'm stuck.
Robby
On Sat, Apr 5, 2014 at 1:15 PM, Greg Hendershott
wrote:
> Oh wait. There could be per-thread "resources". Such as thread cells
Oh, okay. I guess that works if you don't actually need a kill switch that
can always kill, ie if you just need a kill switch that can kill when the
REPL prompt returns (or something along those lines). I'm having trouble
seeing why that is the right choice (or why killing the thread is a
problem)
Oh wait. There could be per-thread "resources". Such as thread cells?
That's why it really ought to be a fresh thread?
On Sat, Apr 5, 2014 at 1:58 PM, Greg Hendershott
wrote:
>> re grokking extra thread: No no, that's not what I'm saying. I'm saying that
>> if you don't create the extra thread, t
Yes, that aspect of it -- attaching the racket/gui/base module, if
any, from the old namespace to the new one -- I figured out fairly
fast and it has been working fine in my testing so far.
The tricky part is that I seem to need a hypothetical
"custodian-shutdown-all-except-the-root-main-eventspac
> re grokking extra thread: No no, that's not what I'm saying. I'm saying that
> if you don't create the extra thread, then the custodian's protection is
> circumvented. The thread you get started on is not under the auspices of the
> custodian you created, so that thread doesn't get shutdown when
Oh, and I see a second issue that you're probably getting at: in the case
you decide you are going to run GUI programs (via the emacs-level variable
if you don't find a better way than my recommendation) you need to share
'(lib "mred/mred.rkt") (or maybe it is okay to share racket/gui/base)
between
re grokking extra thread: No no, that's not what I'm saying. I'm saying
that if you don't create the extra thread, then the custodian's protection
is circumvented. The thread you get started on is not under the auspices of
the custodian you created, so that thread doesn't get shutdown when you
shut
Thank you Robby. I've spent some time thinking about your response,
trying to make use of it, and even looking at some
mred/private/common/wx code.
First, I don't grok the need for an extra thread. This is for an Emacs
mode REPL. It's quite similar to Racket's xrepl, which doesn't use an
extra thr
18 matches
Mail list logo
