[swift-users] Why do collections use the debugDescription on their elements?

[Martin R via swift-users]

I wonder why the description method of collections use the debugDescription 
method to print their elements, and not the description method. Example:

let s = "a\"b"
print(s) // a"b
print(s.debugDescription) // "a\"b"

let x = 1.1
print(x) // 1.1
print(x.debugDescription) // 1.1001

let d = [ s : x ]
print(d) // ["a\"b": 1.1001]


- The embedded quotation mark is printed as " in print(s), but as \" in 
print(d).
- The floating point number is printed with a higher precision in the 
dictionary description.

The same happens with `Array`, `Set` and also `Optional`. Is there a special 
reason? It seems unnecessary and a possible cause for confusion to me.

Regards,
Martin

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

Re: [swift-users] Debugging XCTests on Linux

[Ankit Agarwal via swift-users]

Using swift module in REPL:


Toolchain: January 4, 2017
Platform: Ubuntu 16.04

Add this at end of Package.swift:

```
products += [Product(name: "Result", type: .Library(.Dynamic), modules:
"Result")]
```

$ swift build
$ swift -I .build/debug -L .build/debug -lResult -I
/usr/lib/clang/3.8/include
Welcome to Swift version 3.1-dev (LLVM 217eb6c2b6, Clang 34a98ce92e, Swift
1eb5648c46). Type :help for assistance.
  1> import Result
  2> let a = Result("a")
a: Result.Result = success {
  success = "a"
}
  3> a.dematerialize()
$R0: String = "a"

PS: Make sure you pass these flags when launching docker bash:
"--security-opt seccomp=unconfined"




On Thu, Jan 5, 2017 at 3:33 PM, Robert Atkins via swift-users <
swift-users@swift.org> wrote:

> Hi all,
>
> I'm trying to solve a simple (?) problem where a test suite runs fine on
> macOS but fails on Linux
> (https://github.com/antitypical/Result/pull/210#pullrequestreview-14963305
> ).
> I've downloaded and installed the Swift Linux Docker image
> (https://ashfurrow.com/blog/swift-on-linux/) and got the project
> building and testing, and, mercifully, I get the same failure locally as
> I'm getting on Travis CI. But at this point I'm stuck.
>
> 1) I can't get the SPM-built module the project produces working
> properly in the Swift REPL in order to just play around with it
> (https://bugs.swift.org/browse/SR-1191). Can anyone help me with this?
>
> 2a) How do I use LLDB to set a breakpoint in a test method and step into
> its execution so I can trace through the source of the test failure?
> Saying "lldb swift test" does something, but doesn't know about any of
> the lines I'm trying to set a breakpoint on—I suspect it thinks I'm
> trying to set breakpoints in the swift binary itself, rather than the
> test suite?
>
> 2b) Saying "swift -warnings-as-errors test" doesn't seem to do what I
> want, complaining about "no such file or directory: 'test'", whereas
> "swift test" works fine. Is there a way to pass flags to the swift
> interpreter when it runs tests?
>
> Thanks, Robert.
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>



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

Re: [swift-users] make a static/class method return type be the subclass it is called with

[Pierre Monod-Broca via swift-users]

Hello,

It looks that you have what you wanted because Event.Entity is an alias of 
Event. 

Pierre

