Re: [swift-users] SwiftPM: import ncurses -> conflicting types

2016-12-28 Thread Bouke Haarsma via swift-users 
In hindsight it just looks so easy -- I already found those headers in 
the SDK. Thanks!


On 2016-12-29 05:53:22 +, Ankit Aggarwal via swift-users said:

ncurses is already present in the macOS sdk, so you don't need to 
install it via brew.


In CNCurses package, create a file called "shim.h":
$ cat shim.h
#include "ncurses.h"

and change the modulemap to this:
$ cat module.modulemap
module CNCurses [system] {
  header "shim.h"
  link "ncurses"
  export *
}

On 29-Dec-2016, at 1:25 AM, Bouke Haarsma via swift-users 
 wrote:


Hi all,

I'm trying to build something with ncurses. There's this outdated 
tutorial: 
http://dev.iachieved.it/iachievedit/ncurses-with-swift-on-linux/. In 
order to build, a system module map was provided here: 
https://github.com/iachievedit/CNCURSES. This assumes 
`/usr/include/ncurses.h`, which is not available on MacOS 10.12. So 
I've installed ncurses through homebrew and updated the modulemap: 
https://github.com/Bouke/CNCurses. Sadly though, it doesn't work and I 
can't figure out how to get it working.



brew install homebrew/dupes/ncurses


Module map:


module CNCurses [system] {
header "/usr/local/Cellar/ncurses/6.0_2/include/ncurses.h"
link "ncurses"
export *
}


I'm building with the following command, the flags taken from the 
package provided ncurses.pc:



swift build \
-Xcc -D_DARWIN_C_SOURCE \
-Xcc -I/usr/local/Cellar/ncurses/6.0_2/include \
-Xcc -I/usr/local/Cellar/ncurses/6.0_2/include/ncursesw \
-Xlinker -L/usr/local/Cellar/ncurses/6.0_2/lib


This produces the following error message (shortened):


Compile Swift Module 'TermDraw' (1 sources)
:1:9: note: in file included from :1:
#import "/usr/local/Cellar/ncurses/6.0_2/include/ncurses.h"
^
/usr/local/Cellar/ncurses/6.0_2/include/ncurses.h:60:10: error: 
'ncursesw/ncurses_dll.h' file not found with  include; use 
"quotes" instead

#include 
^
:1:9: note: in file included from :1:
#import "/usr/local/Cellar/ncurses/6.0_2/include/ncurses.h"
^
/usr/local/Cellar/ncurses/6.0_2/include/ncurses.h:653:45: error: 
conflicting types for 'keyname'
extern NCURSES_EXPORT(NCURSES_CONST char *) keyname (int);  
/* implemented */

^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/curses.h:598:45: 
note: previous declaration is here
extern NCURSES_EXPORT(NCURSES_CONST char *) keyname (int);  
/* implemented */

^
:1:9: note: in file included from :1:
#import "/usr/local/Cellar/ncurses/6.0_2/include/ncurses.h"
^


(and goes on for quite a few other conflicting types)

Any help on getting this to build is greatly appreciated. Example code 
can be found here: https://github.com/Bouke/TermDraw


---
Thanks,
Bouke


___
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] SwiftPM: import ncurses -> conflicting types

2016-12-28 Thread Ankit Aggarwal via swift-users 
ncurses is already present in the macOS sdk, so you don't need to install it 
via brew.

In CNCurses package, create a file called "shim.h":
$ cat shim.h
#include "ncurses.h"

and change the modulemap to this: 
$ cat module.modulemap
module CNCurses [system] {
  header "shim.h"
  link "ncurses"
  export *
}

