* Doing more with the new frames
@ 2004-01-04 1:08 Marius Vollmer
2004-01-13 17:28 ` Rob Browning
0 siblings, 1 reply; 2+ messages in thread
From: Marius Vollmer @ 2004-01-04 1:08 UTC (permalink / raw)
Ok,
so the manual now says
[...] For example, you can register a cleanup routine with
scm_on_unwind that is executed when the frame is left. There are
several other more specialized frame actions as well, for example
to temporarily block the execution of asyncs or to temporarily
change the current output port. They are described elsewhere in
this manual.
How far do we want to go with this? Is it even a good idea?
For example, the next thing would be do offer scm_block_asyncs and
scm_unblock_asyncs that could be used like
scm_begin_frame (SCM_F_FRAME_REWINDABLE);
scm_block_asyncs ();
[ asyncs are blocked here. ]
scm_end_frame ();
This is quite nice I think, when you get the idea and use
scm_block_async correctly. However, when people see scm_block_asyncs
and scm_unblock_asyncs in async.h, they might be inclined to use them as
scm_block_asyncs ();
[ asyncs are blocked here? ]
scm_unblock_asyncs ();
This would be quite wrong. Ok, scm_block_asyncs is probably unique
since there is also scm_unblock_asyncs which wouldn't be there for,
say, scm_with_current_output.
Should we worry?
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Doing more with the new frames
2004-01-04 1:08 Doing more with the new frames Marius Vollmer
@ 2004-01-13 17:28 ` Rob Browning
0 siblings, 0 replies; 2+ messages in thread
From: Rob Browning @ 2004-01-13 17:28 UTC (permalink / raw)
Cc: guile-devel
Marius Vollmer <mvo@zagadka.de> writes:
> This is quite nice I think, when you get the idea and use
> scm_block_async correctly. However, when people see scm_block_asyncs
> and scm_unblock_asyncs in async.h, they might be inclined to use them as
>
> scm_block_asyncs ();
>
> [ asyncs are blocked here? ]
>
> scm_unblock_asyncs ();
>
> This would be quite wrong. Ok, scm_block_asyncs is probably unique
> since there is also scm_unblock_asyncs which wouldn't be there for,
> say, scm_with_current_output.
>
> Should we worry?
As long as our documentation is good enough that people don't have to
figure things out by poking around in the headers and guessing, then I
suspect it's fine. It'd probably be a good idea to have cross-refs in
the scm_begin_frame docs to all the other relevant "modifier"
functions.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-01-13 17:28 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-04 1:08 Doing more with the new frames Marius Vollmer
2004-01-13 17:28 ` Rob Browning
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).