On 23 June 2011 15:57, Peter Stirling <peter@...> wrote:
> Is it possible to request an appropriate definition of size_t for
> export in sb-alien? sb-alien:unsigned without an explicit number
> of bits should give you the right type, but it seems like
> something that would need to be defined for enough clients
> to justify simply defining it for everyone.
I think this is perfectly sensible, and will see to it.
The chaining-macro question needs more head-time than I have right
now, so I'm not saying anything about it right now.
> Is there a way to declare that you expect the requirement of
> boxing for a %sap-alien value? I'd like to get rid of the
> 'unable to optimise' notes without using
> (declare (sb-ext:muffle-conditions sb-ext:compiler-note))
> everywhere and risking hiding real notes.
In most cases there is a way. Not in all, unfortunately. There isn't
really a good general-purpose recipe either. I have a work-in-progress
branch that ameliorates the issue by making those cases a lot-less
expensive, though, which would allow downgrading the compiler note so
that it would only be given for high SPEED policies, but I'm not
exactly sure when I'll be done with it.
> I'm attaching a (hopefully uncontroversial) patch that:
Thank you. If at all possible, please follow these directions, from
file HACKING in the source tree:
Preferred patch format is output from "git format-patch", including
the commit message.
The commit message should explain the why and how of the change. See
existing commit messages for examples -- for a truly trivial changes
little is needed, but in most cases more is better.
Please include test-cases in your patch if at all possible: if you're
not sure which file in tests/ to put your test case in, just pick one
that seems vaguely appropriate.
Please format your submission for ease of reading: unless the change
is whitespace only, avoid re-indenting code you are not touching, etc.
Unless your change is large and best understood as a series of
sequential changes, please send it in as single patch.
If your patch includes algorithmic changes, explain them. If your
patch uses a published algorithm, please include a link to the paper.
We aren't always as well-educated as we'd like to...
Ready-to-apply patches should be submitted via Launchpad: please add
the tag "review" to the associated bug (create new bug with name if
there isn't one about the issue yet.)
Patches requiring more widespread discussion and feedback should be
sent to the sbcl-devel mailing list.
If you have any questions, feel free to ask them on sbcl-devel,
or the IRC channel #sbcl@....
> Finally, I'm wondering why define-alien-routine
> explicitly errors if you pass a pointer type
> as an :out parameter? I wrote a wrapper macro that
> re-writes the parameter list in terms of
> system-area-pointer, and calls sap-alien on the
> relevant result, and my tests work as I expect,
> on x86-64 and x86.
Without an example it's hard to say. Could be a bug, could be a
missing feature. Could be something else.