search for: apy

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

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

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: The C API is, in general, a “best effort” for

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

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

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

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

"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

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

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

On Wed, Jul 29, 2015 at 3:28 PM, Eric 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

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

----- Original Message ----- > From: "Hayden Livingston" <halivingston at gmail.com> > To: "Eric Christopher" <echristo at gmail.com> > Cc: "Chris Lattner" <clattner at apple.com>, "Hal Finkel" <hfinkel at anl.gov>, "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Lang > Hames" <lhames at apple.com>

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

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

> On Jul 20, 2015, at 12:36 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Mon, Jul 20, 2015 at 9:40 AM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote: > >> On Jul 18, 2015, at 11:27 AM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote: >> >> 2. We don't have

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