When attempting to build Swift Preview 5 on Linux, I get this error:
Testing Time: 6.02s
Failing Tests (4):
swift-package-tests :: swift-build-self-host.py
swift-package-tests :: swift-package-init-lib.md
swift-package-tests :: test-foundation-
Hi,
I attempted to compile this on OSX El Capitan using the same process I've been
using for snapshots, and got very many failures. Can't find anything related
in bugreporter, mailing list, or google.
Is there a CI run for this tag I could stare at to compare what is wrong with
my build scrip
> On May 6, 2016, at 3:04 PM, Daniel Dunbar wrote:
>
> The conclusion was that after weighing all of the tradeoffs, it made the most
> sense to encourage porting of SourceKit to Linux and then using it to build
> out
> the Linux test discovery feature. This was most in line with a desirable
> l
> On Apr 3, 2016, at 10:05 PM, Dmitri Gribenko wrote:
>
>> Hmm... but then wouldn't that more tightly couple the test discovery tool
>> and the Swift compiler? In an earlier email you said you "like #3 better
>> [...] because that would decouple the test discovery tool from the Swift
>> compiler
Hello all,
I'm growing concerned about a small workflow hangup.
I've noticed a pattern in the PR queue where: a patch is generally
uncontroversial, reviews are of very high quality, and authors are quick to
respond to reviewer concerns. However so much time elapses waiting for review
or re-re
> On Apr 6, 2016, at 11:51 PM, Dmitri Gribenko wrote:
>
> This operation converts a C string to a Swift string, so (2) is a non-starter.
Then it is inappropriately named. The name of the constructor is
`validatingUTF8`, not `cString`.___
swift-dev
let completeFile = [112, 114, 105, 110, 116, 40, 34, 104, 101, 108, 108, 111,
32, 119, 111, 114, 108, 100, 34, 41]
let str = String(validatingUTF8: completeFile)
Did you see it? No?
What if our bytes are not UTF8? Well, one would hope that the constructor, um,
validates them.
Turns out it do
We noticed today when running a swift CLI program to a pipe that stdout is
fully buffered (e.g. not unbuffered, not line-buffered). So just now we
committed unbuffering IO to a bunch of CLI programs.
Is this the right default behavior for Swift?
I realize this is a Cism with a long history, bu
>>
>>> On Feb 5, 2016, at 4:10 PM, Mishal Shah >> <mailto:mishal_s...@apple.com>> wrote:
>>>
>>> Hi Drew,
>>>
>>> Thanks for pointing this out to me, I have tagged swift-integration-test.
>>> https://github.com/apple/swift-i
I'm getting a funny print when trying to create a statically linked executable
on Linux x64.
The driver does not actually support this
(https://bugs.swift.org/browse/SR-730) and so I'm compiling by hand so I can
learn to write the correct driver patch.
$ cat test.swift
print("hello world")
$ s
gt;>>> I noticed however that it is also missing from cmark:
>>>>
>>>> https://github.com/apple/swift-cmark/releases
>>>> <https://github.com/apple/swift-cmark/releases>
>>>>
>>>> Could you tag that one as well?
>>>&
Still fresh on swift-DEVELOPMENT-SNAPSHOT-2016-03-16-a; disabling foundation
tests and snoozing until the next snapshot
> On Mar 1, 2016, at 4:02 AM, Drew Crawford wrote:
>
> From Feb 9th:
>
>> Hello,
>>
>> When building the Feb 8th snapshot from source on Linux x64, I see a new
>> error:
>
12 matches
Mail list logo