> Le 5 janv. 2017 à 16:47, Dave Reed via swift-users  a 
> écrit :
> 
> Is there a way to make a static or class method specify the return type be 
> the actual class it is called with?
> 
> The example code below using protocols/extensions mostly works (the type is 
> [Event.Entity] not [Event] but it seems to work.
> 
> If I try to make DDRCoreData a base class and Event subclass it, I'm only 
> able to get the return type to be [DDRCoreData], not [Event] when I call it 
> with Event.items(in: moc)
> 
> Here is the code that mostly works using protocols. Is there a better way to 
> do this?
> 
> protocol DDRCoreData {
>associatedtype Entity: NSManagedObject
> 
>static func items(in context: NSManagedObjectContext, matching predicate: 
> NSPredicate?, sortedBy sorters: [NSSortDescriptor]?) -> [Entity]
> }
> 
> extension DDRCoreData {
>static func items(in context: NSManagedObjectContext, matching predicate: 
> NSPredicate? = nil, sortedBy sorters: [NSSortDescriptor]? = nil) -> [Entity] {
>var items: [Entity] = []
>context.performAndWait {
>let fetchRequest: NSFetchRequest = Entity.fetchRequest() 
> as! NSFetchRequest
>fetchRequest.predicate = predicate
>fetchRequest.sortDescriptors = sorters
>do {
>items = try fetchRequest.execute() as [Entity]
>} catch {
> 
>}
>}
>return items
>}
> }
> 
> @objc(Event)
> public class Event: NSManagedObject {
> 
> }
> 
> extension Event: DDRCoreData {
>typealias Entity = Event
> }
> 
> // compiler says items is of type [Event.Entity]
> let items = Event.items(in: controller.managedObjectContext!)
> 
> Thanks,
> Dave Reed
> 
> 
> ___
> 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] Difficulties extending BinaryFloatingPoint

[Jens Persson via swift-users]

Great, thank you Steve!


On Thu, Jan 5, 2017 at 5:04 PM, Steve (Numerics) Canon 
wrote:

> Hi Jens —
>
> BinaryFloatingPoint is very deliberately limited to the arithmetic
> operations required by IEEE 754. This is the minimal set of operations that
> a binary floating point type should provide, but it's already a really
> large implementation burden for someone who wants to implement their own
> conforming type.
>
> I agree that there should eventually be either a refinement or orthogonal
> protocol[s] with the semantics “type implements [a subset of] the standard
> math functions”, but those shouldn’t get bolted onto 
> BinaryFloatingPoint—implementing
> these functions for an arbitrary BinaryFloatingPoint type is highly
> non-trivial, and would make the implementation burden for a new floating
> point type unreasonably high. This is also out-of-scope for the current
> phase of Swift evolution.
>
> In the short term for your immediate problem at hand, I’ve been doing
> something like:
>
> import Darwin
>
> public protocol Math: BinaryFloatingPoint {
>   func _exp() -> Self
>   func _log() -> Self
>   func _sin() -> Self
>   func _cos() -> Self
> }
>
> extension Double: Math {
>   public func _exp() -> Double { return exp(self) }
>   public func _log() -> Double { return log(self) }
>   public func _sin() -> Double { return sin(self) }
>   public func _cos() -> Double { return cos(self) }
> }
>
> extension Float: Math {
>   public func _exp() -> Float { return exp(self) }
>   public func _log() -> Float { return log(self) }
>   public func _sin() -> Float { return sin(self) }
>   public func _cos() -> Float { return cos(self) }
> }
>
> func exp(_ x: T) -> T { return x._exp() }
> func log(_ x: T) -> T { return x._log() }
> func sin(_ x: T) -> T { return x._sin() }
> func cos(_ x: T) -> T { return x._cos() }
>
> extension Math {
>   func sigmoid() -> Self {
> return 1.0 / (1.0 + exp(-self))
>   }
> }
>
> let x = 1.0
> x.sigmoid()
>
> Someone else might have a more clever solution.
> – Steve
>
> On Jan 5, 2017, at 8:22 AM, Jens Persson via swift-users <
> swift-users@swift.org> wrote:
>
> The code below doesn't compile since there is no exponential function
> (exp) that works on all FloatingPoint or BinaryFloatingPoint types, also no
> protocol seems to define the power function or the constant e, although
> they do define for example: basic arithmetic operators, squareRoot() and pi.
>
> extension BinaryFloatingPoint {
> func sigmoid() -> Self {
> return 1.0 / (1.0 + exp(-self))
> }
> }
>
> I could, but don't want to write two free funcs sigmoid(Float) -> Float
> and sigmoid(Double) -> Double, because I need to use x.sigmoid() in several
> places where x is of a generic type (a BinaryFloatingPoint).
>
> More generally: I would have the same problem if I needed eg sin or cos.
> Are there any particular reason why, given a generic BinaryFloatingPoint, I
> cannot use sin or cos, while I can use pi and squareRoot()? It does seem a
> bit arbitrary.
>
> Any ideas on how to implement a sigmoid() that works for all
> BinaryFloatingPoint types?
>
> /Jens
> ___
> 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] question about swift and c callbacks

