search for: api

On Jul 19, 2015, at 7:24 PM, Eric Christopher <echristo at gmail.com> wrote: > So, I made this proposal for what I think is a pretty good reason. There's an "unofficial" as Juergen said, policy that the C API is the stable API. There's nothing wrong with a stable C API, but that's what I'm proposing should move out of tree to where those that are most concerned with it can develop it and ensure that it remains stable for whatever guarantees they want. I don’t get it :-) > Some backgroun...

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 Guys, I have been trying to install win32-api 1.4.0 gem on windows 7 x64 but no success. When i...

Hi All, I wanted to send a follow-up mail to the C API discussion/BoF that we had at the latest developer meeting and nicely hosted by Justin and Juergen. We were able to reach consensus on a number of questions/concerns about the C API so I’m going to go ahead and list them for posterity and for any further discussion here: Stability Guarantees: Th...

It's sounds like we've reached two rough conclusions: 1) We need both a stable and a non-stable fully featured C API. It's a somewhat open question whether both or either should be part of the main tree. 2) Everyone seemed okay with the proposed deprecation policy for the stable API. Given this, I would propose we designate the existing C API as the "hopefully stable, but subject to future clean up...

On Thu, Jul 30, 2015 at 3:36 PM Philip Reames <listmail at philipreames.com> wrote: > It's sounds like we've reached two rough conclusions: > 1) We need both a stable and a non-stable fully featured C API. It's a > somewhat open question whether both or either should be part of the main > tree. > I'm fine with the stable API being in the main tree. I proposed moving it out originally so that it could get some work before moving it in. I'm reasonably confident that we can get s...

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 updated/improved, and what functionality needs to be exposed. We have most, but not all, transformations; many, but not all, IR features, etc. > > 2. W...

While I understand the people committing to the primarily C++ codebase of LLVM find it as additional burden, far more number of people enjoy the benefits of an official LLVM C API support than are vocal here. While Clang maybe the first-class LLVM citizen for the foreseeable future, I can tell you LLVM is used in many more situations (I'm talking about Rust, Go, Julia, DLang, etc.) than this alias realized. I alone am using it interesting projects I hope to release some...

"Documentation: We’re going 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." So, yes? -eric On Thu, Nov 19, 2015 at 5:55 PM Sean Silva <chisophugis at gmail.com> wrote: > Are you going to propagate this...

On Mon, Jul 20, 2015 at 4:12 PM Juergen Ributzka <juergen at apple.com> wrote: > I also misunderstood your original transition proposal in this point. I > agree with Jim that we should keep the current C-API where it is and have a > separate location for the bindings. I envision that we will need the > current C-API and the new stable C-API to overlap for at least one release > cycle to allow a smooth transition without breaking all the clients out > there. Some clients only read the releas...

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 excuse to do it is to flesh out some things: >>> >>> - Add more tests of the C API to ensure that pe...

...Christopher <echristo at gmail.com> wrote: > > > On Mon, Jul 20, 2015 at 4:12 PM Juergen Ributzka <juergen at apple.com> > wrote: > >> I also misunderstood your original transition proposal in this point. I >> agree with Jim that we should keep the current C-API where it is and have a >> separate location for the bindings. I envision that we will need the >> current C-API and the new stable C-API to overlap for at least one release >> cycle to allow a smooth transition without breaking all the clients out >> there. Some clients only...

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 filesyste...

...; > 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. > > 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 &g...

...om> wrote: > > > > On Mon, Jul 20, 2015 at 1:37 PM Juergen Ributzka <juergen at apple.com> > wrote: > >> Wow, this went of topic very quickly ;-) >> >> > It did. I am sorry about that :) > > >> As you know I am very interested in an stable API (C and/or C++) for >> LLVM, but maybe we should discuss this in a separate thread. Designing a >> good stable API from scratch will take some time and until that point I >> want to document our current “tribal knowledge”. I will post a patch as you >> suggested. >> &gt...

...; <clattner at apple.com>, "Hal Finkel" <hfinkel at anl.gov>, "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Lang > Hames" <lhames at apple.com> > Sent: Sunday, July 19, 2015 10:37:11 PM > Subject: Re: [LLVMdev] [RFC] Developer Policy for LLVM C API > > While I understand the people committing to the primarily C++ > codebase > of LLVM find it as additional burden, far more number of people enjoy > the benefits of an official LLVM C API support than are vocal here. > > While Clang maybe the first-class LLVM citizen for th...

I also misunderstood your original transition proposal in this point. I agree with Jim that we should keep the current C-API where it is and have a separate location for the bindings. I envision that we will need the current C-API and the new stable C-API to overlap for at least one release cycle to allow a smooth transition without breaking all the clients out there. Some clients only read the release notes, so this pro...

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: /var/tmp/tmp6eZDyW/libguestfs/tests/c-api/.libs...

> (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...

This is an update on some current work on the C API for use in R extensions. The internal R implementation makes use of tens of thousands of C entry points. On Linux and Windows, which support visibility restrictions, most of these are visible only within the R executble or shared library. About 1500 are not hidden and are visible to dynamically lo...

...2015, at 11:27 AM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote: >> >> 2. We don't have a good set of tests for it, nor do we have a good set of tutorials/documentation for it. Our tutorials, specifically, are in C++, not in C. We could break the C API 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...