> On 29-Dec-2016, at 1:25 AM, Bouke Haarsma via swift-users 
>  wrote:
> 
> Hi all,
> 
> I'm trying to build something with ncurses. There's this outdated tutorial: 
> http://dev.iachieved.it/iachievedit/ncurses-with-swift-on-linux/. In order to 
> build, a system module map was provided here: 
> https://github.com/iachievedit/CNCURSES. This assumes 
> `/usr/include/ncurses.h`, which is not available on MacOS 10.12. So I've 
> installed ncurses through homebrew and updated the modulemap: 
> https://github.com/Bouke/CNCurses. Sadly though, it doesn't work and I can't 
> figure out how to get it working.
> 
>> brew install homebrew/dupes/ncurses
> 
> Module map:
> 
>> module CNCurses [system] {
>>header "/usr/local/Cellar/ncurses/6.0_2/include/ncurses.h"
>>link "ncurses"
>>export *
>> }
> 
> I'm building with the following command, the flags taken from the package 
> provided ncurses.pc:
> 
>> swift build \
>>  -Xcc -D_DARWIN_C_SOURCE \
>>  -Xcc -I/usr/local/Cellar/ncurses/6.0_2/include \
>>  -Xcc -I/usr/local/Cellar/ncurses/6.0_2/include/ncursesw \
>>  -Xlinker -L/usr/local/Cellar/ncurses/6.0_2/lib
> 
> This produces the following error message (shortened):
> 
>> Compile Swift Module 'TermDraw' (1 sources)
>> :1:9: note: in file included from :1:
>> #import "/usr/local/Cellar/ncurses/6.0_2/include/ncurses.h"
>>^
>> /usr/local/Cellar/ncurses/6.0_2/include/ncurses.h:60:10: error: 
>> 'ncursesw/ncurses_dll.h' file not found with  include; use "quotes" 
>> instead
>> #include 
>> ^
>> :1:9: note: in file included from :1:
>> #import "/usr/local/Cellar/ncurses/6.0_2/include/ncurses.h"
>>^
>> /usr/local/Cellar/ncurses/6.0_2/include/ncurses.h:653:45: error: conflicting 
>> types for 'keyname'
>> extern NCURSES_EXPORT(NCURSES_CONST char *) keyname (int);  /* 
>> implemented */
>>^
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/curses.h:598:45:
>>  note: previous declaration is here
>> extern NCURSES_EXPORT(NCURSES_CONST char *) keyname (int);  /* 
>> implemented */
>>^
>> :1:9: note: in file included from :1:
>> #import "/usr/local/Cellar/ncurses/6.0_2/include/ncurses.h"
>>^
> 
> (and goes on for quite a few other conflicting types)
> 
> Any help on getting this to build is greatly appreciated. Example code can be 
> found here: https://github.com/Bouke/TermDraw
> 
> ---
> Thanks,
> Bouke
> 
> 
> ___
> 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] Using 'SomeProtocol' as a concrete type conforming to protocol 'SomeProtocol' is not supported

2016-12-28 Thread Ray Fix via swift-users 

Using Optional, your enum type goes away.  (I think it is a great solution 
unless you need something more than .element and .none in real life.)  Great to 
get all that optional machinery for missing values for free!  Then you can 
constrain elements simply from the Element protocol as in as in:

protocol Element {
func compute() -> Int
}

struct ElementType1: Element {
func compute() -> Int {
return 1
}
}
struct ElementType2: Element {
func compute() -> Int {
return 2
}
}

var childElements: [Element?] = []

childElements.append(ElementType1())
childElements.append(ElementType2())
childElements.append(nil)

childElements.flatMap { $0 }.forEach { print($0.compute()) }

1
2



> On Dec 28, 2016, at 4:10 PM, Brandon Knope via swift-users 
>  wrote:
> 
> Aren’t I losing the ability to enforce what is going into this enum’s 
> associated value then?
> 
> Brandon
> 
>> On Dec 28, 2016, at 7:05 PM, Nevin Brackett-Rozinsky 
>> > 
>> wrote:
>> 
>> It will work if you change the enum declaration to:
>> 
>> enum ElementNode
>> 
>> In other words, let the enum hold arbitrary unconstrained associated types, 
>> and then make your APIs utilize instances of the enum with the associated 
>> type constrained to a protocol.
>> 
>> The specific example you provide is essentially equivalent to:
>> 
>> var childElements = [Element?]()
>> 
>> Nevin
>> 
>> 
>> On Wed, Dec 28, 2016 at 6:41 PM, Brandon Knope via swift-users 
>> > wrote:
>> I don’t understand why this is a problem
>> 
>> protocol Element {
>> 
>> }
>> 
>> enum ElementNode {
>> case element(T)
>> case empty
>> }
>> 
>> var childElements = [ElementNode]()
>> 
>> I need to represent an array of my nodes that could be multiple kinds of 
>> elements
>> 
>> Is there a workaround?
>> 
>> Brandon
>> 
>> ___
>> 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] Using 'SomeProtocol' as a concrete type conforming to protocol 'SomeProtocol' is not supported

2016-12-28 Thread Brandon Knope via swift-users 
Aren’t I losing the ability to enforce what is going into this enum’s 
associated value then?

Brandon

> On Dec 28, 2016, at 7:05 PM, Nevin Brackett-Rozinsky 
>  wrote:
> 
> It will work if you change the enum declaration to:
> 
> enum ElementNode
> 
> In other words, let the enum hold arbitrary unconstrained associated types, 
> and then make your APIs utilize instances of the enum with the associated 
> type constrained to a protocol.
> 
> The specific example you provide is essentially equivalent to:
> 
> var childElements = [Element?]()
> 
> Nevin
> 
> 
> On Wed, Dec 28, 2016 at 6:41 PM, Brandon Knope via swift-users 
> > wrote:
> I don’t understand why this is a problem
> 
> protocol Element {
> 
> }
> 
> enum ElementNode {
> case element(T)
> case empty
> }
> 
> var childElements = [ElementNode]()
> 
> I need to represent an array of my nodes that could be multiple kinds of 
> elements
> 
> Is there a workaround?
> 
> Brandon
> 
> ___
> 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] Using 'SomeProtocol' as a concrete type conforming to protocol 'SomeProtocol' is not supported