[Ankit Agarwal via swift-users]

I simplified your example package and posted a bug report here:
https://bugs.swift.org/browse/SR-3556

On Thu, Jan 5, 2017 at 9:59 PM, Yang Yang via swift-users <
swift-users@swift.org> wrote:

> sorry， i made mistake on compiling. It still report the same link error.
>
> Yang
>
> On Wed, Jan 4, 2017 at 11:20 PM Yang Yang  wrote:
>
>> Thanks.
>> It compiled successfully now under linux.
>>
>>
>> 2017-01-04 12:29 GMT-06:00 Joe Groff :
>>
>>
>>
>>
>> > On Dec 30, 2016, at 11:17 AM, Yang Yang via swift-users <
>> swift-users@swift.org> wrote:
>>
>>
>> >
>>
>>
>> > I try to wrap a c library in swift package named Test.
>>
>>
>> > The code looks like this:
>>
>>
>> >
>>
>>
>> > Test1.h
>>
>>
>> >
>>
>>
>> > struct MyParams {
>>
>>
>> >   int (*func)();
>>
>>
>> > };
>>
>>
>> >
>>
>>
>> > typedef struct MyParams MyParams;
>>
>>
>> >
>>
>>
>> > Test2.h
>>
>>
>> > #include "Test1.h"
>>
>>
>> >
>>
>>
>> > static int test(){
>>
>>
>> >   return 0;
>>
>>
>> > }
>>
>>
>> >
>>
>>
>> > void myTest()
>>
>>
>> > {
>>
>>
>> >   MyParams params;
>>
>>
>> >   params.func = test;
>>
>>
>> > }
>>
>>
>> >
>>
>>
>> >
>>
>>
>> > Then I try to import the package into swift code and use
>>
>>
>> > in Test.swift.
>>
>>
>> > 
>>
>>
>> > import Test
>>
>>
>> >
>>
>>
>> > class TestSwift {
>>
>>
>> >   func runtest(){
>>
>>
>> > myTest()
>>
>>
>> >   }
>>
>>
>> > }
>>
>>
>> >
>>
>>
>> > However, the compiler report link error:
>>
>>
>> > function myTest: error: undefined reference to 'test'
>>
>>
>> >
>>
>>
>> > If I comment out
>>
>>
>> > "params.func = test;" in myTest.
>>
>>
>> >
>>
>>
>> > It successfully build. How should I handle this situation?
>>
>>
>>
>>
>>
>> Try making `test` static inline instead of just static.
>>
>>
>>
>>
>>
>> -Joe
>>
>>
>>
>>
>>
>>
>>
>>
>>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>


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

Re: [swift-users] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[Kenny Leung via swift-users]

Hi All.

I think this is a case of ambiguity that the compiler is not catching at the 
call site. Consider this example:

private class DefaultValues {

// If this method exists, it compiles and it called.
// If this method does not exist, the code in the test says, "Ambiguous use 
of 'guous'
/*
public func guous() {
print("guous")
}
*/

public func guous(x:Int=0) {
print("guous x:")
}

public func guous(y:Int=1) {
print("guous y:")
}

}

class DefaultValuesTests: XCTestCase {

func testDefaultValueAmbiguity() {
let ambi = DefaultValues()
ambi.guous()
}

}
 
If the no-arg method doesn’t exist, the test does not compile. There is an 
error at the call site saying, “Ambiguous use of ‘guous’”. If the no-arg method 
does exist, it is preferred, and the code compiles and runs, even though the 
ambiguity still exists. 

I think this should be classified as a compiler bug where it should be 
including no-arg methods and methods with default args to consider if they are 
ambiguous at the call site, not at the definition point.

-Kenny


