12:53 a.m.
Hi all,
First, I'm asking for some advice and/or thoughts. Even so, I may
decide to do something completely different after reading all the
replies. You have been warned.
For reference, I've been working on a libClang wrapper. I already
have a little more than a hello-world already, and have wrapped three
types, and implemented a few functions that return and use these
types.
What's currently bothering me, is how to handle a type like CXCursor,
http://clang.llvm.org/doxygen/structCXCursor.html
which is not completely opaque. (Opaque types are rather easy).
First of all, I believe it'll be beneficial to be able to (get cursor
'kind) and possibly (get cursor 'xdata) which is an integer. However,
there is also a documented void * in it.
This void pointer is kind of "bothering" me. I can quite easily
return nil from (get cursor 'data) and I can also signal an error.
Are there any other sane options?
For the record, for now, (put cursor ...) and (remprop cursor ...) are
not supported; and never may be. As in, trying to use them results in
an error.
On the other hand (object-plist cursor) isn't even implemented, and I
have no idea what to do with it. Any ideas?
Also, the (get cursor 'kind) returns another type, which I've not yet
wrapped. This is an enumerator documented at
http://clang.llvm.org/doxygen/group__CINDEX.html#gaaccc432245b4cd9f2d4709...
and I wonder what some options are to represent this in elisp? My
first thought is to represent it as symbols (possibly even keywords).
Another would be to create yet another type and create constants.
This can potentially also be done with integers.
Any comments on the pros and cons of the various options? So far, I
don't have enough experience with the libClang interface to actually
form an opinion. I may even decide to try a few options and see which
feels best.
That's it for now,
Johann
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:32 a.m.
Johann 'Myrkraverk' Oskarsson writes:
This void pointer is kind of "bothering" me. I can quite
easily
return nil from (get cursor 'data) and I can also signal an error.
Are there any other sane options?
You can return a type derived from Lisp_Opaque object, which is just a
blob of memory containing the data. That's all you need to do if it
just gets passed to other libClang objects. Turning it into an
integer or the like is a bad idea, as that means you can't type check
objects passed to libClang interfaces.
On the other hand (object-plist cursor) isn't even implemented,
and
I have no idea what to do with it. Any ideas?
Property lists are application-specific, user-supplied attributes. If
the cursor type doesn't need them you don't need to implement it.
Also, the (get cursor 'kind) returns another type, which I've
not yet
wrapped. This is an enumerator documented at
http://clang.llvm.org/doxygen/group__CINDEX.html#gaaccc432245b4cd9f2d4709...
and I wonder what some options are to represent this in elisp?
I would most likely use symbols. Whether to use keywords is a matter
of taste. I probably wouldn't. Using integers isn't a great idea;
you can't type check them. If you need to allow users to write
programs where the ints in the underlying enum are directly input,
that can be done with a helper program at the Lisp level. But I would
not support that -- I'd tell the user to write their own
int-to-enumerator helper function if they want that. Creating a
separate enum type seems like overengineering; if you want to
introspect the set of enumerators, a defconst at Lisp level seems
sufficient. If you really want to, you can create that list read-only
at the C level in your module.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:45 p.m.
Hi Stephen, xemacs-beta,
On Wed, Nov 26, 2014 at 3:32 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Johann 'Myrkraverk' Oskarsson writes:
You can return a type derived from Lisp_Opaque object, which is just
a
blob of memory containing the data. That's all you need to do if it
just gets passed to other libClang objects. Turning it into an
integer or the like is a bad idea, as that means you can't type check
objects passed to libClang interfaces.
Since, afaict, this particular void * is never passed around directly,
I think I'll just hide it from the lisp level completely. Maybe just
throw a semi-helpful error if anyone tries to (get) it.
That said, I never grokked how to use Lisp_Opaque. So far I've been
using lcrecords, which are both semi-documented and have an interface
for modules. I say semi-documented because there are things missing
from the comments in lrecord.h about implementing them in a module.
Maybe I'll write a short tutorial when I have slightly more experience.
Property lists are application-specific, user-supplied attributes.
If
the cursor type doesn't need them you don't need to implement it.
Ok, then the question is, what is a better strategy, not to implement
it at all, which gives the error "Object type has no properties" which
can be slightly surprising and misleading if any of the (get), (put)
and (remprop) are implemented; vs. returning nil?
I'd like answers from people who have actually used property lists for
something; if any.
And on that note, why is that the internal putprop callback is
supposed to return 0 to throw a lisp error, but the remprop callback
is supposed to return -1? Wouldn't it have been better to synchronize
it? (This is from Fput and Fremprop in fns.c). I also just checked,
and afaict, this has not changed in 21.5. Given how few modules are
actually out there (mine may be the only one who does types) do you
want to change it?
> Also, the (get cursor 'kind) returns another type, which
I've not yet
> wrapped. This is an enumerator documented at
>
>
http://clang.llvm.org/doxygen/group__CINDEX.html#gaaccc432245b4cd9f2d4709...
>
> and I wonder what some options are to represent this in elisp?
I would most likely use symbols. Whether to use keywords is a matter
of taste. I probably wouldn't. [...] Creating a
separate enum type seems like overengineering; if you want to
introspect the set of enumerators, a defconst at Lisp level seems
sufficient. If you really want to, you can create that list read-only
at the C level in your module.
Overengineering or not, it does make it slightly easier to typecheck
for the functions that take these enumerators as arguments; see here:
http://clang.llvm.org/doxygen/group__CINDEX__CURSOR__MANIP.html#func-members
But that doesn't mean I can't use symbols. Maybe I'll do it the XP
way and try both a type wrapper and symbols to see which feels better.
Have fun,
Johann
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:48 a.m.
Johann 'Myrkraverk' Oskarsson writes:
And on that note, why is that the internal putprop callback is
supposed to return 0 to throw a lisp error, but the remprop callback
is supposed to return -1? Wouldn't it have been better to synchronize
it? (This is from Fput and Fremprop in fns.c).
All types, not just types in modules, use these conventions. I don't
think it's worth changing at this late date.
I also just checked, and afaict, this has not changed in 21.5.
Given how few modules are actually out there (mine may be the only
one who does types) do you want to change it?
What do you mean by "type"? As I use the word, every lrecord/lcrecord
is a different type. Most modules do create specialized lrecords, and
aside from those there are currently over 100 different ones in the
enum of lrecord_types in core.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:35 p.m.
Hi Stephen, xemac-beta,
On Thu, Nov 27, 2014 at 9:48 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Johann 'Myrkraverk' Oskarsson writes:
> And on that note, why is that the internal putprop callback is
> supposed to return 0 to throw a lisp error, but the remprop callback
> is supposed to return -1? Wouldn't it have been better to synchronize
> it? (This is from Fput and Fremprop in fns.c).
All types, not just types in modules, use these conventions. I don't
think it's worth changing at this late date.
But there are only a handful of lrecords who actually implement
properties: strings, extents, faces, glyphs, symbols, gtkobjects and
gtkboxed; in 21.4 at least. Of course there can be more types that do
this too.
Has that changed in 21.5 so everything can have properties?
Anyway, the question is really about lowering the barrier for new
module developers.
> I also just checked, and afaict, this has not changed in 21.5.
> Given how few modules are actually out there (mine may be the only
> one who does types) do you want to change it?
What do you mean by "type"? As I use the word, every lrecord/lcrecord
is a different type. Most modules do create specialized lrecords, and
aside from those there are currently over 100 different ones in the
enum of lrecord_types in core.
In this case, I mean an emodule that implements a type.
Have fun,
Johann
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:25 p.m.
Johann 'Myrkraverk' Oskarsson writes:
But there are only a handful of lrecords who actually implement
properties: strings, extents, faces, glyphs, symbols, gtkobjects and
gtkboxed; in 21.4 at least. Of course there can be more types that do
this too.
Possibly some that you don't know about and can't fix. I have at
least three branches (currently dormant) that implement new types. I
don't remember offhand whether any of them implement object property
lists, but all are intended for the mainline "someday". It would be
annoying to track down such a bug.
Has that changed in 21.5 so everything can have properties?
Quite possibly more do, but it would probably still be only a handful.
Anyway, the question is really about lowering the barrier for new
module developers.
Not entirely. You also have to consider not screwing old ones.
Neither of us has any idea how many such types exist out in people's
workspaces, not just in modules but in modified cores, too. XEmacs
has long been a favorite platform for corporate variants, for example.
> What do you mean by "type"? As I use the word, every
lrecord/lcrecord
> is a different type. Most modules do create specialized lrecords, and
> aside from those there are currently over 100 different ones in the
> enum of lrecord_types in core.
In this case, I mean an emodule that implements a type.
But what do you mean by "implement a type"? Both ldap and postgresql,
as well as my unmerged branches, all create and register new lrecord
types as extensions to the enum in lrecord.h. I consider that to be
implementing a type. Do you?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:33 p.m.
Hi Stephen, xemacs-beta,
On Thu, Nov 27, 2014 at 3:25 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
> In this case, I mean an emodule that implements a type.
But what do you mean by "implement a type"? Both ldap and postgresql,
as well as my unmerged branches, all create and register new lrecord
types as extensions to the enum in lrecord.h. I consider that to be
implementing a type. Do you?
Emodule = foo.ell that gets loaded at run time. None of the modules
currently in XEmacs that implement types are emodules.
That's what I'm talking about.
Johann
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:39 p.m.
Johann 'Myrkraverk' Oskarsson writes:
Emodule = foo.ell that gets loaded at run time.
I know what an emodule is, I've debugged several and written a couple
myself.
None of the modules currently in XEmacs that implement types are
emodules.
I still don't understand what you're saying. modules/postgresql and
modules/ldap both implement types as far as I can see (look for
DEFINE_NODUMP_LISP_OBJECT). Both are normally built as .ells (for
example, in the XEmacs I'm typing this message in they are). They can
be linked into the xemacs binary if you want (but all emodule code can
be linked into the xemacs binary).
If you say they don't implement types, then you have a completely
different definition of "implement type" than I do, and that
definition is what I want to know.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:50 p.m.
Hi Stephen, xemacs-beta,
On Thu, Nov 27, 2014 at 5:39 PM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
I still don't understand what you're saying.
modules/postgresql and
modules/ldap both implement types as far as I can see (look for
DEFINE_NODUMP_LISP_OBJECT). Both are normally built as .ells (for
example, in the XEmacs I'm typing this message in they are). They can
be linked into the xemacs binary if you want (but all emodule code can
be linked into the xemacs binary).
Will you forgive me for not knowing about these details in the 21.5 branch?
If you say they don't implement types, then you have a
completely
different definition of "implement type" than I do, and that
definition is what I want to know.
What I meant, and stand by, is that external emodules that implement
types are so rare they're practically nonexistent; particularly those
that do properties.
In this context, what's part of xemacs core doesn't matter, because
any changes to the ABI* will fix those too.
Johann
* I do mean Application Binary Interface.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:03 p.m.
Johann 'Myrkraverk' Oskarsson writes:
Will you forgive me for not knowing about these details in the 21.5
branch?
Sure, but then the whole conversation is basically moot.
I think it would be a very bad idea to make a change that fixes no bug
in the last release *ever* of 21.4. If Vin has a different opinion,
fine; I've said my opinion, and I'm sure he will give it appropriate
weight.
What I meant, and stand by, is that external emodules that implement
types are so rare they're practically nonexistent;
Only in 21.4.
particularly those that do properties.
In this context, what's part of xemacs core doesn't matter,
because
any changes to the ABI* will fix those too.
Not for third parties who have their own types with properties.
XEmacs has long been the preferred platform for private variations
because we worry about issues like that. This wart isn't worth
changing that.
For better or worse, this little wart is part of the public API (and I
do mean API) for primitive types, and has been for many years. That
means that changing it is a potentially big deal for third parties.
If we're going to do it, we should do it in a way that breaks the
build, not just the runtime. (It still potentially means breaking
only runtime for external modules if they're supplied as binaries, but
that can't be helped.)
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:29 p.m.
Ar an séú lá is fiche de mí na Samhain, scríobh Johann 'Myrkraverk' Oskarsson:
[...] Ok, then the question is, what is a better strategy, not to
implement it at all, which gives the error "Object type has no
properties" which can be slightly surprising and misleading if any of the
(get), (put) and (remprop) are implemented; vs. returning nil?
I'd like answers from people who have actually used property lists for
something; if any.
Implement it. Some (similar-ish) APIs are implemented entirely at Lisp level
and will never give these errors, and it can be surprising to move to a C
API and have it behave so differently. You can use process_putprop,
process_remprop, process_plist, process_setplist from process.c.
And on that note, why is that the internal putprop callback is
supposed to return 0 to throw a lisp error, but the remprop callback
is supposed to return -1? Wouldn't it have been better to synchronize
it? (This is from Fput and Fremprop in fns.c). I also just checked,
and afaict, this has not changed in 21.5. Given how few modules are
actually out there (mine may be the only one who does types) do you
want to change it?
It’s an ugly detail, yes. Send a separate patch to correct it.
> > Also, the (get cursor 'kind) returns another type,
which I've not yet
> > wrapped. This is an enumerator documented at
> >
> >
http://clang.llvm.org/doxygen/group__CINDEX.html#gaaccc432245b4cd9f2d4709...
> >
> > and I wonder what some options are to represent this in elisp?
>
> I would most likely use symbols. Whether to use keywords is a matter
> of taste. I probably wouldn't. [...] Creating a
> separate enum type seems like overengineering; if you want to
> introspect the set of enumerators, a defconst at Lisp level seems
> sufficient. If you really want to, you can create that list read-only
> at the C level in your module.
Overengineering or not, it does make it slightly easier to typecheck
for the functions that take these enumerators as arguments; see here:
http://clang.llvm.org/doxygen/group__CINDEX__CURSOR__MANIP.html#func-members
But that doesn't mean I can't use symbols. Maybe I'll do it the XP
way and try both a type wrapper and symbols to see which feels better.
Another consideration is that there’s a limited number of types available,
256 per XEmacs binary, while there is no significant limitation on the
number of symbols available.
--
‘Tramadol is further fed to cattle […] when working them […] (as draft
animals) so that the animals do not get tired quickly. …’
— Angewandte Chemie, Sept 2014, describing the social context of
(synthetic) tramadol having been found in Cameroon tree roots.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3432
days inactive
3436
days old
10 comments
3 participants
participants (3)
-
Aidan Kehoe -
Johann 'Myrkraverk' Oskarsson -
Stephen J. Turnbull