Neil Jerram <[EMAIL PROTECTED]> writes:
> How about renaming the internal scm_frame functions instead, since
> AFAIK they haven't been released yet?
Yep, I'll do that.
> Perhaps scm_context_..., or scm_dynwind_..., or scm_dc_...?
I'm going with scm_dynwind_ since the functions are directly rela
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Andy Wingo <[EMAIL PROTECTED]> writes:
>
>> - scm_frame_begin, unwind_handler, etc -- should change because there
>> is also a SCM-based scm_frame interface
>
> Yeah, that's unfortunate. we have two things that are termed a
> "frame": he things dealt
Andy Wingo <[EMAIL PROTECTED]> writes:
> 1) functions that take C types normally are named scm_c_*. There are a
> few exceptions though:
The rule is that scm_c_foo is mostly the same as scm_foo, only with a
different calling convention that is easier for C. For example, we
have scm_vector_length
Hi,
A few potential API bugs.
1) functions that take C types normally are named scm_c_*. There are a
few exceptions though:
- scm_from_locale_symbol[n] -- here's a confusing name, perhaps
scm_c_symbol_from_locale_string is more apt -- but this function will be
used frequently, so there is an adv