> On Jan 5, 2017, at 3:17 AM, Wagner Truppel via swift-users 
>  wrote:
> 
> Exactly.
> 
> I would only add that renaming might not be the correct solution in some 
> cases as, then,  instances of the subclass would still be able to invoke the 
> superclass method and that might not always be acceptable.
> 
> Wagner
> 
>> On 5 Jan 2017, at 11:09, Frank O'Dwyer  wrote:
>> 
>> I think there is a clear case for a warning here, in that the introduction 
>> of a default parameter value in such cases is in effect an empty promise and 
>> just introduces unreachable code. Indeed 'unreachable code' should perhaps 
>> be the warning.
>> 
>> This is because as soon as there is a foo() method, whether by inheritance 
>> or a definition in the same class, it renders it impossible to invoke 
>> foo(x:) with its default value in the normal way, or in any interesting way. 
>> In fact it makes no difference at all if the default is 0, 3, or 5, or not 
>> written in the first place. You now have to be explicit. Therefore, adding 
>> the default seems to provide no utility at all and can only lead to the 
>> confusion the OP is talking about, and bugs. Furthermore it seems like a 
>> very loud indication that the programmer expected something else to happen 
>> and it violates the 'principle of least surprise' for anyone else reading 
>> the code.
>> 
>> Given all that, it seems like the syntactic vinegar of having to write a 
>> pragma to get a clean compile would be appropriate. It alerts other readers 
>> of the code that 'here be dragons', and it tells the code author that they 
>> should probably achieve what they intend in another way. Most likely, by 
>> renaming foo(), or removing the useless default for foo(x:).
>> 
>> Cheers,
>> Frank
>> 
>>> On 5 Jan 2017, at 07:58, Rien  wrote:
>>> 
>>> As you know. there is no ambiguity, no warnings needed.
>>> (The parameter is part of the identifier of the function)
>>> 
>>> Imo, this request falls into the category “do as I think, not as I say”.
>>> 
>>> That is a discussion without end. Personally I am against ANY warnings of 
>>> this kind. The reason is that I want my code to compile warnings free 
>>> (default compiler behaviour) and I do not want an extra pragma in the code 
>>> to instruct the compiler that when I am calling “foo()” I do indeed want to 
>>> call “foo()”.
>>> 
>>> Regards,
>>> Rien
>>> 
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Swiftrien
>>> Project: http://swiftfire.nl
>>> 
>>> 
>>> 
>>> 
 On 05 Jan 2017, at 03:29, Wagner Truppel via swift-users 
  wrote:
 
 Hello,
 
 I wasn’t sure whether to post this message here, at swift-dev, or at 
 swift-evolution. so I’ll try here first. Hopefully it will get to the 
 right group of people or, if not, someone will point me to the right 
 mailing list.
 
 I came across a situation that boils down to this example:
 
 class Parent {
 func foo() {
 print("Parent foo() called")
 }
 }
 
 class Child: Parent {
 func foo(x: Int = 0) {
 print("Child foo() called")
 }
 }
 
 let c = Child()
 c.foo()  // prints "Parent foo() called"
 
 I understand why this behaves like so, namely, the subclass has a method 
 foo(x:) but no direct implementation of foo() so the parent’s 
 implementation is invoked rather than the child's. That’s all fine except 
 that it is not very intuitive.
 
 I would argue that the expectation is that the search for an 
 implementation should start with the subclass (which is does) but should 
 look at all possible restrictions of parent implementations, including 

[swift-users] Debugging XCTests on Linux

[Robert Atkins via swift-users]

Hi all,

I'm trying to solve a simple (?) problem where a test suite runs fine on
macOS but fails on Linux
(https://github.com/antitypical/Result/pull/210#pullrequestreview-14963305).
I've downloaded and installed the Swift Linux Docker image
(https://ashfurrow.com/blog/swift-on-linux/) and got the project
building and testing, and, mercifully, I get the same failure locally as
I'm getting on Travis CI. But at this point I'm stuck.

1) I can't get the SPM-built module the project produces working
properly in the Swift REPL in order to just play around with it
(https://bugs.swift.org/browse/SR-1191). Can anyone help me with this?

2a) How do I use LLDB to set a breakpoint in a test method and step into
its execution so I can trace through the source of the test failure?
Saying "lldb swift test" does something, but doesn't know about any of
the lines I'm trying to set a breakpoint on—I suspect it thinks I'm
trying to set breakpoints in the swift binary itself, rather than the
test suite?

2b) Saying "swift -warnings-as-errors test" doesn't seem to do what I
want, complaining about "no such file or directory: 'test'", whereas
"swift test" works fine. Is there a way to pass flags to the swift
interpreter when it runs tests? 

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

