[swift-users] Problems with @objc annotations on linux

[Kevin Lundberg via swift-users]

I just logged this bug (https://bugs.swift.org/browse/SR-6399 
) yesterday regarding some issues I’m 
seeing with getting code to compile both on linux and mac/iOS. It seems that 
method/property signatures that contain types that bridge from swift structs to 
foundation classes (String, Array, Dictionary, etc) cannot be marked @objc on 
Linux, since those types don’t auto-bridge to their foundation equivalents 
there. Is there some workaround I can use on linux that doesn’t require me to 
remove the @objc annotations (since they’re needed on iOS in a mixed language 
context) or have giant #if os(Linux) sections where tons of properties and 
methods are redefined without the annotations)?

Thanks!

--
Kevin Lundberg



___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Parsing Decimal values from JSON

[Kevin Lundberg via swift-users]

Swift shouldn't be forced to adhere to the limitations of JavaScript.
Just because JS doesn't know about decimals doesn't mean swift can't do
better.

Evtim, I don't believe JSONDecoder provides the access you are looking
for. Have you filed a bug on bugs.swift.org?

On 10/30/2017 6:02 AM, Rimantas Liubertas via swift-users wrote:
>
> It seems that the JSON decoder parses it as Double then converts
> it to Decimal which introduces errors in the parsing. That
> behavior is in fact incorrect.
>
>
> Why do you say that? JS in JSON stand for JavaScript, and Javascript
> has now idea about neither Decimal nor Integer numbers.
>
>
> Best regards,
> Rimantas
>
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Detect if a generic type is numeric

[Kevin Lundberg via swift-users]

Scratch that, that won't work for the runtime type:

isNumeric(0 as Any) == false // :(


