> On Apr 21, 2016, at 9:20 PM, Daniel Dunbar via swift-dev
> wrote:
>
> What is the status of the Ubuntu packages CI failure:
> swift-package-tests :: repl/test-repl-glibc.py
>
> It has been failing for a while now and I would like to get back to being
> able to use
> On Apr 21, 2016, at 9:57 PM, no-re...@swift.org wrote:
>
> [FAILURE] oss-lldb-incremental-osx [#2620]
>
> Build URL:https://ci.swift.org/job/oss-lldb-incremental-osx/2620/
> Project: oss-lldb-incremental-osx
> Date of build:Thu, 21 Apr 2016 21:48:20 -0700
> Build duration:
Hi all,
I would like to propose that we include `FileCheck` in the downloadable
toolchains.
The downloadable toolchains are quite useful for people who are wanting to work
on Swift projects that use FileCheck (llbuild, swift-integration-tests), but
don't want to build everything from scratch.
What is the status of the Ubuntu packages CI failure:
swift-package-tests :: repl/test-repl-glibc.py
It has been failing for a while now and I would like to get back to being able
to use @swift-ci please test and merge.
- Daniel
___
swift-dev
Hi Joel,
I list some URLs.
Bug/Feature report in http://bugs.swift.org
---
SR-34 Port Swift to Windows (https://bugs.swift.org/browse/SR-34)
SR-612 In Cygwin port, print() crashed at hook (
https://bugs.swift.org/browse/SR-612)
SR-1128 autolink extraction
Hi Han,
Thanks for the details! Do you have a custom fork or branch with these
changes? I'd love to be able to test this out and contribute if you think
that could help you out. I can get started on testing what you have now as
soon as tomorrow.
Cheers,
--Joel
On Thu, Apr 21, 2016 at 4:15 PM,
I'm confused as to why this wouldn't have failed the first time I ran the
tests. Sorry, will fix promptly.
Jordan
> On Apr 21, 2016, at 11:10, no-re...@swift.org wrote:
>
> [FAILURE] oss-swift-incremental-RA-osx [#3545]
>
> Build URL:
Hi all,
I wanted to propose how we can go about handling newer Ubuntu releases in a
systematic way. This covers how we handle Ubuntu on our CI, but also
reflects where we'll be focusing effort at any given point. The primary
intent is to support the most recent Ubuntu Long Term Service release
Hi all,
I wanted to propose how we can go about handling newer Ubuntu releases in a
systematic way. This covers how we handle Ubuntu on our CI, but also
reflects where we'll be focusing effort at any given point. The primary
intent is to support the most recent Ubuntu Long Term Service release
> On Apr 21, 2016, at 2:29 AM, Alexandr.moq via swift-dev
> wrote:
> Should SWIFT initialize a variable in deinit method if it has not been
> initialized?
>
> For example:
> ```swift
> class A {
> lazy var b = B()
> deinit {
> b.clean()
>
Indeed, and SR-1109 is still causing the Create installable package step to
fail for 14.04 (
https://ci.swift.org/view/Packages/job/oss-swift-package-linux-ubuntu-14_04/1075/console#console-section-9).
The failure was always there (cannot import Glibc into the REPL) but has
now been exposed since
Should SWIFT initialize a variable in deinit method if it has not been
initialized?
For example:
```swift
class A {
lazy var b = B()
deinit {
b.clean()
}
}
var a = A()
a.b.doSomething() //1: variable was created
a = A() //2: "clean" method was called for
12 matches
Mail list logo