Re: [swift-users] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[Wagner Truppel via swift-users]

Exactly.

I would only add that renaming might not be the correct solution in some cases 
as, then,  instances of the subclass would still be able to invoke the 
superclass method and that might not always be acceptable.

Wagner

> On 5 Jan 2017, at 11:09, Frank O'Dwyer  wrote:
> 
> I think there is a clear case for a warning here, in that the introduction of 
> a default parameter value in such cases is in effect an empty promise and 
> just introduces unreachable code. Indeed 'unreachable code' should perhaps be 
> the warning.
> 
> This is because as soon as there is a foo() method, whether by inheritance or 
> a definition in the same class, it renders it impossible to invoke foo(x:) 
> with its default value in the normal way, or in any interesting way. In fact 
> it makes no difference at all if the default is 0, 3, or 5, or not written in 
> the first place. You now have to be explicit. Therefore, adding the default 
> seems to provide no utility at all and can only lead to the confusion the OP 
> is talking about, and bugs. Furthermore it seems like a very loud indication 
> that the programmer expected something else to happen and it violates the 
> 'principle of least surprise' for anyone else reading the code.
> 
> Given all that, it seems like the syntactic vinegar of having to write a 
> pragma to get a clean compile would be appropriate. It alerts other readers 
> of the code that 'here be dragons', and it tells the code author that they 
> should probably achieve what they intend in another way. Most likely, by 
> renaming foo(), or removing the useless default for foo(x:).
> 
> Cheers,
> Frank
> 
>> On 5 Jan 2017, at 07:58, Rien  wrote:
>> 
>> As you know. there is no ambiguity, no warnings needed.
>> (The parameter is part of the identifier of the function)
>> 
>> Imo, this request falls into the category “do as I think, not as I say”.
>> 
>> That is a discussion without end. Personally I am against ANY warnings of 
>> this kind. The reason is that I want my code to compile warnings free 
>> (default compiler behaviour) and I do not want an extra pragma in the code 
>> to instruct the compiler that when I am calling “foo()” I do indeed want to 
>> call “foo()”.
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Swiftrien
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>>> On 05 Jan 2017, at 03:29, Wagner Truppel via swift-users 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> I wasn’t sure whether to post this message here, at swift-dev, or at 
>>> swift-evolution. so I’ll try here first. Hopefully it will get to the right 
>>> group of people or, if not, someone will point me to the right mailing list.
>>> 
>>> I came across a situation that boils down to this example:
>>> 
>>> class Parent {
>>>  func foo() {
>>>  print("Parent foo() called")
>>>  }
>>> }
>>> 
>>> class Child: Parent {
>>>  func foo(x: Int = 0) {
>>>  print("Child foo() called")
>>>  }
>>> }
>>> 
>>> let c = Child()
>>> c.foo()  // prints "Parent foo() called"
>>> 
>>> I understand why this behaves like so, namely, the subclass has a method 
>>> foo(x:) but no direct implementation of foo() so the parent’s 
>>> implementation is invoked rather than the child's. That’s all fine except 
>>> that it is not very intuitive.
>>> 
>>> I would argue that the expectation is that the search for an implementation 
>>> should start with the subclass (which is does) but should look at all 
>>> possible restrictions of parent implementations, including the restriction 
>>> due to default values.
>>> 
>>> At the very least, I think the compiler should emit a warning or possibly 
>>> even an error.
>>> 
>>> Thanks for reading.
>>> Cheers,
>>> 
>>> Wagner
>>> ___
>>> 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] Compiler should issue a warning when a subclass implementation with default values matches a parent implementation without them