On 10/4/2017 9:30 PM, Kevin Lundberg via swift-users wrote:
>
> Can you do something like this?
>
> func isNumber(_ value: T) -> Bool { return true }
>
> func isNumber(_ value: T) -> Bool { return false }
>
> I don't recall whether or not swift will pick the right version of the
> function here, or whether this can even compile (mac isnt open at the
> moment), but if you can overload functions in this way then it might
> be much nicer than checking for lots of concrete types.
>
>
> On 10/1/2017 6:27 PM, V T via swift-users wrote:
>>
>>
>>> On 1. Oct 2017, at 22:43, davel...@mac.com <mailto:davel...@mac.com>
>>> wrote:
>>>
>>>
>>>
>>>> On Oct 1, 2017, at 2:32 PM, Glenn L. Austin >>> <mailto:gl...@austinsoft.com>> wrote:
>>>>
>>>>>
>>>>> On Oct 1, 2017, at 8:56 AM, Dave Reed via swift-users
>>>>> mailto:swift-users@swift.org>> wrote:
>>>>>
>>>>>
>>>>>> On Sep 21, 2017, at 3:58 PM, V T via swift-users
>>>>>> mailto:swift-users@swift.org>> wrote:
>>>>>>
>>>>>> Hi there!
>>>>>>
>>>>>> Is there a best way to check if a given type conforms to numeric
>>>>>> protocol (Integer or FP) at runtime?
>>>>>>
>>>>>> func checkNumeric(_ value: T) {
>>>>>> /* return true if vaiue is Integer or FP */
>>>>>> /* this will not compile: */
>>>>>> if value is Numeric {
>>>>>>
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Best regards!
>>>>>>
>>>>>> VT
>>>>>>
>>>>>
>>>>> I think the way to do it is to try casting as the type, but you
>>>>> can't use "as? Numeric" as you get:
>>>>>
>>>>> error: protocol 'Numeric' can only be used as a generic constraint
>>>>> because it has Self or associated type requirements
>>>>>
>>>>> but you could check for each specific numeric type such as:
>>>>>
>>>>> func checkNumeric(_ value: T) {
>>>>>   if (value as? Int != nil) || (value as? Float != nil) {
>>>>>   print("numeric")
>>>>>   } else {
>>>>>   print("not numeric")
>>>>>   }
>>>>> }
>>>>>
>>>>> checkNumeric(3)
>>>>> checkNumeric(3.0)
>>>>> checkNumeric("3")
>>>>
>>>> You can also use the 'is' operator, as in 'value is Int || value is
>>>> Float || value is Double'
>>>>
>>>> -- 
>>>> Glenn L. Austin, Computer Wizard, AustinSoft.com
>>>> <http://AustinSoft.com>
>>>
>>>
>>> Ah, I had forgotten "is" works in Swift
>>>
>>> Just be careful as:
>>>
>>> func checkNumeric(_ value: T) {
>>>    if (value is Int) || (value is Float) {
>>>    print("numeric")
>>>    } else {
>>>    print("not numeric")
>>>    }
>>> }
>>>
>>
>> Thanks all! My current implementation looks like this. A bit
>> redundant, bat it works. My intention was to simplify that monster:
>>
>> func isNumber(_ value: T) -> Bool {
>>     let valueMirror = Mirror(reflecting: value)
>>     #ifarch(arm) || arch(arm64)
>>         if (valueMirror.subjectType == Int.self ||
>> valueMirror.subjectType == UInt.self || valueMirror.subjectType ==
>> Double.self || valueMirror.subjectType == Int8.self ||
>> valueMirror.subjectType == Int16.self || valueMirror.subjectType ==
>> Int32.self || valueMirror.subjectType == Int64.self ||
>> valueMirror.subjectType == UInt8.self || valueMirror.subjectType ==
>> UInt16.self || valueMirror.subjectType == UInt32.self ||
>> valueMirror.subjectType == UInt64.self || valueMirror.subjectType ==
>> Float.self || valueMirror.subjectType == Float32.self ||
>> valueMirror.subjectType == NSNumber.self || valueMirror.subjectType
>> == NSDecimalNumber.self ) {
>>             return true
>>         }
>>         else {
>>             return false
>>         }
>>     #else
>>         if (valueMirror.subjectType == Int.

Re: [swift-users] Detect if a generic type is numeric

[Kevin Lundberg via swift-users]

Can you do something like this?

func isNumber(_ value: T) -> Bool { return true }

func isNumber(_ value: T) -> Bool { return false }

I don't recall whether or not swift will pick the right version of the
function here, or whether this can even compile (mac isnt open at the
moment), but if you can overload functions in this way then it might be
much nicer than checking for lots of concrete types.


On 10/1/2017 6:27 PM, V T via swift-users wrote:
>
>
>> On 1. Oct 2017, at 22:43, davel...@mac.com 
>> wrote:
>>
>>
>>
>>> On Oct 1, 2017, at 2:32 PM, Glenn L. Austin >> > wrote:
>>>

 On Oct 1, 2017, at 8:56 AM, Dave Reed via swift-users
 mailto:swift-users@swift.org>> wrote:


> On Sep 21, 2017, at 3:58 PM, V T via swift-users
> mailto:swift-users@swift.org>> wrote:
>
> Hi there!
>
> Is there a best way to check if a given type conforms to numeric
> protocol (Integer or FP) at runtime?
>
> func checkNumeric(_ value: T) {
> /* return true if vaiue is Integer or FP */
> /* this will not compile: */
> if value is Numeric {
>
> }
> }
>
> Best regards!
>
> VT
>

 I think the way to do it is to try casting as the type, but you
 can't use "as? Numeric" as you get:

 error: protocol 'Numeric' can only be used as a generic constraint
 because it has Self or associated type requirements

 but you could check for each specific numeric type such as:

 func checkNumeric(_ value: T) {
   if (value as? Int != nil) || (value as? Float != nil) {
   print("numeric")
   } else {
   print("not numeric")
   }
 }

 checkNumeric(3)
 checkNumeric(3.0)
 checkNumeric("3")
>>>
>>> You can also use the 'is' operator, as in 'value is Int || value is
>>> Float || value is Double'
>>>
>>> -- 
>>> Glenn L. Austin, Computer Wizard, AustinSoft.com 
>>
>>
>> Ah, I had forgotten "is" works in Swift
>>
>> Just be careful as:
>>
>> func checkNumeric(_ value: T) {
>>    if (value is Int) || (value is Float) {
>>    print("numeric")
>>    } else {
>>    print("not numeric")
>>    }
>> }
>>
>
> Thanks all! My current implementation looks like this. A bit
> redundant, bat it works. My intention was to simplify that monster:
>
> func isNumber(_ value: T) -> Bool {
>     let valueMirror = Mirror(reflecting: value)
>     #ifarch(arm) || arch(arm64)
>         if (valueMirror.subjectType == Int.self ||
> valueMirror.subjectType == UInt.self || valueMirror.subjectType ==
> Double.self || valueMirror.subjectType == Int8.self ||
> valueMirror.subjectType == Int16.self || valueMirror.subjectType ==
> Int32.self || valueMirror.subjectType == Int64.self ||
> valueMirror.subjectType == UInt8.self || valueMirror.subjectType ==
> UInt16.self || valueMirror.subjectType == UInt32.self ||
> valueMirror.subjectType == UInt64.self || valueMirror.subjectType ==
> Float.self || valueMirror.subjectType == Float32.self ||
> valueMirror.subjectType == NSNumber.self || valueMirror.subjectType ==
> NSDecimalNumber.self ) {
>             return true
>         }
>         else {
>             return false
>         }
>     #else
>         if (valueMirror.subjectType == Int.self ||
> valueMirror.subjectType == UInt.self || valueMirror.subjectType ==
> Double.self || valueMirror.subjectType == Int8.self ||
> valueMirror.subjectType == Int16.self || valueMirror.subjectType ==
> Int32.self || valueMirror.subjectType == Int64.self ||
> valueMirror.subjectType == UInt8.self || valueMirror.subjectType ==
> UInt16.self || valueMirror.subjectType == UInt32.self ||
> valueMirror.subjectType == UInt64.self || valueMirror.subjectType ==
> Float.self || valueMirror.subjectType == Float32.self ||
> valueMirror.subjectType == Float80.self || valueMirror.subjectType ==
> NSNumber.self || valueMirror.subjectType == NSDecimalNumber.self ) {
>             return true
>         }
>         else {
>             return false
>         }
>     #endif
> }
>
>> checkNumeric(3)
>> checkNumeric(3.0)
>> checkNumeric("3")
>>
>> outputs:
>>
>> numeric
>> not numeric
>> not numeric
>>
>> Since the literal 3.0 is a Double so you'd have to catch every
>> floating point type (including CGFloat, I suspect etc.) vs. just
>> trying to cast to a Float (although I guess casting to a Float could
>> have unexpected results also if someone made an extension that allows
>> a type to be cast as a Float).
>>
>> Dave
>>
>>
>
>
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Calling (Void) -> () with Void

[Kevin Lundberg via swift-users]

I think the fix-it is hinting that you need a value of type Void, not
literally Void itself. It's a bit confusing since () is both a type and
a value, while Void is only a type since it's declared as a typealias.
Typealiases aren't processed like macros are, it would seem.

I think the convention for function types is to only use Void after the
arrow (if at all) to avoid this confusion:

let foo: () -> Void = {} // or just () -> (), takes no params

let bar: (()) -> () // clear(er) that it takes one param of type ()

On 7/9/2017 8:43 PM, Saagar Jha via swift-users wrote:
> Hello,
>
> I’m having some odd results with closures that take Void as a
> parameter, and was wondering if this was expected behavior or a bug.
> Specifically, I have the following closure:
>
> > Welcome to Apple Swift version 4.0 (swiftlang-900.0.45.6
> clang-900.0.26).
> > let foo: (Void) -> () = {}
>
>
> Trying to call foo without parameters fails, of course:
>
> > foo()
> error: missing argument for parameter #1 in call
> foo()
> ^
> <#Void#>
>
>
> However, the fix-it doesn’t seem to work:
>
> > foo(Void) // or even: foo(Void())
> error: argument passed to call that takes no arguments
> foo(Void)
>^~
>
>
> while
>
> > foo(()) // Executes with no errors
>
>
> works. Since Void is a typealias for () this should work, shouldn’t
> it? Just wanted to confirm that I’m not going crazy here.
>
> Regards,
> Saagar Jha
>
>
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Discrepancy between sharing internal Swift symbols with Obj-C when in an app vs a framework target

[Kevin Lundberg via swift-users]

My apologies if I insinuated that the effort would be small or trivial, that 
wasn’t my intent.

The converse situation that you describe, where objc code must also be public 
in the framework makes sense. I didn’t mind that myself when I was attempting 
this since this is an internally used framework only, but ideally that should 
also be resolved. The fact that swift in frameworks has to be public for this 
to work today is less a problem for me than the discrepancy between target 
types.

I logged a radar for the swift -> objc case that I described initially as 
that’s the use case that affects me most: rdar://26663470. 

--
Kevin Lundberg
ke...@klundberg.com

> On Jun 6, 2016, at 1:34 PM, Jordan Rose  wrote:
> 
> We don't currently have a way to generate two headers, one to be used 
> internally and one externally. For methods and properties on existing types, 
> it's safe to write a category manually to be included in your .m files, but 
> classes and protocols don't really have a good answer.
> 
> This is very similar to another existing problem, that you can't import 
> implementation-detail things into Swift without making them public. However, 
> that problem still needs a lot of design, whereas this one is essentially as 
> simple as "generate two headers". (It's not quite that easy because you need 
> one to import the other rather than having them be independent, but it's 
> still a problem where it's known that the solution will work.)
> 
> "Simple" or "easy" does not necessarily mean "quick to implement", though, so 
> we have to balance this against other improvements.
> 
> Best,
> Jordan
> 
> 
>> On Jun 4, 2016, at 13:00, Daniel Dunbar via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> Unfortunately, this is a limitation of the current model for mixed Obj-C and 
>> Swift targets. The Swift code is compiled and optimized as a single module, 
>> and the only supported external entry points that result from that are the 
>> public API, which is then exposed as the "-Swift.h" header file.
>> 
>> However, this limitation applies to application targets as well, so I'm not 
>> sure I understand yet what the blocker is w.r.t. your migration. Can you 
>> explain more?
>> 
>> - Daniel
>> 
>>> On Jun 4, 2016, at 11:29 AM, Kevin Lundberg via swift-users 
>>> mailto:swift-users@swift.org>> wrote:
>>> 
>>> The former case is what I'm concerned with. I agree that code external to 
>>> the framework should only see public symbols. However objc code inside the 
>>> same framework as the swift code in question should ideally be able to see 
>>> internal swift symbols as well, as they are within the same module.
>>> 
>>> --
>>> Kevin Lundberg
>>> 
>>> On Jun 4, 2016, at 2:48 AM, Brent Royal-Gordon >> <mailto:br...@architechies.com>> wrote:
>>> 
>>>>> I ran into a major hurdle this week that basically stopped my work in
>>>>> its tracks. I've been working on moving a large codebase from an iOS app
>>>>> target to a framework target, since we have the same code in multiple
>>>>> app targets and it is problematic to have to remember to add new code to
>>>>> every single app target when they can all just share a framework.
>>>> 
>>>> To be clear: Are you having trouble making the Objective-C and Swift 
>>>> inside your framework talk to each other, or the Objective-C outside your 
>>>> framework talk to the Swift inside your framework?
>>>> 
>>>> If it's the latter, then I agree with Jens that this is "works as 
>>>> intended", and you're just going to have to spend some time pasting 
>>>> `public` into your code in a lot of places. But if you're being forced to 
>>>> make Swift APIs public so you can use them from Objective-C *inside* the 
>>>> framework, that might be something worth talking about.
>>>> 
>>>> -- 
>>>> Brent Royal-Gordon
>>>> Architechies
>>>> 
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-users
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users
> 

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Discrepancy between sharing internal Swift symbols with Obj-C when in an app vs a framework target

[Kevin Lundberg via swift-users]

Its not just methods, but types themselves. Even if this was a solution
I'd still have to manually fix all build issues by prepending dynamic to
everything that needs it :(


On 6/4/2016 2:56 PM, Austin Zheng wrote:
> This is probably a solution to a different issue, but what happens if
> you declare your "should be visible from Objective-C" swift methods as
> 'dynamic'?
>
> Austin
>
>> On Jun 4, 2016, at 11:55 AM, Jens Alfke via swift-users
>> mailto:swift-users@swift.org>> wrote:
>>
>>
>>> On Jun 4, 2016, at 11:29 AM, Kevin Lundberg via swift-users
>>> mailto:swift-users@swift.org>> wrote:
>>>
>>> However objc code inside the same framework as the swift code in
>>> question should ideally be able to see internal swift symbols as
>>> well, as they are within the same module.
>>
>> I agree; I didn’t realize that was your situation. I haven’t tried
>> doing this myself. It sounds like a bug.
>>
>> —Jens
>> ___
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users
>

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Discrepancy between sharing internal Swift symbols with Obj-C when in an app vs a framework target

[Kevin Lundberg via swift-users]

Our application target swift code is internal since we don't bother putting 
public in there as its not shared outside the app(s), obviously. The internally 
scoped swift code is exported to obj/c through the generated -Swift.h header 
when in the app target, in addition to anything marked as public (unlike the 
framework case where only public symbols are found in that header). 

This discrepancy seems off, and could possibly trip up anyone else who wants to 
migrate some mixed language code from an app to a framework. I'd love for there 
to be some way to import internal symbols in a private/project visible header 
in objc code in the same framework. I'd be less enthusiastic if consistency 
went in the other direction where swift code had to be public to be seen in 
objc code in an app too, but at least that would be consistent behavior for all 
types of build targets (and if that change resulted in a migrator to do the 
work that was too much for me to tackle manually, that wouldn't be too bad).

--
Kevin Lundberg

> On Jun 4, 2016, at 4:00 PM, Daniel Dunbar  wrote:
> 
> Unfortunately, this is a limitation of the current model for mixed Obj-C and 
> Swift targets. The Swift code is compiled and optimized as a single module, 
> and the only supported external entry points that result from that are the 
> public API, which is then exposed as the "-Swift.h" header file.
> 
> However, this limitation applies to application targets as well, so I'm not 
> sure I understand yet what the blocker is w.r.t. your migration. Can you 
> explain more?
> 
> - Daniel
> 
>> On Jun 4, 2016, at 11:29 AM, Kevin Lundberg via swift-users 
>>  wrote:
>> 
>> The former case is what I'm concerned with. I agree that code external to 
>> the framework should only see public symbols. However objc code inside the 
>> same framework as the swift code in question should ideally be able to see 
>> internal swift symbols as well, as they are within the same module.
>> 
>> --
>> Kevin Lundberg
>> 
>> On Jun 4, 2016, at 2:48 AM, Brent Royal-Gordon  
>> wrote:
>> 
>>>> I ran into a major hurdle this week that basically stopped my work in
>>>> its tracks. I've been working on moving a large codebase from an iOS app
>>>> target to a framework target, since we have the same code in multiple
>>>> app targets and it is problematic to have to remember to add new code to
>>>> every single app target when they can all just share a framework.
>>> 
>>> To be clear: Are you having trouble making the Objective-C and Swift inside 
>>> your framework talk to each other, or the Objective-C outside your 
>>> framework talk to the Swift inside your framework?
>>> 
>>> If it's the latter, then I agree with Jens that this is "works as 
>>> intended", and you're just going to have to spend some time pasting 
>>> `public` into your code in a lot of places. But if you're being forced to 
>>> make Swift APIs public so you can use them from Objective-C *inside* the 
>>> framework, that might be something worth talking about.
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Discrepancy between sharing internal Swift symbols with Obj-C when in an app vs a framework target

[Kevin Lundberg via swift-users]

The former case is what I'm concerned with. I agree that code external to the 
framework should only see public symbols. However objc code inside the same 
framework as the swift code in question should ideally be able to see internal 
swift symbols as well, as they are within the same module.

--
Kevin Lundberg

On Jun 4, 2016, at 2:48 AM, Brent Royal-Gordon  wrote:

>> I ran into a major hurdle this week that basically stopped my work in
>> its tracks. I've been working on moving a large codebase from an iOS app
>> target to a framework target, since we have the same code in multiple
>> app targets and it is problematic to have to remember to add new code to
>> every single app target when they can all just share a framework.
> 
> To be clear: Are you having trouble making the Objective-C and Swift inside 
> your framework talk to each other, or the Objective-C outside your framework 
> talk to the Swift inside your framework?
> 
> If it's the latter, then I agree with Jens that this is "works as intended", 
> and you're just going to have to spend some time pasting `public` into your 
> code in a lot of places. But if you're being forced to make Swift APIs public 
> so you can use them from Objective-C *inside* the framework, that might be 
> something worth talking about.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Discrepancy between sharing internal Swift symbols with Obj-C when in an app vs a framework target

[Kevin Lundberg via swift-users]

I ran into a major hurdle this week that basically stopped my work in
its tracks. I've been working on moving a large codebase from an iOS app
target to a framework target, since we have the same code in multiple
app targets and it is problematic to have to remember to add new code to
every single app target when they can all just share a framework.

However I didn't anticipate the issue that made this task explode in
terms of effort. According to the Using Swift with Cocoa & obj-C book
(this section:
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html#//apple_ref/doc/uid/TP40014216-CH10-ID122),
swift code in an app target can be accessed from obj-c if it is internal
or public. However, swift code in a framework target can only be
accessed from objc if it is public, not internal.

Is there any way around this restriction? The codebase I want to migrate
has a lot of swift and obj-c intermingling, and I can't see a reasonable
end to converting everything I need to convert to public from internal
for this to work.

If there's no feasible workaround, would swift-evolution be the proper
place to discuss changing this behavior? Or is this something that would
need to be logged in radar for the Xcode team to address?

Thanks,
- Kevin
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift.org RSS Feed appears broken

[Kevin Lundberg via swift-users]

I saw the latest 2.2 announcement post in my reader yesterday, so it does 
appear to be fixed.

Kevin Lundberg
ke...@klundberg.com



> On Mar 24, 2016, at 1:18 PM, Ted Kremenek via swift-users 
>  wrote:
> 
> Hi Neil,
> 
> Aside from the encoding issue (which we are looking into), this should now be 
> fixed.  Can you check on your end?
> 
> Thanks,
> Ted
> 
>> On Mar 22, 2016, at 5:53 AM, Neil via swift-users > > wrote:
>> 
>> Hello all,
>> 
>> What is the correct place to report that swift.org  rss 
>> feeds are broken?  The feed does not work with Vienna on OS X and fails W3C 
>> validation.
>> 
>> Thanks,
>> 
>> Neil
>> 
>> https://validator.w3.org/feed/check.cgi?url=feed%3Ahttps%3A%2F%2Fswift.org%2Fatom.xml
>>  
>> 
>> 
>> Sorry
>> 
>> This feed does not validate.
>>  • line 15, column 21: id must be a full and valid URL: /blog/welcome (9 
>> occurrences) [help]
>>/blog/welcome
>> ^
>>  • line 54, column 2: Missing entry element: author (9 occurrences) 
>> [help]
>>  
>>  ^
>> In addition, interoperability with the widest range of feed readers could be 
>> improved by implementing the following recommendations.
>>  • Your feed appears to be encoded as "utf-8", but your server is 
>> reporting "US-ASCII" [help]
>> 
>>  • line 4, column 65: Relative href value on self link: /atom.xml [help]
>>  
>> ^
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] memory requirements for building swift on linux?

[Kevin Lundberg via swift-users]

This appears to have helped me. I’m on to testing the build, it appears my 
linker woes are behind me. Thanks!

- Kevin

> On Dec 14, 2015, at 12:04 PM, Daniel Dunbar  wrote:
> 
> For those hitting this issue, you might try building without debug info to 
> see if that helps (build-script -R).
> 
>  - Daniel
> 
>> On Dec 14, 2015, at 6:55 AM, Kevin Lundberg via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> I was able to build it on my 8GB macbook successfully, but there may be 
>> platform differences there that caused that.
>> 
>> It seems that 4GB isn't enough either, fails when linking clang-3.8. I'll 
>> have to figure something else out for linux for me. Thanks!
>> 
>> On 12/14/2015 9:30 AM, Tobias Scholze wrote:
>>> Hi,
>>> to build Swift from the sources I used a 16 GB bare metal machine and it 
>>> was not enough.
>>> So I think, you need a lot of memory ( > 16 GB) to have fun while building 
>>> it.
>>> 
>>> - Toby
>>> 
>>> Kevin Lundberg via swift-users < 
>>> <mailto:swift-users@swift.org>swift-users@swift.org 
>>> <mailto:swift-users@swift.org>> schrieb am Mo., 14. Dez. 2015 um 15:03 Uhr:
>>> Hi All,
>>> 
>>> I've set up a linux VM (ubuntu 15.10) in virtualbox on my windows PC to
>>> build and test swift on linux, but I've been unable to successfully
>>> build it to completion. I have all the repos including the corelibs
>>> cloned locally, and have followed all the steps as far as I know for
>>> installing dependencies. Every time I build, it fails somewhere during
>>> linking, the last time failing when  linking "CXX shared library
>>> lib/libLTO.so".
>>> 
>>> I don't have the full error, but I'm curious if there's some RAM
>>> requirement for building swift. My VM had 2GB, and I just bumped it up
>>> to 4GB to try again. Has anyone else run into this, and is there a
>>> recommended minimum needed to successfully build swift with? Could
>>> something else be the cause here instead of RAM if 2GB is in fact enough?
>>> 
>>> Thanks!
>>> 
>>> -Kevin
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> <https://lists.swift.org/mailman/listinfo/swift-users>
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users
> 

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] memory requirements for building swift on linux?

[Kevin Lundberg via swift-users]

I was able to build it on my 8GB macbook successfully, but there may be
platform differences there that caused that.

It seems that 4GB isn't enough either, fails when linking clang-3.8.
I'll have to figure something else out for linux for me. Thanks!

On 12/14/2015 9:30 AM, Tobias Scholze wrote:
> Hi,
> to build Swift from the sources I used a 16 GB bare metal machine and
> it was not enough.
> So I think, you need a lot of memory ( > 16 GB) to have fun while
> building it.
>
> - Toby
>
> Kevin Lundberg via swift-users  <mailto:swift-users@swift.org>> schrieb am Mo., 14. Dez. 2015 um
> 15:03 Uhr:
>
> Hi All,
>
> I've set up a linux VM (ubuntu 15.10) in virtualbox on my windows
> PC to
> build and test swift on linux, but I've been unable to successfully
> build it to completion. I have all the repos including the corelibs
> cloned locally, and have followed all the steps as far as I know for
> installing dependencies. Every time I build, it fails somewhere during
> linking, the last time failing when  linking "CXX shared library
> lib/libLTO.so".
>
> I don't have the full error, but I'm curious if there's some RAM
> requirement for building swift. My VM had 2GB, and I just bumped it up
> to 4GB to try again. Has anyone else run into this, and is there a
> recommended minimum needed to successfully build swift with? Could
> something else be the cause here instead of RAM if 2GB is in fact
> enough?
>
> Thanks!
>
> -Kevin
> ___
> swift-users mailing list
> swift-users@swift.org <mailto:swift-users@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users
>

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] memory requirements for building swift on linux?

[Kevin Lundberg via swift-users]

Hi All,

I've set up a linux VM (ubuntu 15.10) in virtualbox on my windows PC to
build and test swift on linux, but I've been unable to successfully
build it to completion. I have all the repos including the corelibs
cloned locally, and have followed all the steps as far as I know for
installing dependencies. Every time I build, it fails somewhere during
linking, the last time failing when  linking "CXX shared library
lib/libLTO.so".

I don't have the full error, but I'm curious if there's some RAM
requirement for building swift. My VM had 2GB, and I just bumped it up
to 4GB to try again. Has anyone else run into this, and is there a
recommended minimum needed to successfully build swift with? Could
something else be the cause here instead of RAM if 2GB is in fact enough?

Thanks!

-Kevin
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users