Doug Evans skribis:
> On Fri, May 2, 2014 at 4:19 PM, Ludovic Courtès wrote:
>> Doug Evans skribis:
>>
>>> On Fri, May 2, 2014 at 4:44 AM, Ludovic Courtès wrote:
Doug Evans skribis:
> While function declarations are markable as being internal/external in
> published headers
On Tue, Apr 29, 2014 at 11:25 AM, Andy Wingo wrote:
> Hi!
>
> Thanks for the feedback, it's really useful.
>
> On Tue 29 Apr 2014 17:56, Doug Evans writes:
>
>> The struct interface, contrary to what the documentation says, takes a
>> stdarg list beginning with the number of fields (and not termi
On Sun, Apr 27, 2014 at 10:51 AM, Andy Wingo wrote:
>[...]
>> Portability is more problematic for pointer types. The C standards make
>> no guarantees about the semantics of converting between pointers and
>> integers, and it's not clear to me how future proof this will be.
>
> Don't they make so
On Fri, May 2, 2014 at 4:19 PM, Ludovic Courtès wrote:
> Doug Evans skribis:
>
>> On Fri, May 2, 2014 at 4:44 AM, Ludovic Courtès wrote:
>>> Doug Evans skribis:
>>>
While function declarations are markable as being internal/external in
published headers (SCM_INTERNAL vs SCM_API), macr
Doug Evans skribis:
> On Fri, May 2, 2014 at 4:44 AM, Ludovic Courtès wrote:
>> Doug Evans skribis:
>>
>>> While function declarations are markable as being internal/external in
>>> published headers (SCM_INTERNAL vs SCM_API), macros are not.
>>
>> Internal macros are marked by a naming convent
On Fri, May 2, 2014 at 4:44 AM, Ludovic Courtès wrote:
> Doug Evans skribis:
>
>> While function declarations are markable as being internal/external in
>> published headers (SCM_INTERNAL vs SCM_API), macros are not.
>
> Internal macros are marked by a naming convention: they are prefixed by
> ‘S
Doug Evans skribis:
> While function declarations are markable as being internal/external in
> published headers (SCM_INTERNAL vs SCM_API), macros are not.
Internal macros are marked by a naming convention: they are prefixed by
‘SCM_I’.
If this convention is deemed insufficient, we could #ifdef
Hi!
On Tue 29 Apr 2014 18:33, Doug Evans writes:
> On Sun, Apr 27, 2014 at 6:17 AM, Andy Wingo wrote:
>>
>> [...]
>> 7) There is legacy code out there that uses e.g. SCM_SETCDR to set
>> smob fields. (This is terrible, but it exists:
>> https://github.com/search?q=SCM_SETCDR+smob&r
Hi!
On Tue 29 Apr 2014 18:08, Doug Evans writes:
> Hi. fwiw, this is all great stuff (and welcome!), but I think it's in
> the wrong place in the docs.
> The issue comes up in multiple places, so I would write it ("it" being
> the general prose regarding issues with finalizers) once and refer to
Hi!
Thanks for the feedback, it's really useful.
On Tue 29 Apr 2014 17:56, Doug Evans writes:
> The struct interface, contrary to what the documentation says, takes a
> stdarg list beginning with the number of fields (and not terminated
> with SCM_UNDEFINED), instead of _1, _2, _3
This is what
On Sun, Apr 27, 2014 at 6:17 AM, Andy Wingo wrote:
> Hi,
>
> SMOBs have a few problems.
>
> [...]
> 7) There is legacy code out there that uses e.g. SCM_SETCDR to set
> smob fields. (This is terrible, but it exists:
> https://github.com/search?q=SCM_SETCDR+smob&ref=cmdform&type=Code
>
On Mon, Apr 28, 2014 at 9:08 AM, Andy Wingo wrote:
> [...]
> 1.4 Foreign Object Memory Management
>
>
> Once a foreign object has been released to the tender mercies of the
> Scheme system, it must be prepared to survive garbage collection. In
> the example ab
On Sun, Apr 27, 2014 at 6:17 AM, Andy Wingo wrote:
> Hi,
>
> SMOBs have a few problems.
>
> 1) They are limited in number to 255.
>
> 2) It's difficult to refer to a SMOB type from Scheme. You can use
> class-of once you have an object, but the class-of isn't exactly
> the same as t
On Mon 28 Apr 2014 10:24, l...@gnu.org (Ludovic Courtès) writes:
> I would have preferred to rebase SMOBs on top of structs, with the added
> documentation as to how they can be accessed from Scheme, but I suppose
> this is ruled out by the SCM_SETCDR issue above?
We can think of doing this in th
On Sun 27 Apr 2014 18:46, Stefan Israelsson Tampe
writes:
> FYI I need need the gc mark interface for my prolog variables in order
> to hope for garbage collecting of prolog programs, e.g. clean the
> variables bindings in the prolog stack for variables that no longer is
> referenced. It is poss
On Sun 27 Apr 2014 18:00, Mark H Weaver writes:
> Andy Wingo writes:
>
>> I propose to provide a new interface that will eventually make SMOBs
>> obsolete. This new interface is based on structs with raw fields -- the
>> 'u' fields. (See
>> http://www.gnu.org/software/guile/docs/master/guile.h
Hello!
Andy Wingo skribis:
> 7) There is legacy code out there that uses e.g. SCM_SETCDR to set
> smob fields. (This is terrible, but it exists:
> https://github.com/search?q=SCM_SETCDR+smob&ref=cmdform&type=Code
> for an example.)
[...]
> I propose to provide a new interface
Hi Mark,
Thanks for the review!
On Sun 27 Apr 2014 18:00, Mark H Weaver writes:
> Andy Wingo writes:
>
>> Here is the proposed C API:
>>
>> SCM scm_make_foreign_object_type (SCM name, SCM slot_names,
>> scm_t_struct_finalize finalizer);
>
> Shouldn't i
Currently only having 256 smob types is enough arguments for the additions.
This can only be a good thing even if I need to the current smob for
modelling prolog variables (the overhead of 2 words is a bit heavy if
you only have one data slot). So it is brilliant to dispatch all the
multitude of la
Hi Andy,
Andy Wingo writes:
> I propose to provide a new interface that will eventually make SMOBs
> obsolete. This new interface is based on structs with raw fields -- the
> 'u' fields. (See
> http://www.gnu.org/software/guile/docs/master/guile.html/Vtables.html#Vtables
> for description of '
20 matches
Mail list logo