2016-12-28 Thread Nevin Brackett-Rozinsky via swift-users 
It will work if you change the enum declaration to:

enum ElementNode

In other words, let the enum hold arbitrary unconstrained associated types,
and then make your APIs utilize instances of the enum with the associated
type constrained to a protocol.

The specific example you provide is essentially equivalent to:

var childElements = [Element?]()

Nevin


On Wed, Dec 28, 2016 at 6:41 PM, Brandon Knope via swift-users <
swift-users@swift.org> wrote:

> I don’t understand why this is a problem
>
> protocol Element {
>
>
> }
>
> enum ElementNode {
> case element(T)
> case empty
> }
>
> var childElements = [ElementNode]()
>
> I need to represent an array of my nodes that could be multiple kinds of
> elements
>
> Is there a workaround?
>
> Brandon
>
> ___
> 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] Using 'SomeProtocol' as a concrete type conforming to protocol 'SomeProtocol' is not supported

2016-12-28 Thread Brandon Knope via swift-users 
I don’t understand why this is a problem

protocol Element {

}

enum ElementNode {
case element(T)
case empty
}

var childElements = [ElementNode]()

I need to represent an array of my nodes that could be multiple kinds of 
elements

Is there a workaround?

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

Re: [swift-users] System Modules and pkgConfig

2016-12-28 Thread Etan Kissling via swift-users 
Addition:

Example system module as I have it now:
https://github.com/Scriptreactor/SwiftCTLS

I'd like to get rid of the absolute path in the module.modulemap's "header" 
directive and have it instead use pkgConfig values.



> On 28 Dec 2016, at 17:12, Etan Kissling via swift-users 
>  wrote:
> 
> Hi,
> 
> before Swift 3, for System Modules to work, these steps were necessary:
> 1. Creating module map
> 2. Creating System Module package
> 3. Creating git repo for System Module package, tagging with version
> 4. Referencing the System Module package from main package
> 5. Adding -Xcc -I and -Xlinker -L flags to the swift build command.
> 
> The problem here is, that absolute system-depending paths are required at:
> - module map "header" entry.
> - Xcc -I flag when building.
> - Xlinker -L flag when building.
> 
> To solve this, Swift 3 introduced support for System Module search paths:
> https://github.com/apple/swift-evolution/blob/master/proposals/0063-swiftpm-system-module-search-paths.md
> 
> In my case, I end up with the following for the System Module package:
> 
> module CFoo [system] {
>  header "/system/depending/path/to/my/header.h"
>  link "foo"
>  export *
> }
> 
> 
> import PackageDescription
> 
> let package = Package(
>name: "CFoo",
>pkgConfig: "foo",
>providers: [
>.Brew("foo")
>]
> )
> 
> 
> With this setup, I can run
> PKG_CONFIG_PATH=/system/depending/path/to/my/pc/file swift build
> and build the project without specifying custom Xcc -I / Xlinker -L flags.
> 
> However, the absolute system-depending path is still required in the 
> modulemap.
> 
> When I change the module map to
> 
> module CFoo [system] {
>  header "header.h"
>  link "foo"
>  export *
> }
> 
> , I get build errors like
> 
> /module.modulemap:2:##: error: header 'header.h' not found
> 
> This is kind of different than what is suggested by the proposal (that it 
> should recommend installing via Brew / Apt in that case).
> 
> 
> ==> How do I need to set up the project so that system-depending paths are 
> required at no point?
> ==> Is there an example project available on github that demonstrates the 
> pkgConfig feature of SwiftPM?
> 
> 
> Thanks
> 
> Etan
> 
> 
> 
> ___
> 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] Confused/Surprised by IndexingIterator.forEach behavior

2016-12-28 Thread Guillaume Lessard via swift-users 
forEach is defined by the Sequence protocol, and is not a mutating function. By 
definition, it must create a local iterator in order to perform its duty. As a 
consequence, the variable `stream` is the same immediately before and after the 
forEach call.

Cheers,
Guillaume Lessard

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

Re: [swift-users] Confused/Surprised by IndexingIterator.forEach behavior

2016-12-28 Thread Ole Begemann via swift-users 

On 28/12/2016 19:57, Travis Griggs via swift-users wrote:

The behavior of the following playground snippet surprised me:

var source = [10, 20, 30, 40]
var stream = source.makeIterator()
stream.next()  // 10
stream.next()  // 20
stream.forEach { (each) in
print("\(each)")
}  // prints 30, 40 to the console
stream.next()  // 30
stream.next()  // 40
stream.next()  // nil

I can move the forEach statement up and down the stack there, and it *appears* 
that while it respects the the current position of the stream/iterator as a 
start point, it does not actually consume the elements (as next does). That 
seems inconsistent to me I guess. I would have expected the forEach to either 
pass through to the source and just ignore the current position, or to consume 
the items. Whereas the current behavior is kind of a hybrid.

Guess I’m just looking for some enlightenment as to why it was designed to work 
this way. I figure there’s some valuable insight here that I’m missing.


The IndexingIterator returned by `source.makeIterator()` is itself a 
`Sequence` (you couldn't call `forEach` if it weren't).


When you call `forEach` (which is implemented using a `for ... in` 
loop), you effectively call `stream.makeIterator()`, thus making a new 
iterator. The state of the original `stream` iterator isn't affected by 
this.


You can see more clearly what happens when you deconstruct the call to 
`forEach`, first into a for-in loop and then into a while loop (which is 
equivalent to the for-in loop). All three variants give the same result 
even if called sequentially on the same sequence, because a new iterator 
is created for each loop:


// ...
stream.next()  // 10
stream.next()  // 20
stream.forEach { (each) in
print("forEach \(each)")
}  // prints 30, 40 to the console

// for-in loop has the same effect
for element in stream {
print("for in \(element)")
} // prints 30, 40 to the console

// while loop has the same effect
// Here you can see that a new iterator is created.
var iter = stream.makeIterator()
while let element = iter.next() {
print("while \(element)")
}

stream.next()  // 30
stream.next()  // 40
stream.next()  // nil

(The result would be different if the sequence were _destructively 
consumed_, i.e. it can only be iterated over once -- which is allowed by 
the Sequence protocol).


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

[swift-users] Confused/Surprised by IndexingIterator.forEach behavior

2016-12-28 Thread Travis Griggs via swift-users 
The behavior of the following playground snippet surprised me:

var source = [10, 20, 30, 40]
var stream = source.makeIterator()
stream.next()  // 10
stream.next()  // 20
stream.forEach { (each) in
print("\(each)")
}  // prints 30, 40 to the console
stream.next()  // 30
stream.next()  // 40
stream.next()  // nil

I can move the forEach statement up and down the stack there, and it *appears* 
that while it respects the the current position of the stream/iterator as a 
start point, it does not actually consume the elements (as next does). That 
seems inconsistent to me I guess. I would have expected the forEach to either 
pass through to the source and just ignore the current position, or to consume 
the items. Whereas the current behavior is kind of a hybrid. 

Guess I’m just looking for some enlightenment as to why it was designed to work 
this way. I figure there’s some valuable insight here that I’m missing.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] System Modules and pkgConfig

2016-12-28 Thread Etan Kissling via swift-users 
Hi,

before Swift 3, for System Modules to work, these steps were necessary:
1. Creating module map
2. Creating System Module package
3. Creating git repo for System Module package, tagging with version
4. Referencing the System Module package from main package
5. Adding -Xcc -I and -Xlinker -L flags to the swift build command.

The problem here is, that absolute system-depending paths are required at:
- module map "header" entry.
- Xcc -I flag when building.
- Xlinker -L flag when building.

To solve this, Swift 3 introduced support for System Module search paths:
https://github.com/apple/swift-evolution/blob/master/proposals/0063-swiftpm-system-module-search-paths.md

In my case, I end up with the following for the System Module package:

module CFoo [system] {
  header "/system/depending/path/to/my/header.h"
  link "foo"
  export *
}


import PackageDescription

let package = Package(
name: "CFoo",
pkgConfig: "foo",
providers: [
.Brew("foo")
]
)


With this setup, I can run
PKG_CONFIG_PATH=/system/depending/path/to/my/pc/file swift build
and build the project without specifying custom Xcc -I / Xlinker -L flags.

However, the absolute system-depending path is still required in the modulemap.

When I change the module map to

module CFoo [system] {
  header "header.h"
  link "foo"
  export *
}

, I get build errors like

/module.modulemap:2:##: error: header 'header.h' not found

This is kind of different than what is suggested by the proposal (that it 
should recommend installing via Brew / Apt in that case).


==> How do I need to set up the project so that system-depending paths are 
required at no point?
==> Is there an example project available on github that demonstrates the 
pkgConfig feature of SwiftPM?


Thanks

Etan



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