as already aware of the problem and
> fixed it in some places but not all. This also suggests that the problem
> itself can be fixed merely by replacing the remaining uses of
> __dispatch_async with _swift_dispatch_async(). I will try this out.
>
> -Kevin
>
> On Mon, Aug
(). I will try this out.
-Kevin
On Mon, Aug 1, 2016, at 02:53 PM, Kevin Ballard via swift-dev wrote:
> I just filed SR-2246 about how `queue.async(flags: .barrier)` is completely
> broken, and I think the problem comes down to `dispatch_block_t` is being
> imported as `() -> ()` i
I just filed SR-2246 about how `queue.async(flags: .barrier)` is completely
broken, and I think the problem comes down to `dispatch_block_t` is being
imported as `() -> ()` instead of as `@convention(block) () -> ()`, and
therefore `__dispatch_async` has the type `(DispatchQueue, () -> Void) ->
On Sun, Jan 3, 2016, at 09:30 AM, Jesse Rusak wrote:
> Some things from Kevin:
>
>> But the warning that Jesse was talking about, the one that was
>> discussed in the older threads, I think is completely different. If I
>> declare a method on my type that matches a protocol extension method,
>> it
(CCing the list again as I believe you omitted it accidentally)
On Sat, Jan 2, 2016, at 10:10 PM, Douglas Gregor wrote:
> On Jan 2, 2016, at 6:58 PM, Kevin Ballard via swift-dev d...@swift.org> wrote:
>> On Sat, Jan 2, 2016, at 11:39 AM, Douglas Gregor via swift-dev wrote:
>>&g
Incidentally, for a long time I've maintained my own vim Swift plugin at
https://github.com/kballard/vim-swift. It provides a bunch of features like
compiling and running the current file when you press ⌘R. It's not entirely
up-to-date yet (e.g. I haven't updated it to allow string literals insi
On Sat, Jan 2, 2016, at 11:39 AM, Douglas Gregor via swift-dev wrote:
>
>
>> On Dec 31, 2015, at 3:15 PM, Jesse Rusak wrote:
>>
>> Hi Doug,
>>
>> I’ve been playing around with an implementation of the warning you
>> referenced here:
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-
Running tests on current master fails on 3 tests every time. I already checked
to make sure I'm fully up-to-date. They reproduce with just `build-script -t`.
FAIL: Swift-Unit :: Basic/SwiftBasicTests/Compression.FlatEncoding (2266 of
2451)
TEST 'Swift-Unit ::
Basic/SwiftBas
On Dec 31, 2015, at 1:07 AM, Dave Abrahams wrote:
>> Alternatively, we could work around it by allowing you to say `extension Any
>> : EquatableSequenceType where Self : SequenceType { ... }` and having that
>> essentially extend every concrete type that conforms to SequenceType, which
>> mean
FWIW, once we have conditional protocol conformance (`extension ... : Proto
where ...`), and if we get rid of the circular protocol inheritance limitation
(two protocols that inherit from each other, which should in theory be fine),
then we can say something like
protocol EquatableSequenceType
I'm pretty sure the current implementation uses Unicode canonical
equivalence to perform the comparison. This is equivalent to invoking
`decomposedStringWithCanonicalMapping` on both strings and then
comparing the resulting utf8 (or utf16) sequences, although it doesn't
actually build new strings.
On Wed, Dec 16, 2015, at 11:49 AM, Joe Groff wrote:
>
>> On Dec 16, 2015, at 11:47 AM, Kevin Ballard wrote:
>>
>> On Wed, Dec 16, 2015, at 11:42 AM, Joe Groff wrote:
>>>
>>>> On Dec 16, 2015, at 11:24 AM, Kevin Ballard via swift-dev >>> d...@swif
On Wed, Dec 16, 2015, at 11:42 AM, Joe Groff wrote:
>
> > On Dec 16, 2015, at 11:24 AM, Kevin Ballard via swift-dev
> > wrote:
> >
> > On Wed, Dec 16, 2015, at 12:12 AM, Dave Abrahams wrote:
> >>
> >>> Come to think of it, what's the actual
On Wed, Dec 16, 2015, at 12:12 AM, Dave Abrahams wrote:
>
> > Come to think of it, what's the actual use-case for withUnsafePointer()?
>
> I'm not sure we still have one that isn't covered by &x; that's my point.
>
> > If a value is mutable, you can already use &x or
> > withUnsafeMutablePointe
On Tue, Dec 15, 2015, at 11:25 PM, Dave Abrahams wrote:
>
> > On Dec 15, 2015, at 6:46 PM, Kevin Ballard wrote:
> >
> > On Tue, Dec 15, 2015, at 06:39 PM, Dave Abrahams wrote:
> >>
> >>> On Dec 15, 2015, at 6:33 PM, Kevin Ballard via swift-dev
>
On Tue, Dec 15, 2015, at 06:39 PM, Dave Abrahams wrote:
>
> > On Dec 15, 2015, at 6:33 PM, Kevin Ballard via swift-dev
> > wrote:
> >
> > On Tue, Dec 15, 2015, at 03:03 PM, Joe Groff via swift-dev wrote:
> >>
> >> Yeah, it seems to me like a
On Tue, Dec 15, 2015, at 03:03 PM, Joe Groff via swift-dev wrote:
>
> Yeah, it seems to me like a reasonable refinement for 'withUnsafePointer' to
> take an immutable parameter. Since this is a stdlib API change, you should
> suggest that on swift-evolution.
A change like that is going to break
On Tue, Dec 15, 2015, at 06:12 PM, John McCall wrote:
> So, just to complete the loop here: absent Darwin granting public and
> backwards-compatible access to an internal API, we need to write this in a
> way that falls back on using a heavyweight lock in the presence of
> contention. I’m fine
On Tue, Dec 15, 2015, at 01:38 PM, Greg Parker via swift-dev wrote:
>
> Another solution is to use a handoff lock algorithm. This is what libobjc
> does now. The lock owner stores its thread ID in the lock. Each lock waiter
> yields to the owner thread specifically, donating its priority and res
On Mon, Dec 14, 2015, at 09:34 PM, Douglas Gregor wrote:
>
>> On Dec 14, 2015, at 6:52 PM, Kevin Ballard wrote:
>>
>> (I haven't touched case prefix stripping; presumably it's trying to
>> strip the Swift name instead of the ObjC name)
>
> Probably. It’s not actually clear which prefix it should t
On Mon, Dec 14, 2015, at 07:48 PM, Greg Parker wrote:
>
> > On Dec 14, 2015, at 7:39 PM, Kevin Ballard wrote:
> >
> >> On Mon, Dec 14, 2015, at 07:34 PM, Greg Parker wrote:
> >>
> >>> On Dec 14, 2015, at 7:26 PM, Kevin Ballard via swift-dev
> &g
On Mon, Dec 14, 2015, at 07:34 PM, Greg Parker wrote:
>
> > On Dec 14, 2015, at 7:26 PM, Kevin Ballard via swift-dev
> > wrote:
> >
> >> On Mon, Dec 14, 2015, at 12:19 PM, Greg Parker via swift-dev wrote:
> >>
> >>> On Dec 14, 2015,
On Mon, Dec 14, 2015, at 12:19 PM, Greg Parker via swift-dev wrote:
>
> > On Dec 14, 2015, at 9:47 AM, John McCall via swift-dev
> > wrote:
> >
> >> On Dec 12, 2015, at 7:04 PM, Chris Lattner wrote:
> >> #3 sounds like a great approach to me. I agree with Kevin that if we keep
> >> the objec
(moved to swift-dev)
I went ahead and implemented this over the weekend, but ran into some
weird behavior when testing it. I defined a new macro
# if defined(__has_feature) && __has_feature(generalized_swift_name)
# define SWIFT_ENUM_NAMED(_type, _name, SWIFT_NAME) enum _name : _type
# _name; enu
On Sat, Dec 12, 2015, at 12:01 AM, Kevin Ballard wrote:
> Another possible fix is to just atomically load/store the Value pointer
> itself (assuming all platforms Swift runs on supports lock-free atomic
> pointers). This way if the object is deallocating, it would attempt an atomic
> CAS on the
On Fri, Dec 11, 2015, at 07:00 AM, Mike Ash via swift-dev wrote:
>
> Increasing the inline size of weak references opens up the possibilities a
> bit. I can think of at least four fixes:
>
> 1. Delete the zeroing, and otherwise leave things as-is. This extends the
> life of the object husk (by
t; platform + other options would make a lot of sense to me.
>
> I'd recommend filing specific enhancement requests as bugs, since these
> should be easy things for people to cherry pick off. Ditto for the bug about
> the install path.
>
> - Daniel
>
> > On Dec 9
build-script --preset="buildbot_osx_package"
> install_destdir="${SWIFT_INSTALL_DIR}"
> installable_package="${SWIFT_INSTALLABLE_PACKAGE}"
> install_toolchain_dir="${SWIFT_TOOLCHAIN_DIR}"
> install_symroot="${SWIFT_INSTALL_SYMROOT}"
Is there an easy way to build and install my own toolchain into
/Library/Developer/Toolchains? I assume there must be some automated way to
construct the package installer, but nothing immediately leaps out at me. It
looks like build-script can create a root, but that seems to be for BNI, which
When I get a crash in Swift, is there any easy way to figure out if it's
already a known crasher? I know there's a bunch of test cases in
validation-test/compiler_crashers{,_2}/ which I assume are all existing
crashers. Short of reading through them for similar-looking code, is there some
solut
Can you please stop creating a new thread for every single message? This
is making it hard to read the list. Just reply to the last message in
the thread instead.
-Kevin
On Mon, Dec 7, 2015, at 01:27 PM, Piero Sabino via swift-dev wrote:
> My .bashrc is the following: [snip]
_
31 matches
Mail list logo