[Frank O'Dwyer via swift-users]

I think there is a clear case for a warning here, in that the introduction of a 
default parameter value in such cases is in effect an empty promise and just 
introduces unreachable code. Indeed 'unreachable code' should perhaps be the 
warning.

This is because as soon as there is a foo() method, whether by inheritance or a 
definition in the same class, it renders it impossible to invoke foo(x:) with 
its default value in the normal way, or in any interesting way. In fact it 
makes no difference at all if the default is 0, 3, or 5, or not written in the 
first place. You now have to be explicit. Therefore, adding the default seems 
to provide no utility at all and can only lead to the confusion the OP is 
talking about, and bugs. Furthermore it seems like a very loud indication that 
the programmer expected something else to happen and it violates the 'principle 
of least surprise' for anyone else reading the code.

Given all that, it seems like the syntactic vinegar of having to write a pragma 
to get a clean compile would be appropriate. It alerts other readers of the 
code that 'here be dragons', and it tells the code author that they should 
probably achieve what they intend in another way. Most likely, by renaming 
foo(), or removing the useless default for foo(x:).

Cheers,
Frank

> On 5 Jan 2017, at 07:58, Rien  wrote:
> 
> As you know. there is no ambiguity, no warnings needed.
> (The parameter is part of the identifier of the function)
> 
> Imo, this request falls into the category “do as I think, not as I say”.
> 
> That is a discussion without end. Personally I am against ANY warnings of 
> this kind. The reason is that I want my code to compile warnings free 
> (default compiler behaviour) and I do not want an extra pragma in the code to 
> instruct the compiler that when I am calling “foo()” I do indeed want to call 
> “foo()”.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
> 
> 
> 
> 
>> On 05 Jan 2017, at 03:29, Wagner Truppel via swift-users 
>>  wrote:
>> 
>> Hello,
>> 
>> I wasn’t sure whether to post this message here, at swift-dev, or at 
>> swift-evolution. so I’ll try here first. Hopefully it will get to the right 
>> group of people or, if not, someone will point me to the right mailing list.
>> 
>> I came across a situation that boils down to this example:
>> 
>> class Parent {
>>   func foo() {
>>   print("Parent foo() called")
>>   }
>> }
>> 
>> class Child: Parent {
>>   func foo(x: Int = 0) {
>>   print("Child foo() called")
>>   }
>> }
>> 
>> let c = Child()
>> c.foo()  // prints "Parent foo() called"
>> 
>> I understand why this behaves like so, namely, the subclass has a method 
>> foo(x:) but no direct implementation of foo() so the parent’s implementation 
>> is invoked rather than the child's. That’s all fine except that it is not 
>> very intuitive.
>> 
>> I would argue that the expectation is that the search for an implementation 
>> should start with the subclass (which is does) but should look at all 
>> possible restrictions of parent implementations, including the restriction 
>> due to default values.
>> 
>> At the very least, I think the compiler should emit a warning or possibly 
>> even an error.
>> 
>> Thanks for reading.
>> Cheers,
>> 
>> Wagner
>> ___
>> 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] Difficulties extending BinaryFloatingPoint

[Jens Persson via swift-users]

The code below doesn't compile since there is no exponential function (exp)
that works on all FloatingPoint or BinaryFloatingPoint types, also no
protocol seems to define the power function or the constant e, although
they do define for example: basic arithmetic operators, squareRoot() and pi.

extension BinaryFloatingPoint {
func sigmoid() -> Self {
return 1.0 / (1.0 + exp(-self))
}
}

I could, but don't want to write two free funcs sigmoid(Float) -> Float and
sigmoid(Double) -> Double, because I need to use x.sigmoid() in several
places where x is of a generic type (a BinaryFloatingPoint).

More generally: I would have the same problem if I needed eg sin or cos.
Are there any particular reason why, given a generic BinaryFloatingPoint, I
cannot use sin or cos, while I can use pi and squareRoot()? It does seem a
bit arbitrary.

