search for: apis

...e can possibly look at bringing it back into tree at some point in the future. For example, if someone comes up with a good "libjit" api then we can look at how the API design works and make sure it's general enough that it's not going to cause undue solidification of the existing APIs. > > Caveat: I'm not talking about the existing libclang or liblto libraries. Those seem to work and have a small enough API surface that they seem reasonable to support and we can move to a new API if they seem to be hindering development in the future. > > This help explain wher...

Support Requests item #24279, was opened at 2009-03-03 06:51 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=412&aid=24279&group_id=85 Category: win32-api Group: v1.0 (example) Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Windows 7 x64 - building a win32-api gem on windows Initial Comment: Hi

...ing to document this policy in the developer documentation. In addition, any changes to the C API will require documentation in the release notes so that it’s clear to external users who do not follow the project how the C API is changing and evolving. What we expect this means in practice is that APIs like libLTO and other APIs based on reading IR are going to remain highly stable and that more wrapper like APIs (IR creation, etc) are going to both be added and change as the underlying IR changes. Please feel free to follow up to this thread with any concerns. Thanks! -eric (with Justin and J...

...for the existing C API. We can then start discussing how we should create the fully featured API. I'd lean towards a tool like Swig, but we could also do it purely on demand. For example, I could add some shims for the experimental GC support without committing to supporting the current APIs long term. Philip On 07/30/2015 01:47 PM, Reid Kleckner wrote: > On Thu, Jul 30, 2015 at 1:04 PM, Eric Christopher <echristo at gmail.com > <mailto:echristo at gmail.com>> wrote: > > I think the idea of having a (hopefully not too) fluid C API that > can encomp...

...e flip the switch that says "this is now not stable, please use X". In the mean time we can either a) move a bindings level C API into a separate directory starting with the existing wrapped C++ API that we have as part of the C API, or b) expand in the current directory and copy a set of APIs off to another directory. How to do this with minimal churn in external projects is important - this is why I'm inclined to say that the bindings API reside in the current C API directory, but others are more hesitant, I'm just not sure in their mind how the final transition from "best...

On Jul 18, 2015, at 11:27 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> I am strongly in favor of moving the bindings, C or otherwise, to >> another project. > > I agree. From my viewpoint we have two primary problems with the C API: > > 1. Many of the LLVM contributors don't use it, and thus, don't have a great understanding of how it can be most-usefully

...at bringing it back > into tree at some point in the future. For example, if someone comes up with > a good "libjit" api then we can look at how the API design works and make > sure it's general enough that it's not going to cause undue solidification > of the existing APIs. > > Caveat: I'm not talking about the existing libclang or liblto libraries. > Those seem to work and have a small enough API surface that they seem > reasonable to support and we can move to a new API if they seem to be > hindering development in the future. > > This help...

...documentation. In >> addition, any changes to the C API will require documentation in the >> release notes so that it’s clear to external users who do not follow the >> project how the C API is changing and evolving. >> >> What we expect this means in practice is that APIs like libLTO and other >> APIs based on reading IR are going to remain highly stable and that more >> wrapper like APIs (IR creation, etc) are going to both be added and change >> as the underlying IR changes. >> >> Please feel free to follow up to this thread with any...

...a release note warning that the C API directory is going to be unstable in X release and expand the current directory. This means that current users of it in a bindings sort of way (honestly most users) won't have to migrate and that users that care deeply about stability can migrate to the new APIs as they make it in tree. Does this make sense? Are there any problems with this? > I added an initial patch for discussion. There is one point I am not sure > about yet. You mentioned that existing API implementations might become > NOOPS. I agree that this is a viable and sometimes nec...

On Tue, Aug 5, 2014 at 2:49 PM, Filip Pizlo <fpizlo at apple.com> wrote: > >> On Aug 5, 2014, at 1:46 PM, Eric Christopher <echristo at gmail.com> wrote: >> >>> (7) Make the C API truly great. >>> >>> I think it’s harmful to LLVM in the long run if external embedders use the C++ API. I think that one way of ensuring that they don’t have an

