> 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
>>> wrote:
>>>
>>> On Tue, Dec 15, 2015, at 03:03 PM, Joe Groff via swift-dev wrote:
Yeah, it seems to me
> On Dec 15, 2015, at 6:27 PM, Kevin Ballard wrote:
> 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 hea
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 reasonable refinement for 'withUnsafePointer'
> >>
> 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 reasonable refinement for 'withUnsafePointer' to
>> take an immutable parameter. Since this is a stdlib API change, you s
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 Dec 15, 2015, at 6:01 PM, Greg Parker via swift-dev
> wrote:
>> On Dec 15, 2015, at 5:32 PM, Kevin Ballard wrote:
>>
>>> 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
> On Dec 15, 2015, at 5:32 PM, Kevin Ballard wrote:
>
>> 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
Works for me. I'll look into the LLDB bug.
I've created some buildbot Docker containers:
https://github.com/eosrei/docker-swift-dev-buildbot
if someone wants to build a snapshot on Fedora (or Ubuntu for that matter):
cd /path/to/swift
docker run --name swift-f23 -v $PWD:/src -v $PWD:/output
eosre
Yeah, option 1 seems reasonable to me. I might give it attribute-like spelling,
though, to help bracket it and keep it separate from the real name and
declaration:
sil [debug_decl_context test.foo : (T) -> ()] @_Tfoo : $... {
}
-Joe
> On Dec 15, 2015, at 4:30 PM, Adrian Prantl wrote:
>
>>
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 Dec 15, 2015, at 3:42 PM, Jens Persson via swift-dev
> wrote:
>
> Ok thanks, and what about the initial topic of this thread, ie stuff like
> this:
>
> func f() {
> 1; "two"; 3.0
> [4, 5]; 6 * 7
> print("No warnings or errors!")
> }
> f() // No warnings or errors!
>
> Should
> On Dec 15, 2015, at 2:37 PM, Joe Groff wrote:
>
>>
>> On Dec 15, 2015, at 2:34 PM, Adrian Prantl wrote:
>>
>>>
>>> On Dec 15, 2015, at 2:27 PM, Joe Groff wrote:
>>>
On Dec 15, 2015, at 1:25 PM, Adrian Prantl wrote:
>
> On Dec 10, 2015, at 10:19 AM, John McCall
>> On Dec 14, 2015, at 9:42 PM, Chris Lattner via swift-dev
>> mailto:swift-dev@swift.org>> wrote:
>> There are two defensible models here:
>>
>> 1) comments should be treated as whitespace.
>> 2) comments should be treated as if they were not present.
>>
>> The later model seems more ideal to
Ok thanks, and what about the initial topic of this thread, ie stuff like
this:
func f() {
1; "two"; 3.0
[4, 5]; 6 * 7
print("No warnings or errors!")
}
f() // No warnings or errors!
Should I file a bug for that too or is this by design / has this been
discussed somewhere already?
> On Dec 15, 2015, at 8:12 AM, Ryan Lovelett via swift-dev
> wrote:
>
> I've been playing around with a Swift wrapper for the FFmpeg C libraries
> (e.g., libavutil, libavcodec, libavformat, etc...). While providing some
> extensions to some of the core C structures I've run into something that
> On Dec 15, 2015, at 3:01 PM, Adrian Prantl wrote:
>> On Dec 15, 2015, at 2:35 PM, John McCall wrote:
>>
>>> On Dec 15, 2015, at 1:25 PM, Adrian Prantl wrote:
On Dec 10, 2015, at 10:19 AM, John McCall wrote:
> On Dec 10, 2015, at 8:31 AM, Joe Groff via swift-dev
> wrote:
> On Dec 15, 2015, at 2:35 PM, John McCall wrote:
>
>> On Dec 15, 2015, at 1:25 PM, Adrian Prantl wrote:
>>> On Dec 10, 2015, at 10:19 AM, John McCall wrote:
>>>
On Dec 10, 2015, at 8:31 AM, Joe Groff via swift-dev
wrote:
> On Dec 9, 2015, at 4:15 PM, Adrian Prantl via swift-d
> On Dec 14, 2015, at 11:04 AM, Jens Persson via swift-dev
> wrote:
>
> Yes, and I don't know if there is any particular reason why the == operator
> for Int doesn't have @warn_unused_result while the one for Doubles has:
>
> func f() { 1 == 2 } // OK
> func g() { 1.0 == 2.0 } // Warning: Res
> On Dec 15, 2015, at 2:34 PM, Adrian Prantl wrote:
>
>>
>> On Dec 15, 2015, at 2:27 PM, Joe Groff wrote:
>>
>>>
>>> On Dec 15, 2015, at 1:25 PM, Adrian Prantl wrote:
>>>
On Dec 10, 2015, at 10:19 AM, John McCall wrote:
> On Dec 10, 2015, at 8:31 AM, Joe Groff via swi
> On Dec 15, 2015, at 1:25 PM, Adrian Prantl wrote:
>> On Dec 10, 2015, at 10:19 AM, John McCall wrote:
>>
>>> On Dec 10, 2015, at 8:31 AM, Joe Groff via swift-dev
>>> wrote:
On Dec 9, 2015, at 4:15 PM, Adrian Prantl via swift-dev
wrote:
In order to write textual SIL ->
> On Dec 15, 2015, at 2:27 PM, Joe Groff wrote:
>
>>
>> On Dec 15, 2015, at 1:25 PM, Adrian Prantl wrote:
>>
>>>
>>> On Dec 10, 2015, at 10:19 AM, John McCall wrote:
>>>
On Dec 10, 2015, at 8:31 AM, Joe Groff via swift-dev
wrote:
> On Dec 9, 2015, at 4:15 PM, Adrian Prantl
> On Dec 15, 2015, at 1:25 PM, Adrian Prantl wrote:
>
>>
>> On Dec 10, 2015, at 10:19 AM, John McCall wrote:
>>
>>> On Dec 10, 2015, at 8:31 AM, Joe Groff via swift-dev
>>> wrote:
On Dec 9, 2015, at 4:15 PM, Adrian Prantl via swift-dev
wrote:
In order to write textual
I'm also trying to figure out more about the build process. I don't even
understand in what context the buld_osx_package function should be (should
it be just in it's own file or in some context where eg SRC_DIR and
BUILD_NUMBER are defined)?
What I want to do most of the times is just to try out
> On Dec 14, 2015, at 7:51 PM, Mike Ash wrote:
>
>> On Dec 14, 2015, at 3: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
> On Dec 10, 2015, at 10:19 AM, John McCall wrote:
>
>> On Dec 10, 2015, at 8:31 AM, Joe Groff via swift-dev
>> wrote:
>>> On Dec 9, 2015, at 4:15 PM, Adrian Prantl via swift-dev
>>> wrote:
>>>
>>> In order to write textual SIL -> SIL testcases that exercise the handling
>>> of debug infor
Hi,
I'm in the process of porting Foundation to FreeBSD (see
https://github.com/apple/swift-corelibs-foundation/pull/141).
After fixing a bunch of build/portability errors I'm now stuck trying
to fix an issue with modules.
In particular, I see a lot of errors like this:
:0: error: module file's mi
Highly unlikely because many many other frameworks needed for iOS
development eg UIKit etc are not available on Linux and have no plans to be
made available as of now.
Also it's very difficult to make an iOS app without an IDE (read: Xcode)
which also doesn't have any plans to be made available for
Wait... are you sure that's the appropriate configuration? Shouldn't
the xctoolchain destination be in /Library/Developer/Toolchains/ rather
than the xcode directory proper? Or is the actual end destination handled
entirely by `toolchain-installer'?
Only somewhat related: SRC_DIR isn't defined, s
I’m sorry for the experience Travis, but this is certainly one of our pain
points. There’s a lot at play and we haven’t finished setting up our public CI
either. Here’s what I do locally to build a toolchain on OS X:
function build_osx_package() {
I've been playing around with a Swift wrapper for the FFmpeg C libraries
(e.g., libavutil, libavcodec, libavformat, etc...). While providing some
extensions to some of the core C structures I've run into something that
doesn't feel quite right to me.
Before I provide a discussion here is a Gist [0
Highly unlikely because many many other frameworks needed for iOS
development eg UIKit etc are not available on Linux and have no plans to be
made available as of now.
Also it's very difficult to make an iOS app without an IDE (read: Xcode)
which also doesn't have any plans to be made available for
In the future we will develop apps ios with swift in linux?
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
On Tue, Dec 15, 2015 at 2:39 AM, Nick Wellnhofer via swift-dev
wrote:
> On 10/12/2015 00:05, William Dillon via swift-dev wrote:
>>
>> At this point, the compiler and standard library are all built, and I
>> think I have one final issue. In the testing suite, the binaries generated
>> by the swif
On 10/12/2015 00:05, William Dillon via swift-dev wrote:
At this point, the compiler and standard library are all built, and I think I
have one final issue. In the testing suite, the binaries generated by the
swift compiler don’t run. They’re emitting unexpected reloc type errors. It
appear
35 matches
Mail list logo
