Re: [swift-corelibs-dev] libdispatch epoll port

> On Dec 17, 2015, at 21:16, Daniel A. Steffen via swift-corelibs-dev > wrote: > >> >> On Dec 17, 2015, at 13:41, Pierre Habouzit via swift-corelibs-dev >> wrote: >> >> >> -Pierre >> >>> On Dec 17, 2015, at 1:35 PM, Pierre Habouzit wrote: >>> On Dec 17, 2015, at 12:40 PM, Tony Park

Re: [swift-corelibs-dev] libdispatch epoll port

> On Dec 17, 2015, at 13:41, Pierre Habouzit via swift-corelibs-dev > wrote: > > > -Pierre > >> On Dec 17, 2015, at 1:35 PM, Pierre Habouzit wrote: >> >>> On Dec 17, 2015, at 12:40 PM, Tony Parker via swift-corelibs-dev >>> wrote: >>> >>> Hi Dzianis, >>> On Dec 17, 2015, at 12:36 P

Re: [swift-corelibs-dev] NSThread properties

Thanks Tony, https://bugs.swift.org/browse/SR-303 has been filed. On Thu, Dec 17, 2015 at 8:53 PM, Tony Parker wrote: > Hi Joe, > > Looks like an oversight. We should add them. > > - Tony > > On Dec 17, 2015, at 6:45 PM, Joseph Bell via swift-corelibs-dev < > swift-corelibs-dev@swift.org> wrote:

Re: [swift-corelibs-dev] NSThread properties

Hi Joe, Looks like an oversight. We should add them. - Tony > On Dec 17, 2015, at 6:45 PM, Joseph Bell via swift-corelibs-dev > wrote: > > Reading the Status page I see that NSThread is "fully implemented", yet. when > looking at the code and verifying by compiling, none of the properties: >

[swift-corelibs-dev] NSThread properties

Reading the Status page I see that NSThread is "fully implemented", yet. when looking at the code and verifying by compiling, none of the properties: executing finished cancelled are implemented. Is this an oversight or was it decided to not implement these properties? Double-checking before I

Re: [swift-corelibs-dev] Git history

Completely agree re: not wishing to be pedantic and I know this represents such a tiny part of the overall scope of the project (ie it's much more important that we have a full library vs a perfect commit history). I'll try and put together a couple of scenarios based on the current history and ho

Re: [swift-corelibs-dev] Starter bug: Run Foundation tests against OS X Foundation

Awesome, thanks Ian! - Tony > On Dec 17, 2015, at 12:54 PM, Ian Ynda-Hummel wrote: > > Hey all, > > I'd like to claim this one. I'll assign to myself on Jira. > > On Thu, Dec 17, 2015 at 12:08 PM Tony Parker via swift-corelibs-dev > mailto:swift-corelibs-dev@swift.org>> wrote: > Hi everyone,

Re: [swift-corelibs-dev] libdispatch epoll port

libev model isn’t compatible with dispatch model, and retrofiting one on top of the other will put you in a world of hurt, and would diverge from the OS X port greatly, which we’d like to avoid. I originally thought you were replying to the thread about having the Runloop queues code in dispatc

Re: [swift-corelibs-dev] libdispatch epoll port

What about libev? http://software.schmorp.de/pkg/libev.html On Thu, Dec 17, 2015 at 12:36 PM, Dzianis Fedarenka via swift-corelibs-dev < swift-corelibs-dev@swift.org> wrote: > >> On Dec 10, 2015, at 12:42 AM, Joakim Hassila via swift-corelibs-dev > wrote: > >> > >> Hi, > >> > >>> On 8 dec. 2015,

Re: [swift-corelibs-dev] libdispatch epoll port

-Pierre > On Dec 17, 2015, at 1:35 PM, Pierre Habouzit wrote: > >> On Dec 17, 2015, at 12:40 PM, Tony Parker via swift-corelibs-dev >> wrote: >> >> Hi Dzianis, >> >>> On Dec 17, 2015, at 12:36 PM, Dzianis Fedarenka via swift-corelibs-dev >>> wrote: >>> > On Dec 10, 2015, at 12:42 AM,

Re: [swift-corelibs-dev] libdispatch epoll port

> On Dec 17, 2015, at 12:40 PM, Tony Parker via swift-corelibs-dev > wrote: > > Hi Dzianis, > >> On Dec 17, 2015, at 12:36 PM, Dzianis Fedarenka via swift-corelibs-dev >> wrote: >> On Dec 10, 2015, at 12:42 AM, Joakim Hassila via swift-corelibs-dev wrote: Hi, >

Re: [swift-corelibs-dev] Proposal: Make NSTask's standardInput/standardOutput/standardError properties type-safe

Hi Tony, thanks for the response! In regards to why an enum w/ associated values: - It avoids creating additional storage. (Admittedly, a very small amount, but the point still stands.) - It deterministically defines that it’s either one or the other, and guards against someone trying to be cl

Re: [swift-corelibs-dev] Starter bug: Run Foundation tests against OS X Foundation

Hey all, I'd like to claim this one. I'll assign to myself on Jira. On Thu, Dec 17, 2015 at 12:08 PM Tony Parker via swift-corelibs-dev < swift-corelibs-dev@swift.org> wrote: > Hi everyone, > > I filed a bug here that would be a great way for someone to jump into > contributing to swift-corelibs

Re: [swift-corelibs-dev] libdispatch epoll port

Hi Dzianis, > On Dec 17, 2015, at 12:36 PM, Dzianis Fedarenka via swift-corelibs-dev > wrote: > >>> On Dec 10, 2015, at 12:42 AM, Joakim Hassila via swift-corelibs-dev >>> wrote: >>> >>> Hi, >>> On 8 dec. 2015, at 16:56, Pierre Habouzit wrote: FWIW, this is my personal,

[swift-corelibs-dev] libdispatch epoll port

>> On Dec 10, 2015, at 12:42 AM, Joakim Hassila via swift-corelibs-dev >> wrote: >> >> Hi, >> >>> On 8 dec. 2015, at 16:56, Pierre Habouzit wrote: >>> >>> FWIW, this is my personal, let’s call it enlightened, opinion, based on my >>> knowledge of dispatch and my past extensive system p

Re: [swift-corelibs-dev] Proposal: Make NSTask's standardInput/standardOutput/standardError properties type-safe

Hi Dan, Thank you for your proposal. This is the right place to start discussion of it. If we want to do this then we would have to make changes in both Darwin and open source versions, to maintain source compatibility. Out of curiosity, why propose an enum instead of an additional set of typed

[swift-corelibs-dev] Proposal: Make NSTask's standardInput/standardOutput/standardError properties type-safe

This is my first proposal to swift-corelibs, so I’m not sure how much flexibility we have in terms of deviating from the darwin’s original Foundation definitions. That said, it’s always seemed a little screwy to me that NSTask's standardInput/standardOutput/standardError properties sacrifice an

Re: [swift-corelibs-dev] Upcoming holiday schedule

Indeed! I hope the mismatch doesn’t cause us to fall too far behind. ;) - Tony > On Dec 17, 2015, at 9:10 AM, Brian Gesiak wrote: > > Thanks for the head's up! Conversely, I imagine that for many people, > holidays from work are precisely the time to contribute! :) > > - Brian Gesiak > > >