...warning that the C API directory is going to be unstable in X > release and expand the current directory. This means that current users of > it in a bindings sort of way (honestly most users) won't have to migrate > and that users that care deeply about stability can migrate to the new APIs > as they make it in tree. > > Does this make sense? Are there any problems with this? > Jim's idea of keeping the current one as the stable one (since those users are least amenable to changing their library, etc) seems like a good idea to me, naively speaking. But my guess is tha...

Hi Al, Here's a set of patches that converts a bunch (but not yet all!) to the new mount API. To this end, it makes the following changes: (1) Provides a convenience member in struct fs_context that is OR'd into sb->s_iflags by sget_fc(). (2) Provides a convenience helper function, vfs_init_pseudo_fs_context(), for doing most of the work in mounting a pseudo filesystem.

On Tue, Aug 5, 2014 at 2:57 PM, Filip Pizlo <fpizlo at apple.com> wrote: > > On Aug 5, 2014, at 2:51 PM, Eric Christopher <echristo at gmail.com> wrote: > > On Tue, Aug 5, 2014 at 2:49 PM, Filip Pizlo <fpizlo at apple.com> wrote: > > > On Aug 5, 2014, at 1:46 PM, Eric Christopher <echristo at gmail.com> wrote: > > (7) Make the C API truly great.

On Mon, Jul 20, 2015 at 3:20 PM Jim Grosbach <grosbach at apple.com> wrote: > On Jul 20, 2015, at 2:24 PM, Jim Grosbach <grosbach at apple.com> wrote: > > > On Jul 20, 2015, at 1:45 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Mon, Jul 20, 2015 at 1:37 PM Juergen Ributzka <juergen at apple.com> > wrote: > >> Wow, this

...int in the future. For example, if someone > > comes up with > > a good "libjit" api then we can look at how the API design works > > and make > > sure it's general enough that it's not going to cause undue > > solidification > > of the existing APIs. > > > > Caveat: I'm not talking about the existing libclang or liblto > > libraries. > > Those seem to work and have a small enough API surface that they > > seem > > reasonable to support and we can move to a new API if they seem to > > be > > h...

...es, so this process will take some time. I added an initial patch for discussion. There is one point I am not sure about yet. You mentioned that existing API implementations might become NOOPS. I agree that this is a viable and sometimes necessary path, but what are the limitations for this? Which APIs can be safely converted to NOOPs? —Juergen > On Jul 20, 2015, at 3:26 PM, Eric Christopher <echristo at gmail.com> wrote: > > On Mon, Jul 20, 2015 at 3:20 PM Jim Grosbach <grosbach at apple.com <mailto:grosbach at apple.com>> wrote: >> On Jul 20, 2015, at 2:24...

Hey, >make check-TESTS >make[3]: Entering directory '/var/tmp/tmp6eZDyW/libguestfs/tests/c-api' >make[4]: Entering directory '/var/tmp/tmp6eZDyW/libguestfs/tests/c-api' >PASS: /var/tmp/tmp6eZDyW/libguestfs/tests/c-api/.libs/lt-test-create-handle >PASS: /var/tmp/tmp6eZDyW/libguestfs/tests/c-api/.libs/lt-test-config >PASS:

> (7) Make the C API truly great. > > I think it’s harmful to LLVM in the long run if external embedders use the C++ API. I think that one way of ensuring that they don’t have an excuse to do it is to flesh out some things: > > - Add more tests of the C API to ensure that people don’t break it accidentally and to give more gravitas to the C API backwards compatibility claims. >

...and we'd likely remain unaware for quite awhile. > I think this is the most important point, that we lack testing for it. > > IMO, the language doesn’t matter too much. I’m happy with C or C++, but whichever (or both) or those are exposed in a stable way, we need the *users* of those APIs to help test it. > > How about we add a StableAPI directory in unittests? Then have a test written in C/C++ for each of the users of it. So a WebKit.c test, Go.c, SomeProject.cpp, etc. > > Then adding anything to the stable API must have a corresponding test, and changing the API sh...

Thanks for your convincing comment, but it seems the R core team has a different opinion... A few hours ago, src/include/R_ext/Altrep.h got this comment: /* Not part of the API, subject to change at any time. */ commit: https://github.com/r-devel/r-svn/commit/2059bffde642f8426d1f39ab5dd995d19a575d4d While I'm glad to see their attempt to make it clear, I'm confused. That