Any ideas on how to implement a sigmoid() that works for all
BinaryFloatingPoint types?

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

Re: [swift-users] question about swift and c callbacks

[Yang Yang via swift-users]

sorry， i made mistake on compiling. It still report the same link error.

Yang
On Wed, Jan 4, 2017 at 11:20 PM Yang Yang  wrote:

> Thanks.
> It compiled successfully now under linux.
>
>
> 2017-01-04 12:29 GMT-06:00 Joe Groff :
>
>
>
>
> > On Dec 30, 2016, at 11:17 AM, Yang Yang via swift-users <
> swift-users@swift.org> wrote:
>
>
> >
>
>
> > I try to wrap a c library in swift package named Test.
>
>
> > The code looks like this:
>
>
> >
>
>
> > Test1.h
>
>
> >
>
>
> > struct MyParams {
>
>
> >   int (*func)();
>
>
> > };
>
>
> >
>
>
> > typedef struct MyParams MyParams;
>
>
> >
>
>
> > Test2.h
>
>
> > #include "Test1.h"
>
>
> >
>
>
> > static int test(){
>
>
> >   return 0;
>
>
> > }
>
>
> >
>
>
> > void myTest()
>
>
> > {
>
>
> >   MyParams params;
>
>
> >   params.func = test;
>
>
> > }
>
>
> >
>
>
> >
>
>
> > Then I try to import the package into swift code and use
>
>
> > in Test.swift.
>
>
> > 
>
>
> > import Test
>
>
> >
>
>
> > class TestSwift {
>
>
> >   func runtest(){
>
>
> > myTest()
>
>
> >   }
>
>
> > }
>
>
> >
>
>
> > However, the compiler report link error:
>
>
> > function myTest: error: undefined reference to 'test'
>
>
> >
>
>
> > If I comment out
>
>
> > "params.func = test;" in myTest.
>
>
> >
>
>
> > It successfully build. How should I handle this situation?
>
>
>
>
>
> Try making `test` static inline instead of just static.
>
>
>
>
>
> -Joe
>
>
>
>
>
>
>
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] GCD and Process

[Mr Bee via swift-users]

Hi all,
I'm currently still learning Swift 3. Now I'm playing around with GCD (grand 
central dispatch). I'd like to start an external process using Process from an 
asynced thread, and create another thread to stop that external process after 
some times. Here's what I do…
import Foundationimport Dispatch
extension Process {  func execute(command: String, currentDir: String = "~", 
arguments: [String] = [], input: String = "") -> String {    if !input.isEmpty 
{      let pipeIn = Pipe()      self.standardInput = pipeIn      // multiple 
inputs are separated by newline      if let input = input.data(using: 
String.Encoding.utf8) {        pipeIn.fileHandleForWriting.write(input)      }  
  }        let pipeOut = Pipe()    self.standardOutput = pipeOut        
self.arguments = arguments    self.launchPath = command    
self.currentDirectoryPath = currentDir        self.launch()    let output = 
pipeOut.fileHandleForReading.readDataToEndOfFile()    self.waitUntilExit()      
  return String(data: output, encoding: String.Encoding(rawValue: 
String.Encoding.utf8.rawValue))!  }}
//print(Process().execute(command: "/bin/ls", arguments: ["-l"]))
var cmd = Process()
print("Starting...")
DispatchQueue.global(qos: .default).async {  print("Executing...")  let s = 
cmd.execute(command: "/bin/ls", arguments: ["-l"])  print(s)}
DispatchQueue.global(qos: .default).asyncAfter(deadline: DispatchTime.now() + 
.seconds(5)) {  if cmd.isRunning {    print("Terminating...")    
cmd.terminate()  }}
print("Done.") 
The code doesn't work as expected. The execute() function itself works fine 
(uncomment the call in the middle of the code), but I don't know why it doesn't 
work if it's called from within DispatchQueue closure. Even if I call a much 
more simple function —like a for loop— it doesn't work consistenly, sometimes 
the loop is completed, but other times it's not.
Google didn't really help me because this topic is pretty rare I suppose. Could 
anyone enlight me, how to make the code works as I expected? What did I do 
wrong?
Thank you.
Regards,

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