Re: [swift-corelibs-dev] Upcoming holiday schedule

I will probably be around a bit more than Tony over the break; I will try to keep up with the pull requests. There are a few things that I think will speed up the process so that we can keep things running well: Discrete commits that implement a specific thing; reviewing two different spots so

Re: [swift-corelibs-dev] Upcoming holiday schedule

Thanks for the head's up! Conversely, I imagine that for many people, holidays from work are precisely the time to contribute! :) - Brian Gesiak On Thu, Dec 17, 2015 at 9:03 AM -0800, "Tony Parker via swift-corelibs-dev" wrote: Hello fellow contributors, As you are aware, we are

[swift-corelibs-dev] Upcoming holiday schedule

Hello fellow contributors, As you are aware, we are fast approaching the year-end holiday season. Here at Apple, many of us are taking some time off starting next week through the new year. As a result, it is likely that some pull requests will take more time than expected to review and merge.

[swift-corelibs-dev] Starter bug: Run Foundation tests against OS X Foundation

Hi everyone, I filed a bug here that would be a great way for someone to jump into contributing to swift-corelibs-foundation: SR-276 The basic idea is that we could really use a way to run our Swift test suite against the system (OS X) Foundation. This wi

Re: [swift-corelibs-dev] Git history

Hi Tom, I’ve actually been thinking about this a lot over the past few days, but haven’t come to any real conclusion yet. The way I’ve traditionally worked on Foundation is that each commit has more content, and each commit is (almost) always associated with a bug. This is basically the proces

Re: [swift-corelibs-dev] Git history

git rebase -i is great and very well documented, with tons of blogs post about it all over the web. if you pick `s` as a memonic it will squash and let you edit the merged commit message. If the base commit message is already good, use `f` and it will “fixup” it which is a squash where the orig

Re: [swift-corelibs-dev] Git history

Help on rebasing would be great. I use git all the time but I still struggle to squash my commits as I usually don't do it. On Thu, Dec 17, 2015 at 9:25 AM, Tom Jowett via swift-corelibs-dev < swift-corelibs-dev@swift.org> wrote: > Hi everyone, > > I'm wondering if there's a way I can help to kee

[swift-corelibs-dev] Git history

Hi everyone, I'm wondering if there's a way I can help to keep the commit structure of the repo a bit tidier? I can see the guideline being provided on CONTRIBUTING.md however the current commit history could be a little easier to follow for the average viewer (eb06d19 and b4f6e2b were duplicate