Hi Roman,
> On 31 Jan 2017, at 15:51, Roman Pastushkov via swift-dev
> wrote:
>
> Hello everyone! Now i am trying (newbie) on Ubuntu Swift 3. I am trying to
> Read String from File Using FileHandle
>
> import Foundation
> let filemgr = FileManager.default
> let filepath1 = "/home/roman/test"
Hi Mark,
That's unfortunate. Assuming you're on macOS, do you mind running
ls ~/Library/Logs/DiagnosticReports/swift*.crash
that might reveal some compiler crash reports. If yes I think the best would be
to file a bug for these crashes on http://bugs.swift.org . What presumably
would be most h
Hi Mark,
> Here’s the directory although these are all old and not related to the crash
> under discussion (the most recent crash is for swiftc 800.0.63, the Xcode 3.1
> toolchain appears to be 802.0.48). I was able to reproduce today with Xcode
> 8.3.1 update but no log with today’s date.
o
Ok, one more question: How do you know swiftc crashed, what exactly is printed?
In Xcode for example, do you see something like
Command
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc
failed with exit code 6
in the "Report navigator". Maybe you cou
Hi,
So as far as I know Xcode doesn't really discriminate between exit codes and
signals. So it could be signal 1 (SIGHUP, unlikely) or exit code 1 (more
likely). I guess the next step would be to open Terminal.app and just paste
everything from the step that's failing in the Xcode build output
fantastic, that's definitely a Swift/LLVM bug. From what I can see the most
relevant bit is
--- SNIP ---
> "output": "PHI node operands are not the same type as the result!\n %384 =
> phi %CSo7UIColor* [ %395, %394 ], [ %377, %379 ], !dbg !469\nPHI node
> operands are not the same type as th
Hi swift-dev,
If I have basically this program (full program see at the tail end of this mail)
public class A { func bar() { ... }}
public protocol B {
func foo(_ a: A)
}
extension B {
func foo(_ a: A) { a.bar() }
}
public class ActualB: B {
}
public class OtherB: B {
}
func abc() {
l
c_stack (It could because @in_guaranteed guarantees no write) … i would
> expect it to mem promote this … ARC could then remove the retain/release pair
> (AFAICT).
>
>
> https://bugs.swift.org/browse/SR-5403
>
>
>> On Jul 7, 2017, at 11:27 AM, Johannes Weiß via swif
Hi swift-dev,
I haven't heard anything about semantic ARC and couldn't really find much
documentation besides
https://gottesmm.github.io/proposals/high-level-arc-memory-operations.html . So
I wanted to ask how much of it is implemented and what the plan for Swift 4/5
regarding Semantic ARC is.
Hi Michael,
Firstly: if swift-dev is not the right place for me to ask silly questions,
please let me know :).
Thanks very much for all your pointers on the JIRA [1] ticket. I was just
trying to get started and already have a few questions. Apologies, they're very
basic as I'm just getting sta
this :)
Thanks,
Johannes
> On 10 Jul 2017, at 2:22 am, Michael Gottesman wrote:
>
>
>> On Jul 8, 2017, at 10:36 AM, Johannes Weiß via swift-dev
>> wrote:
>>
>> Hi swift-dev,
>>
>> I haven't heard anything about semantic ARC and couldn
Hi Michael,
> [...]
>> Now you advise to run the '-debug-only=sil-redundant-load-elim' so I tried
>>
>> sil-opt [...] -debug-only=sil-redundant-load-elim
>>
>> but it doesn't seem happy with that. Did I misunderstand how to pass this
>> option?
>
> What do you mean by it doesn't seem happy?
Hi Michael,
> [...]
>> Long story short, I think the RLE actually works for the test case I
>> created. It's even clever enough to see through my invalid function bad()
>> which modified the storage despite its claim that it doesn't. I might also
>> be misunderstanding something.
>
> When som
Thanks Michael!
Erik, I hope what I wrote makes some sense. Any questions or suggestions,
please let me know.
> On 14 Jul 2017, at 7:30 pm, Michael Gottesman wrote:
>
>>
>> On Jul 12, 2017, at 9:53 AM, Johannes Weiß wrote:
>>
>> Hi Michael,
>>
>>
>>> [...]
Long story short, I think t
Hi Erik,
> On 17 Jul 2017, at 10:26 pm, Erik Eckstein wrote:
>
> Hi Johannes,
>
> great that you want to work on this!
Thanks for your help, without Michael's and your help I wouldn't have been able
to do anything here really!
> Some ideas:
> SideEffectAnalysis currently does not have a not
Thanks, both suggestions look great. Will work them in tomorrow and will also
try to add a test for the whole thing.
> On 18 Jul 2017, at 5:53 pm, Michael Gottesman wrote:
>
>>
>> On Jul 18, 2017, at 8:39 AM, Johannes Weiß wrote:
>>
>> Hi Erik,
>>
>>> On 17 Jul 2017, at 10:26 pm, Erik Eckst
great, thank you. I think I have worked all the suggestions in, let's do the
rest in this PR: https://github.com/apple/swift/pull/11040
It's getting late here so I'll probably to the test tomorrow (but marked the
patch as 'do not merge' & added that a test is still missing).
> On 18 Jul 2017, a
Thanks very much Eric & Michael for your help! And thanks for merging it. Will
this automatically be part of Swift 4 or do I need to make another PR against a
swift 4 branch?
Thanks,
Johannes
> On 18 Jul 2017, at 9:21 pm, Johannes Weiß via swift-dev
> wrote:
>
> great, th
gt;>
>>
>>> On Jul 25, 2017, at 12:55 PM, Johannes Weiß via swift-dev
>>> wrote:
>>>
>>> Thanks very much Eric & Michael for your help! And thanks for merging it.
>>> Will this automatically be part of Swift 4 or do I need to make
Hi all,
Sorry, only back from vacation now. The URLs seem to be 404, any information on
what failed?
Thanks,
Johannes
> On 30 Aug 2017, at 10:52 pm, Michael Ilseman via swift-dev
> wrote:
>
> This failed while running ‘TestURLSession.test_concurrentRequests’. hi, is
> this related to your
That sounds awesome! Don't have much time right now to check the details but
these 'near misses' have been a real problem for us.
> On 26 Oct 2017, at 9:28 pm, Douglas Gregor via swift-dev
> wrote:
>
> I have a pull request up to introduce “near-miss” warnings for protocol
> conformances:
>
Definitely a +1 from me, a haven't recently seen much of a difference either.
Said that I do sometimes use it in a micro-benchmark just to convince myself we
don't lose much performance on the checks. Usually it turns out fine, I'm happy
and move on. But I guess there's some value in being able
> On 2 Nov 2017, at 1:33 pm, Erik Eckstein wrote:
>
>
>
>> On Nov 2, 2017, at 10:51 AM, Johannes Weiß wrote:
>>
>> Definitely a +1 from me, a haven't recently seen much of a difference either.
>>
>> Said that I do sometimes use it in a micro-benchmark just to convince myself
>> we don't l
Hi swift-dev,
I talked to a few people about this problem and we agreed that it is a problem
and that it needs to be discussed. I didn't quite know where it would fit best
but let's go with swift-dev, please feel free to tell to post it elsewhere if
necessary. And apologies for the long mail, c
ibraries in the program
will need to know and agree on that type
- sounds like ThreadSanitizer would trap here unless we synchronise it which
would make it slow again
-- Johannes
> - Daniel
>
>> On Nov 2, 2017, at 5:57 PM, Johannes Weiß via swift-dev
>> wrote:
>>
>>
25 matches
Mail list logo