[swift-users] Bls: GCD and Process

[Mr Bee via swift-users]

How to make my app alive to make the second queue finish its job? What I want 
is:
- start program- start an external process from a thread (asynchronously)- 
start another thread after 5 seconds to terminate the process from the other 
thread- end program
That's all. 
–Mr Bee
 

Pada Jumat, 6 Januari 2017 14:49, Shawn Erickson  
menulis:
 

 It looks like you aren't keeping your app alive to allow the secondary queue 
to reliably execute the closures you queue with it. It isn't really clear what 
you want to attempt so it hard to suggest the correct way to do things.

-Shawn
On Thu, Jan 5, 2017 at 11:39 PM Mr Bee via swift-users  
wrote:

Hi all,
I'm currently still learning Swift 3. Now I'm playing around with GCD (grand 
central dispatch). I'd like to start an external process using Process from an 
asynced thread, and create another thread to stop that external process after 
some times. Here's what I do…
import Foundationimport Dispatch
extension Process {  func execute(command: String, currentDir: String = "~", 
arguments: [String] = [], input: String = "") -> String {    if !input.isEmpty 
{      let pipeIn = Pipe()      self.standardInput = pipeIn      // multiple 
inputs are separated by newline      if let input = input.data(using: 
String.Encoding.utf8) {        pipeIn.fileHandleForWriting.write(input)      }  
  }        let pipeOut = Pipe()    self.standardOutput = pipeOut        
self.arguments = arguments    self.launchPath = command    
self.currentDirectoryPath = currentDir        self.launch()    let output = 
pipeOut.fileHandleForReading.readDataToEndOfFile()    self.waitUntilExit()      
  return String(data: output, encoding: String.Encoding(rawValue: 
String.Encoding.utf8.rawValue))!  }}
//print(Process().execute(command: "/bin/ls", arguments: ["-l"]))
var cmd = Process()
print("Starting...")
DispatchQueue.global(qos: .default).async {  print("Executing...")  let s = 
cmd.execute(command: "/bin/ls", arguments: ["-l"])  print(s)}
DispatchQueue.global(qos: .default).asyncAfter(deadline: DispatchTime.now() + 
.seconds(5)) {  if cmd.isRunning {    print("Terminating...")    
cmd.terminate()  }}
print("Done.") 
The code doesn't work as expected. The execute() function itself works fine 
(uncomment the call in the middle of the code), but I don't know why it doesn't 
work if it's called from within DispatchQueue closure. Even if I call a much 
more simple function —like a for loop— it doesn't work consistenly, sometimes 
the loop is completed, but other times it's not.
Google didn't really help me because this topic is pretty rare I suppose. Could 
anyone enlight me, how to make the code works as I expected? What did I do 
wrong?
Thank you.
Regards,

–Mr Bee
___
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] getResourceValue

[Rien via swift-users]

What is your real question?
Obviously the doc says that this is fine, so what are you asking? what is your 
problem?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 05 Jan 2017, at 20:36, J.E. Schotsman via swift-users 
>  wrote:
> 
> Hello,
> 
> Is getResourceValue a method or URL or only on NSURL?
> After migrating a project to Swift 3 I have code like
> 
> var file:URL
> file.getResourceValue(...) // compiles!
> 
> From the documentation and the headers I get the impression that this should 
> not compile!
> 
> TIA,
> 
> Jan E.
> ___
> 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] Why do collections use the debugDescription on their elements?

[Ole Begemann via swift-users]

I wonder why the description method of collections use the debugDescription 
method to print their elements, and not the description method.


Dmitri Gribenko gave this reason in December 2015 [1]:


Array's description shouldn't be presented to the user in raw form,
ever, so the use case here is debugging. Thus, it makes sense to
present the debug representation of the elements in both cases.
Consider an array of strings:

var myArray = [ "", "", "" ]

If we used the regular description, then String(myArray) would be
"[  , , ]", which looks like a library bug.


[1]: 
https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151207/000272.html


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