Re: [swift-users] Communicating with dynamically loaded swift library

[Ján Kosa via swift-users]

I was afraid it will come to that :) I will try to make something tonight,
either it will help you fix it, or I will find out what I did wrong

On 8 October 2017 at 09:49, Daniel Dunbar  wrote:

> Is it possible for you to make a small test package that shows the
> problem, and file a bug in bugs.swift.org? There may be something we need
> to fix in SwiftPM before this can work (because of our linking model).
>
>  - Daniel
>
>
> On Oct 7, 2017, at 10:42 PM, Ján Kosa via swift-users <
> swift-users@swift.org> wrote:
>
> That is exactly what I did. The only package that depends on the protobuf
> is the PluginInterface. Both MyPlugin and and PluginConsumer depend on the
> PluginInterface and not on the protobuf itself. I had to shuffle around my
> dependencies a bit, which resulted in smaller number of dependencies but
> they don't make much sense now (as in, some target had to depend on
> PluginInterface even if they don't need to, just to get access to
> protobuf). I could live with that if it solved the issue, but it didn't.
>
> I am adding my Package.swift files in case I missed something:
>
> PluginInterface:
>
> ```swift
> let package = Package(
>
> name: "PluginInterface",
>
> products: [ .library(name: "PluginInterface", type: .dynamic, targets: [
> "PluginInterface"]) ],
>
> dependencies: [ .package(url: "https://github.com/apple/swift-protobuf.git
> ", from: "0.0.0") ],
>
> targets: [ .target(name: "PluginInterface", dependencies: ["SwiftProtobuf"])
> ]
>
> )```
>
>
> MyPlugin:
>
> ```swift
>
> let package = Package(
>
> name: "MyPlugin",
>
> products: [ .library(name: "MyPlugin", type: .dynamic, targets: [
> "PluginImpl"]) ],
>
> dependencies: [
>
> .package(url: "path/to/PluginInterface.git", from: "0.0.0"),
>
> ],
>
> targets: [
>
> .target(name: "PluginImpl", dependencies: ["ProtoBufMessages"]),
>
> .target(name: "ProtoBufMessages", dependencies: ["PluginInterface"])
>
> ]
>
> )```
>
>
> PluginConsumer:
>
> ```swift
>
> let package = Package(
>
> name: "PluginConsumer",
>
> dependencies: [
>
> .package(url: "https://github.com/PerfectlySoft/Perfect-WebSockets.git;,
> from: "3.0.0"),
>
> .package(url: "https://github.com/PerfectlySoft/Perfect-HTTPServer.git;,
> from: "3.0.0"),
>
> .package(url: "path/to/PluginInterface", from: "0.0.0"),
>
> .package(url: "https://github.com/krzyzanowskim/CryptoSwift.git;, from:
> "0.0.0")
>
> ],
>
> targets: [
>
> .target(name: "AppMaster", dependencies: ["Shared", "CryptoSwift"]),
>
> .target(name: "PluginConsumer", dependencies: ["Shared", "CryptoSwift"]),
>
> .target(name: "Shared", dependencies: ["ProtoBufMessages",
> "PerfectHTTPServer", "PerfectWebSockets"]),
>
> .target(name: "ProtoBufMessages", dependencies: ["PluginInterface"])
>
> ]
>
> )```
>
>
> App master is separate executable that shares some functionality with
> PluginConsumer, but it doesn't link against it in any way. I guess it could
> be omitted, but I wanted to give you whole thing as it is
>
> On 7 October 2017 at 18:33, Geordie Jay  wrote:
>
>>
>> Ján Kosa  schrieb am Sa. 7. Okt. 2017 um 15:27:
>>
>>> I tried to use @_exported and it helped somewhat. While I still have
>>> same warnings, size of the PluginInterface library went down by 6mb (to
>>> 120kb) so it looks like Protobuf is no longer statically linked to it.
>>> However, size of PluginConsumer executable went up by same 6mb, it looks
>>> like it is linked there twice now.
>>>
>>
>> To be clear: take protobuf out of the PluginConsumer dependencies.
>> Actually, I’m not sure which is which, but protobuf should only be listed
>> as a dependency of one package, where it is imported as @_exported. After
>> that, your other modules depend on the package that imports / exports
>> protobuf.
>>
>> I also noticed interesting thing. If I build executable using `swift
>>> build` the size is around 17mb, when I generate xcode project and build it
>>> using that, size is around 200kb, but I get same warnings using both
>>> approaches
>>>
>>> On 7 October 2017 at 15:44, Geordie Jay  wrote:
>>>

 Ján Kosa  schrieb am Sa. 7. Okt. 2017 um 13:34:

> I tried swift package clean, but it didn't help
>
> "Try to ensure the plugin provider module (libA) is (only) being
> compiled into its standalone shared library file."
> How do I go about this? It is 3rd party module, it doesn't define any
> products (https://github.com/apple/swift-protobuf.git). Is there
> something I can do in my Package files to make sure it is loaded
> dynamically?
>

 When you compile a package depending on protobuf, all the relevant
 symbols end up in your package’s library file. So here’s something you
 might try:

 import protobuf into your own “PluginProvider” module (package), which
 has a shared library product like this: ‘@_exported import Protobuf’ in
 some compiled swift file. Then from the other 

Re: [swift-users] Communicating with dynamically loaded swift library

[Daniel Dunbar via swift-users]

Is it possible for you to make a small test package that shows the problem, and 
file a bug in bugs.swift.org? There may be something we need to fix in SwiftPM 
before this can work (because of our linking model).

 - Daniel

> On Oct 7, 2017, at 10:42 PM, Ján Kosa via swift-users  
> wrote:
> 
> That is exactly what I did. The only package that depends on the protobuf is 
> the PluginInterface. Both MyPlugin and and PluginConsumer depend on the 
> PluginInterface and not on the protobuf itself. I had to shuffle around my 
> dependencies a bit, which resulted in smaller number of dependencies but they 
> don't make much sense now (as in, some target had to depend on 
> PluginInterface even if they don't need to, just to get access to protobuf). 
> I could live with that if it solved the issue, but it didn't.
> 
> I am adding my Package.swift files in case I missed something:
> 
> PluginInterface:
> 
> ```swift
> let package = Package(
> name: "PluginInterface",
> 
> products: [ .library(name: "PluginInterface", type: .dynamic, targets: 
> ["PluginInterface"]) ],
> 
> dependencies: [ .package(url: "https://github.com/apple/swift-protobuf.git 
> ", from: "0.0.0") ],
> 
> targets: [ .target(name: "PluginInterface", dependencies: ["SwiftProtobuf"]) ]
> 
> )```
> 
> 
> 
> MyPlugin:
> 
> ```swift
> 
> let package = Package(
> 
> name: "MyPlugin",
> 
> products: [ .library(name: "MyPlugin", type: .dynamic, targets: 
> ["PluginImpl"]) ],
> 
> dependencies: [
> 
> .package(url: "path/to/PluginInterface.git", from: "0.0.0"),
> 
> ],
> 
> targets: [
> 
> .target(name: "PluginImpl", dependencies: ["ProtoBufMessages"]),
> 
> .target(name: "ProtoBufMessages", dependencies: ["PluginInterface"])
> 
> ]
> 
> 
> )```
> 
> 
> 
> PluginConsumer:
> 
> ```swift
> 
> let package = Package(
> 
> name: "PluginConsumer",
> 
> dependencies: [
> 
> .package(url: "https://github.com/PerfectlySoft/Perfect-WebSockets.git 
> ", from: "3.0.0"),
> 
> .package(url: "https://github.com/PerfectlySoft/Perfect-HTTPServer.git 
> ", from: "3.0.0"),
> 
> .package(url: "path/to/PluginInterface", from: "0.0.0"),
> 
> .package(url: "https://github.com/krzyzanowskim/CryptoSwift.git 
> ", from: "0.0.0")
> 
> ],
> 
> targets: [
> 
> .target(name: "AppMaster", dependencies: ["Shared", "CryptoSwift"]),
> 
> .target(name: "PluginConsumer", dependencies: ["Shared", "CryptoSwift"]),
> 
> .target(name: "Shared", dependencies: ["ProtoBufMessages", 
> "PerfectHTTPServer", "PerfectWebSockets"]),
> 
> .target(name: "ProtoBufMessages", dependencies: ["PluginInterface"])
> 
> ]
> 
> 
> )```
> 
> 
> 
> App master is separate executable that shares some functionality with 
> PluginConsumer, but it doesn't link against it in any way. I guess it could 
> be omitted, but I wanted to give you whole thing as it is
> 
> 
> On 7 October 2017 at 18:33, Geordie Jay  > wrote:
> 
> Ján Kosa > schrieb am Sa. 7. 
> Okt. 2017 um 15:27:
> I tried to use @_exported and it helped somewhat. While I still have same 
> warnings, size of the PluginInterface library went down by 6mb (to 120kb) so 
> it looks like Protobuf is no longer statically linked to it. However, size of 
> PluginConsumer executable went up by same 6mb, it looks like it is linked 
> there twice now. 
> 
> To be clear: take protobuf out of the PluginConsumer dependencies. Actually, 
> I’m not sure which is which, but protobuf should only be listed as a 
> dependency of one package, where it is imported as @_exported. After that, 
> your other modules depend on the package that imports / exports protobuf.
> 
> I also noticed interesting thing. If I build executable using `swift build` 
> the size is around 17mb, when I generate xcode project and build it using 
> that, size is around 200kb, but I get same warnings using both approaches
> 
> On 7 October 2017 at 15:44, Geordie Jay  > wrote:
> 
> Ján Kosa > schrieb am Sa. 7. 
> Okt. 2017 um 13:34:
> I tried swift package clean, but it didn't help
> 
> "Try to ensure the plugin provider module (libA) is (only) being compiled 
> into its standalone shared library file." 
> How do I go about this? It is 3rd party module, it doesn't define any 
> products (https://github.com/apple/swift-protobuf.git 
> ). Is there something I can do 
> in my Package files to make sure it is loaded dynamically?
> 
> When you compile a package depending on protobuf, all the relevant symbols 
> end up in your package’s library file. So here’s something you might try:
> 
> import protobuf into your own “PluginProvider” module (package), which has 

Re: [swift-users] Communicating with dynamically loaded swift library

[Ján Kosa via swift-users]

That is exactly what I did. The only package that depends on the protobuf
is the PluginInterface. Both MyPlugin and and PluginConsumer depend on the
PluginInterface and not on the protobuf itself. I had to shuffle around my
dependencies a bit, which resulted in smaller number of dependencies but
they don't make much sense now (as in, some target had to depend on
PluginInterface even if they don't need to, just to get access to
protobuf). I could live with that if it solved the issue, but it didn't.

I am adding my Package.swift files in case I missed something:

PluginInterface:

```swift
let package = Package(

name: "PluginInterface",

products: [ .library(name: "PluginInterface", type: .dynamic, targets: [
"PluginInterface"]) ],

dependencies: [ .package(url: "https://github.com/apple/swift-protobuf.git;,
from: "0.0.0") ],

targets: [ .target(name: "PluginInterface", dependencies: ["SwiftProtobuf"])
]

)```


MyPlugin:

```swift

let package = Package(

name: "MyPlugin",

products: [ .library(name: "MyPlugin", type: .dynamic, targets: [
"PluginImpl"]) ],

dependencies: [

.package(url: "path/to/PluginInterface.git", from: "0.0.0"),

],

targets: [

.target(name: "PluginImpl", dependencies: ["ProtoBufMessages"]),

.target(name: "ProtoBufMessages", dependencies: ["PluginInterface"])

]

)```


PluginConsumer:

```swift

let package = Package(

name: "PluginConsumer",

dependencies: [

.package(url: "https://github.com/PerfectlySoft/Perfect-WebSockets.git;,
from: "3.0.0"),

.package(url: "https://github.com/PerfectlySoft/Perfect-HTTPServer.git;,
from: "3.0.0"),

.package(url: "path/to/PluginInterface", from: "0.0.0"),

.package(url: "https://github.com/krzyzanowskim/CryptoSwift.git;, from:
"0.0.0")

],

targets: [

.target(name: "AppMaster", dependencies: ["Shared", "CryptoSwift"]),

.target(name: "PluginConsumer", dependencies: ["Shared", "CryptoSwift"]),

.target(name: "Shared", dependencies: ["ProtoBufMessages",
"PerfectHTTPServer", "PerfectWebSockets"]),

.target(name: "ProtoBufMessages", dependencies: ["PluginInterface"])

]

)```


App master is separate executable that shares some functionality with
PluginConsumer, but it doesn't link against it in any way. I guess it could
be omitted, but I wanted to give you whole thing as it is

On 7 October 2017 at 18:33, Geordie Jay  wrote:

>
> Ján Kosa  schrieb am Sa. 7. Okt. 2017 um 15:27:
>
>> I tried to use @_exported and it helped somewhat. While I still have
>> same warnings, size of the PluginInterface library went down by 6mb (to
>> 120kb) so it looks like Protobuf is no longer statically linked to it.
>> However, size of PluginConsumer executable went up by same 6mb, it looks
>> like it is linked there twice now.
>>
>
> To be clear: take protobuf out of the PluginConsumer dependencies.
> Actually, I’m not sure which is which, but protobuf should only be listed
> as a dependency of one package, where it is imported as @_exported. After
> that, your other modules depend on the package that imports / exports
> protobuf.
>
> I also noticed interesting thing. If I build executable using `swift
>> build` the size is around 17mb, when I generate xcode project and build it
>> using that, size is around 200kb, but I get same warnings using both
>> approaches
>>
>> On 7 October 2017 at 15:44, Geordie Jay  wrote:
>>
>>>
>>> Ján Kosa  schrieb am Sa. 7. Okt. 2017 um 13:34:
>>>
 I tried swift package clean, but it didn't help

 "Try to ensure the plugin provider module (libA) is (only) being
 compiled into its standalone shared library file."
 How do I go about this? It is 3rd party module, it doesn't define any
 products (https://github.com/apple/swift-protobuf.git). Is there
 something I can do in my Package files to make sure it is loaded
 dynamically?

>>>
>>> When you compile a package depending on protobuf, all the relevant
>>> symbols end up in your package’s library file. So here’s something you
>>> might try:
>>>
>>> import protobuf into your own “PluginProvider” module (package), which
>>> has a shared library product like this: ‘@_exported import Protobuf’ in
>>> some compiled swift file. Then from the other dependent modules “import
>>> PluginProvider” - the protobuf symbols should be available, and all from
>>> one (nonconflicting) source.
>>>
>>> Geordie
>>>
>>>
>>>
 On 6 October 2017 at 22:52, Geordie Jay  wrote:

> I think SwiftPM is (incorrectly) compiling A.XYZ into each of the
> modules that depend on it, as well as into your intended libA.so file.
>
> Try to ensure the plugin provider module (libA) is (only) being
> compiled into its standalone shared library file. Try cleaning the swiftpm
> build for one (swift package clean) and ensure the Package.swift files are
> correctly set up to output the shared library.
>
> Sorry I can’t be more specific, I’ve had these same kinds 

[swift-users] Hacking the swift compiler to use the llvm wasm target

[Fabio Kaminski via swift-users]

Hello,

I was playing a liitle bit with the Swift compiler to it could use the
WebAssembly LLVM backend, the same way Clang already do it right now.

Well, i've implemented the toolchain ok, but now its asking me for a
Sdk for the new toolchain.

My question is: How can i create a new runtime for this custom
toolchain i've created in a way the compiler understand is it there?

Of course i can spend more time hacking and findind that out.. but
maybe someone could give me some tips and spare me some trouble?

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

Re: [swift-users] Swift 4.0 LLDBFrontend Crash

[Edward Connell via swift-users]

Hi Michael,
No I am not evaluating an expression or anything. This all worked fine in
past builds.

I simply set a breakpoint in a function and after stopping while gathering
values for the debugger view, it crashes.

It doesn't crash in all functions, but it does crash when trying to stop in
many different functions.
An example function signature where it crashes is (DataView is a concrete
struct):

public func setupForward(mode: EvaluationMode, inData: DataView, labels:
DataView?,
 outData: inout DataView, backData: inout
DataView?) throws { ... }

Before calling the function, all of the parameters have valid values that I
can examine. But as soon as I step into this function, LLDB crashes with
that message. It behaves the same way with other functions that have
different signatures.

I tried to create a very simple repro case using this signature, but it
didn't crash. My project is on GitHub and this can be easily reproduced.
The only pain is installing my project on your test machine.

Ubuntu 16.04
Swift 4.0 release
NVidia gpu
Netlib https://github.com/ewconnell/Netlib/wiki#installation
CLion IDE with Swift plugin

1) do a debug build
2) set a breakpoint at CudaSoftmax.swift:44  or any line in the function
3) run
4) when it stops LLDBFrontend crashes

*LLDBFrontend:
/home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp:613:
(anonymous namespace)::SourceAccess (anonymous
namespace)::AccessEnforcementSelection::getSourceAccess(swift::SILValue):
Assertion `isa(address) || isa(address)' failed.*
*Stack dump:*
*0. While running pass #10 SILModuleTransform ""Access Enforcement
Selection"".*


Using the LLDB CLI I am able to stop there. If I try "fr var -O" with

   - mode, inData, and labels, it prints their values no problem
   - outData and backData gives me a segmentation violation

The visible difference is the "inout"

Not sure what the problem is. It worked fine in the past.

If you can think of an experiment I can try to create a simple repro case,
please let me know.

Thanks, Ed

On Fri, Oct 6, 2017 at 4:34 PM, Michael Gottesman 
wrote:

> It looks like this is failing during guaranteed optimization. Are you
> running an expression in the debugger and we are crashing there?
>
> Michael
>
> On Oct 6, 2017, at 11:53 AM, Edward Connell via swift-users <
> swift-users@swift.org> wrote:
>
> While trying to debug a Netlib function, LLDB is crashing
>
> I'm not sure what this assert means.
>
> *LLDBFrontend:
> /home/buildnode/jenkins/workspace/oss-swift-4.0-package-linux-ubuntu-16_04/swift/lib/SILOptimizer/Mandatory/AccessEnforcementSelection.cpp:613:
> (anonymous namespace)::SourceAccess (anonymous
> namespace)::AccessEnforcementSelection::getSourceAccess(swift::SILValue):
> Assertion `isa(address) || isa(address)' failed.*
> *Stack dump:*
> *0. While running pass #10 SILModuleTransform ""Access Enforcement
> Selection"".*
>
> It fails every time and the same way in several functions, but not all
> functions.
> I tried to create a simple repro with the same function signature, but I
> can't get the simple case to fail.
> A debug build isn't doing whole-module-optimization, so that's not it
>
> Ideas anyone?
>
> Who owns the LLDBFrontend?
>
> Thanks, Ed
> ___
> 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 libdispatch with Trunk Development snapshot

[Lane Schwartz via swift-users]

Bizarre. And 10/5 is no longer available for download.

$ wget
> https://swift.org/builds/development/ubuntu1604/swift-DEVELOPMENT-SNAPSHOT-2017-10-05-a/swift-DEVELOPMENT-SNAPSHOT-2017-10-05-a-ubuntu16.04.tar.gz
> --2017-10-07 11:49:56--
> https://swift.org/builds/development/ubuntu1604/swift-DEVELOPMENT-SNAPSHOT-2017-10-05-a/swift-DEVELOPMENT-SNAPSHOT-2017-10-05-a-ubuntu16.04.tar.gz
> Resolving swift.org (swift.org)... 169.47.73.10
> Connecting to swift.org (swift.org)|169.47.73.10|:443... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 2017-10-07 11:49:56 ERROR 404: Not Found.


On Sat, Oct 7, 2017 at 11:53 AM, Edward Connell  wrote:

> $ find ~/swift -name "*dispatch*"
> /home/ed/swift/usr/lib/swift/linux/libdispatch.la
> /home/ed/swift/usr/lib/swift/linux/libdispatch.so
> /home/ed/swift/usr/lib/swift/dispatch
> /home/ed/swift/usr/lib/swift/dispatch/dispatch.h
>
>
> On Sat, Oct 7, 2017 at 9:51 AM, Lane Schwartz  wrote:
>
>> Edward,
>>
>> Could you please try running this command wherever your
>> swift-DEVELOPMENT* directory is located?
>>
>> find swift-DEVELOPMENT-SNAPSHOT-* -name "*dispatch*"
>>
>> Thanks,
>> Lane
>>
>>
>>
>>
>> On Sat, Oct 7, 2017 at 11:47 AM, Edward Connell 
>> wrote:
>>
>>> No I installed it yesterday so 10/5 was the current one
>>>
>>> On Sat, Oct 7, 2017 at 9:36 AM, Lane Schwartz 
>>> wrote:
>>>
 Do you mean 10/6? I don't see a 10/5 build.

 On Sat, Oct 7, 2017 at 11:26 AM, Edward Connell 
 wrote:

> I had the same problem with the 9/30 build, but the 10/5 build worked
> for me.
>
> On Sat, Oct 7, 2017 at 9:21 AM, Alex Blewitt via swift-users <
> swift-users@swift.org> wrote:
>
>> This sounds like a bug. There were some changes recently to migrate
>> the build towards CMake and it may be that they have broken the build
>> accordingly.
>>
>> Since I can't find one, can you create a bug at
>> https://bugs.swift.org with the snapshot build that you saw the
>> issue is?
>>
>> Alex
>>
>> > On 7 Oct 2017, at 17:08, Lane Schwartz via swift-users <
>> swift-users@swift.org> wrote:
>> >
>> > Hi,
>> >
>> > I'm on Ubuntu 16, and I'd like to try out the current Trunk
>> Development snapshot. I successfully downloaded and installed it. But 
>> when
>> I tried compiling my sample program with it, I got an error that
>> libdispatch wasn't available.
>> >
>> > I looked in the directory, and sure enough, the development
>> snapshots do not appear to include libdispatch. Is this intentional? What
>> is the recommended mechanism for getting libdispatch when using the Trunk
>> Development snapshots?
>> >
>> > Thanks,
>> > Lane
>> >
>> > ___
>> > 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
>>
>
>


 --
 When a place gets crowded enough to require ID's, social collapse is not
 far away.  It is time to go elsewhere.  The best thing about space
 travel
 is that it made it possible to go elsewhere.
 -- R.A. Heinlein, "Time Enough For Love"

>>>
>>>
>>
>>
>> --
>> When a place gets crowded enough to require ID's, social collapse is not
>> far away.  It is time to go elsewhere.  The best thing about space travel
>> is that it made it possible to go elsewhere.
>> -- R.A. Heinlein, "Time Enough For Love"
>>
>
>


-- 
When a place gets crowded enough to require ID's, social collapse is not
far away.  It is time to go elsewhere.  The best thing about space travel
is that it made it possible to go elsewhere.
-- R.A. Heinlein, "Time Enough For Love"
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Using libdispatch with Trunk Development snapshot

[Edward Connell via swift-users]

$ find ~/swift -name "*dispatch*"
/home/ed/swift/usr/lib/swift/linux/libdispatch.la
/home/ed/swift/usr/lib/swift/linux/libdispatch.so
/home/ed/swift/usr/lib/swift/dispatch
/home/ed/swift/usr/lib/swift/dispatch/dispatch.h


On Sat, Oct 7, 2017 at 9:51 AM, Lane Schwartz  wrote:

> Edward,
>
> Could you please try running this command wherever your swift-DEVELOPMENT*
> directory is located?
>
> find swift-DEVELOPMENT-SNAPSHOT-* -name "*dispatch*"
>
> Thanks,
> Lane
>
>
>
>
> On Sat, Oct 7, 2017 at 11:47 AM, Edward Connell 
> wrote:
>
>> No I installed it yesterday so 10/5 was the current one
>>
>> On Sat, Oct 7, 2017 at 9:36 AM, Lane Schwartz  wrote:
>>
>>> Do you mean 10/6? I don't see a 10/5 build.
>>>
>>> On Sat, Oct 7, 2017 at 11:26 AM, Edward Connell 
>>> wrote:
>>>
 I had the same problem with the 9/30 build, but the 10/5 build worked
 for me.

 On Sat, Oct 7, 2017 at 9:21 AM, Alex Blewitt via swift-users <
 swift-users@swift.org> wrote:

> This sounds like a bug. There were some changes recently to migrate
> the build towards CMake and it may be that they have broken the build
> accordingly.
>
> Since I can't find one, can you create a bug at https://bugs.swift.org
> with the snapshot build that you saw the issue is?
>
> Alex
>
> > On 7 Oct 2017, at 17:08, Lane Schwartz via swift-users <
> swift-users@swift.org> wrote:
> >
> > Hi,
> >
> > I'm on Ubuntu 16, and I'd like to try out the current Trunk
> Development snapshot. I successfully downloaded and installed it. But when
> I tried compiling my sample program with it, I got an error that
> libdispatch wasn't available.
> >
> > I looked in the directory, and sure enough, the development
> snapshots do not appear to include libdispatch. Is this intentional? What
> is the recommended mechanism for getting libdispatch when using the Trunk
> Development snapshots?
> >
> > Thanks,
> > Lane
> >
> > ___
> > 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
>


>>>
>>>
>>> --
>>> When a place gets crowded enough to require ID's, social collapse is not
>>> far away.  It is time to go elsewhere.  The best thing about space travel
>>> is that it made it possible to go elsewhere.
>>> -- R.A. Heinlein, "Time Enough For Love"
>>>
>>
>>
>
>
> --
> When a place gets crowded enough to require ID's, social collapse is not
> far away.  It is time to go elsewhere.  The best thing about space travel
> is that it made it possible to go elsewhere.
> -- R.A. Heinlein, "Time Enough For Love"
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Using libdispatch with Trunk Development snapshot

[Lane Schwartz via swift-users]

Edward,

Could you please try running this command wherever your swift-DEVELOPMENT*
directory is located?

find swift-DEVELOPMENT-SNAPSHOT-* -name "*dispatch*"

Thanks,
Lane




On Sat, Oct 7, 2017 at 11:47 AM, Edward Connell  wrote:

> No I installed it yesterday so 10/5 was the current one
>
> On Sat, Oct 7, 2017 at 9:36 AM, Lane Schwartz  wrote:
>
>> Do you mean 10/6? I don't see a 10/5 build.
>>
>> On Sat, Oct 7, 2017 at 11:26 AM, Edward Connell 
>> wrote:
>>
>>> I had the same problem with the 9/30 build, but the 10/5 build worked
>>> for me.
>>>
>>> On Sat, Oct 7, 2017 at 9:21 AM, Alex Blewitt via swift-users <
>>> swift-users@swift.org> wrote:
>>>
 This sounds like a bug. There were some changes recently to migrate the
 build towards CMake and it may be that they have broken the build
 accordingly.

 Since I can't find one, can you create a bug at https://bugs.swift.org
 with the snapshot build that you saw the issue is?

 Alex

 > On 7 Oct 2017, at 17:08, Lane Schwartz via swift-users <
 swift-users@swift.org> wrote:
 >
 > Hi,
 >
 > I'm on Ubuntu 16, and I'd like to try out the current Trunk
 Development snapshot. I successfully downloaded and installed it. But when
 I tried compiling my sample program with it, I got an error that
 libdispatch wasn't available.
 >
 > I looked in the directory, and sure enough, the development snapshots
 do not appear to include libdispatch. Is this intentional? What is the
 recommended mechanism for getting libdispatch when using the Trunk
 Development snapshots?
 >
 > Thanks,
 > Lane
 >
 > ___
 > 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

>>>
>>>
>>
>>
>> --
>> When a place gets crowded enough to require ID's, social collapse is not
>> far away.  It is time to go elsewhere.  The best thing about space travel
>> is that it made it possible to go elsewhere.
>> -- R.A. Heinlein, "Time Enough For Love"
>>
>
>


-- 
When a place gets crowded enough to require ID's, social collapse is not
far away.  It is time to go elsewhere.  The best thing about space travel
is that it made it possible to go elsewhere.
-- R.A. Heinlein, "Time Enough For Love"
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Using libdispatch with Trunk Development snapshot

[Lane Schwartz via swift-users]

Strange. 10/5 is not available to download. And the 10/6 release doesn't
have libdispatch.

On Sat, Oct 7, 2017 at 11:47 AM, Edward Connell  wrote:

> No I installed it yesterday so 10/5 was the current one
>
> On Sat, Oct 7, 2017 at 9:36 AM, Lane Schwartz  wrote:
>
>> Do you mean 10/6? I don't see a 10/5 build.
>>
>> On Sat, Oct 7, 2017 at 11:26 AM, Edward Connell 
>> wrote:
>>
>>> I had the same problem with the 9/30 build, but the 10/5 build worked
>>> for me.
>>>
>>> On Sat, Oct 7, 2017 at 9:21 AM, Alex Blewitt via swift-users <
>>> swift-users@swift.org> wrote:
>>>
 This sounds like a bug. There were some changes recently to migrate the
 build towards CMake and it may be that they have broken the build
 accordingly.

 Since I can't find one, can you create a bug at https://bugs.swift.org
 with the snapshot build that you saw the issue is?

 Alex

 > On 7 Oct 2017, at 17:08, Lane Schwartz via swift-users <
 swift-users@swift.org> wrote:
 >
 > Hi,
 >
 > I'm on Ubuntu 16, and I'd like to try out the current Trunk
 Development snapshot. I successfully downloaded and installed it. But when
 I tried compiling my sample program with it, I got an error that
 libdispatch wasn't available.
 >
 > I looked in the directory, and sure enough, the development snapshots
 do not appear to include libdispatch. Is this intentional? What is the
 recommended mechanism for getting libdispatch when using the Trunk
 Development snapshots?
 >
 > Thanks,
 > Lane
 >
 > ___
 > 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

>>>
>>>
>>
>>
>> --
>> When a place gets crowded enough to require ID's, social collapse is not
>> far away.  It is time to go elsewhere.  The best thing about space travel
>> is that it made it possible to go elsewhere.
>> -- R.A. Heinlein, "Time Enough For Love"
>>
>
>


-- 
When a place gets crowded enough to require ID's, social collapse is not
far away.  It is time to go elsewhere.  The best thing about space travel
is that it made it possible to go elsewhere.
-- R.A. Heinlein, "Time Enough For Love"
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Using libdispatch with Trunk Development snapshot

[Edward Connell via swift-users]

No I installed it yesterday so 10/5 was the current one

On Sat, Oct 7, 2017 at 9:36 AM, Lane Schwartz  wrote:

> Do you mean 10/6? I don't see a 10/5 build.
>
> On Sat, Oct 7, 2017 at 11:26 AM, Edward Connell 
> wrote:
>
>> I had the same problem with the 9/30 build, but the 10/5 build worked for
>> me.
>>
>> On Sat, Oct 7, 2017 at 9:21 AM, Alex Blewitt via swift-users <
>> swift-users@swift.org> wrote:
>>
>>> This sounds like a bug. There were some changes recently to migrate the
>>> build towards CMake and it may be that they have broken the build
>>> accordingly.
>>>
>>> Since I can't find one, can you create a bug at https://bugs.swift.org
>>> with the snapshot build that you saw the issue is?
>>>
>>> Alex
>>>
>>> > On 7 Oct 2017, at 17:08, Lane Schwartz via swift-users <
>>> swift-users@swift.org> wrote:
>>> >
>>> > Hi,
>>> >
>>> > I'm on Ubuntu 16, and I'd like to try out the current Trunk
>>> Development snapshot. I successfully downloaded and installed it. But when
>>> I tried compiling my sample program with it, I got an error that
>>> libdispatch wasn't available.
>>> >
>>> > I looked in the directory, and sure enough, the development snapshots
>>> do not appear to include libdispatch. Is this intentional? What is the
>>> recommended mechanism for getting libdispatch when using the Trunk
>>> Development snapshots?
>>> >
>>> > Thanks,
>>> > Lane
>>> >
>>> > ___
>>> > 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
>>>
>>
>>
>
>
> --
> When a place gets crowded enough to require ID's, social collapse is not
> far away.  It is time to go elsewhere.  The best thing about space travel
> is that it made it possible to go elsewhere.
> -- R.A. Heinlein, "Time Enough For Love"
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Using libdispatch with Trunk Development snapshot

[Edward Connell via swift-users]

I had the same problem with the 9/30 build, but the 10/5 build worked for
me.

On Sat, Oct 7, 2017 at 9:21 AM, Alex Blewitt via swift-users <
swift-users@swift.org> wrote:

> This sounds like a bug. There were some changes recently to migrate the
> build towards CMake and it may be that they have broken the build
> accordingly.
>
> Since I can't find one, can you create a bug at https://bugs.swift.org
> with the snapshot build that you saw the issue is?
>
> Alex
>
> > On 7 Oct 2017, at 17:08, Lane Schwartz via swift-users <
> swift-users@swift.org> wrote:
> >
> > Hi,
> >
> > I'm on Ubuntu 16, and I'd like to try out the current Trunk Development
> snapshot. I successfully downloaded and installed it. But when I tried
> compiling my sample program with it, I got an error that libdispatch wasn't
> available.
> >
> > I looked in the directory, and sure enough, the development snapshots do
> not appear to include libdispatch. Is this intentional? What is the
> recommended mechanism for getting libdispatch when using the Trunk
> Development snapshots?
> >
> > Thanks,
> > Lane
> >
> > ___
> > 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 libdispatch with Trunk Development snapshot

[Alex Blewitt via swift-users]

This sounds like a bug. There were some changes recently to migrate the build 
towards CMake and it may be that they have broken the build accordingly.

Since I can't find one, can you create a bug at https://bugs.swift.org with the 
snapshot build that you saw the issue is?

Alex

> On 7 Oct 2017, at 17:08, Lane Schwartz via swift-users 
>  wrote:
> 
> Hi,
> 
> I'm on Ubuntu 16, and I'd like to try out the current Trunk Development 
> snapshot. I successfully downloaded and installed it. But when I tried 
> compiling my sample program with it, I got an error that libdispatch wasn't 
> available. 
> 
> I looked in the directory, and sure enough, the development snapshots do not 
> appear to include libdispatch. Is this intentional? What is the recommended 
> mechanism for getting libdispatch when using the Trunk Development snapshots?
> 
> Thanks,
> Lane
> 
> ___
> 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 libdispatch with Trunk Development snapshot

[Lane Schwartz via swift-users]

Hi,

I'm on Ubuntu 16, and I'd like to try out the current Trunk Development
snapshot. I successfully downloaded and installed it. But when I tried
compiling my sample program with it, I got an error that libdispatch wasn't
available.

I looked in the directory, and sure enough, the development snapshots do
not appear to include libdispatch. Is this intentional? What is the
recommended mechanism for getting libdispatch when using the Trunk
Development snapshots?

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

Re: [swift-users] Communicating with dynamically loaded swift library

[Ján Kosa via swift-users]

I tried to use @_exported and it helped somewhat. While I still have same
warnings, size of the PluginInterface library went down by 6mb (to 120kb)
so it looks like Protobuf is no longer statically linked to it. However,
size of PluginConsumer executable went up by same 6mb, it looks like it is
linked there twice now.
I also noticed interesting thing. If I build executable using `swift build`
the size is around 17mb, when I generate xcode project and build it using
that, size is around 200kb, but I get same warnings using both approaches

On 7 October 2017 at 15:44, Geordie Jay  wrote:

>
> Ján Kosa  schrieb am Sa. 7. Okt. 2017 um 13:34:
>
>> I tried swift package clean, but it didn't help
>>
>> "Try to ensure the plugin provider module (libA) is (only) being
>> compiled into its standalone shared library file."
>> How do I go about this? It is 3rd party module, it doesn't define any
>> products (https://github.com/apple/swift-protobuf.git). Is there
>> something I can do in my Package files to make sure it is loaded
>> dynamically?
>>
>
> When you compile a package depending on protobuf, all the relevant symbols
> end up in your package’s library file. So here’s something you might try:
>
> import protobuf into your own “PluginProvider” module (package), which has
> a shared library product like this: ‘@_exported import Protobuf’ in some
> compiled swift file. Then from the other dependent modules “import
> PluginProvider” - the protobuf symbols should be available, and all from
> one (nonconflicting) source.
>
> Geordie
>
>
>
>> On 6 October 2017 at 22:52, Geordie Jay  wrote:
>>
>>> I think SwiftPM is (incorrectly) compiling A.XYZ into each of the
>>> modules that depend on it, as well as into your intended libA.so file.
>>>
>>> Try to ensure the plugin provider module (libA) is (only) being compiled
>>> into its standalone shared library file. Try cleaning the swiftpm build for
>>> one (swift package clean) and ensure the Package.swift files are correctly
>>> set up to output the shared library.
>>>
>>> Sorry I can’t be more specific, I’ve had these same kinds of issues
>>> before but I’m not 100% what they were.
>>>
>>> Geordie
>>>
>>>
>>> Ján Kosa via swift-users  schrieb am Fr. 6. Okt.
>>> 2017 um 14:41:
>>>
 It worked! Took me a while to iron out details, but it is working now.
 Huge thanks sir, I will name my firstborn after you.
 Thanks for the @_cdecl("initializePlugin") tip as well, I didn't know
 about it and it will be very useful.

 I am having slightly related problem now (it was there before, but I
 ignored it for the time being), not sure if I should start a new thread?

 The PluginInterface module has one external dependency on module A,
 PluginConsumer has the dependency on module B which has dependency on same
 module A that the PluginInterface uses. When I load the plugin library, I
 get bunch of errors like:

 Class A.XYZ is implemented in both libPluginInterface.dylib and
 libMyPlugin.dylib

 I know why it is there, but I don't know how to get rid of it. I can't
 just remove dependency from PluginConsumer and use the one from
 PluginInterface (if that would even work?) because PluginConsumer does not
 depend on it directly, but it is going through module B first

 Cheers,
 Lope

 On 4 October 2017 at 22:17, Daniel Dunbar 
 wrote:

> The way that I have done this in the past is pass a protocol as an
> unsafe pointer to an exposed entry point:
> ```swift
> let entryPoint = dlsym(handle, “initializePlugin”)
> guard entryPoint != nil else {
> fatalError("missing plugin entry point: \(pluginPath)")
> }
> typealias PluginInitializationFunc = @convention(c)
> (UnsafeRawPointer) -> ()
> let f = unsafeBitCast(entryPoint, to:
> PluginInitializationFunc.self)
> f(Unmanaged.passUnretained(self).toOpaque())
> ```
>
> and then in the plugin convert back to the appropriate type:
>
> ```
> @_cdecl("initializePlugin")
> public func initializePlugin(_ ptr: UnsafeRawPointer) {
> let manager = Unmanaged.fromOpaque(ptr).
> takeUnretainedValue()
> ```
>
> HTH,
>  - Daniel
>
> On Oct 4, 2017, at 11:02 AM, Ján Kosa via swift-users <
> swift-users@swift.org> wrote:
>
> Hello folks,
>
> I have been toying with dynamic libraries, trying to implement plugin
> functionality. I was able to get to the point where I can call simple
> function in loaded library, but I am having troubles starting more
> sophisticated communication channel.
>
> There are 3 projects
> - PluginConsumer is an app that loads plugin libraries
> - MyPlugin is a plugin implementation, 

Re: [swift-users] Communicating with dynamically loaded swift library

[Geordie Jay via swift-users]

Ján Kosa  schrieb am Sa. 7. Okt. 2017 um 13:34:

> I tried swift package clean, but it didn't help
>
> "Try to ensure the plugin provider module (libA) is (only) being compiled
> into its standalone shared library file."
> How do I go about this? It is 3rd party module, it doesn't define any
> products (https://github.com/apple/swift-protobuf.git). Is there
> something I can do in my Package files to make sure it is loaded
> dynamically?
>

When you compile a package depending on protobuf, all the relevant symbols
end up in your package’s library file. So here’s something you might try:

import protobuf into your own “PluginProvider” module (package), which has
a shared library product like this: ‘@_exported import Protobuf’ in some
compiled swift file. Then from the other dependent modules “import
PluginProvider” - the protobuf symbols should be available, and all from
one (nonconflicting) source.

Geordie



> On 6 October 2017 at 22:52, Geordie Jay  wrote:
>
>> I think SwiftPM is (incorrectly) compiling A.XYZ into each of the
>> modules that depend on it, as well as into your intended libA.so file.
>>
>> Try to ensure the plugin provider module (libA) is (only) being compiled
>> into its standalone shared library file. Try cleaning the swiftpm build for
>> one (swift package clean) and ensure the Package.swift files are correctly
>> set up to output the shared library.
>>
>> Sorry I can’t be more specific, I’ve had these same kinds of issues
>> before but I’m not 100% what they were.
>>
>> Geordie
>>
>>
>> Ján Kosa via swift-users  schrieb am Fr. 6. Okt.
>> 2017 um 14:41:
>>
>>> It worked! Took me a while to iron out details, but it is working now.
>>> Huge thanks sir, I will name my firstborn after you.
>>> Thanks for the @_cdecl("initializePlugin") tip as well, I didn't know
>>> about it and it will be very useful.
>>>
>>> I am having slightly related problem now (it was there before, but I
>>> ignored it for the time being), not sure if I should start a new thread?
>>>
>>> The PluginInterface module has one external dependency on module A,
>>> PluginConsumer has the dependency on module B which has dependency on same
>>> module A that the PluginInterface uses. When I load the plugin library, I
>>> get bunch of errors like:
>>>
>>> Class A.XYZ is implemented in both libPluginInterface.dylib and
>>> libMyPlugin.dylib
>>>
>>> I know why it is there, but I don't know how to get rid of it. I can't
>>> just remove dependency from PluginConsumer and use the one from
>>> PluginInterface (if that would even work?) because PluginConsumer does not
>>> depend on it directly, but it is going through module B first
>>>
>>> Cheers,
>>> Lope
>>>
>>> On 4 October 2017 at 22:17, Daniel Dunbar 
>>> wrote:
>>>
 The way that I have done this in the past is pass a protocol as an
 unsafe pointer to an exposed entry point:
 ```swift
 let entryPoint = dlsym(handle, “initializePlugin”)
 guard entryPoint != nil else {
 fatalError("missing plugin entry point: \(pluginPath)")
 }
 typealias PluginInitializationFunc = @convention(c)
 (UnsafeRawPointer) -> ()
 let f = unsafeBitCast(entryPoint, to:
 PluginInitializationFunc.self)
 f(Unmanaged.passUnretained(self).toOpaque())
 ```

 and then in the plugin convert back to the appropriate type:

 ```
 @_cdecl("initializePlugin")
 public func initializePlugin(_ ptr: UnsafeRawPointer) {
 let manager =
 Unmanaged.fromOpaque(ptr).takeUnretainedValue()
 ```

 HTH,
  - Daniel

 On Oct 4, 2017, at 11:02 AM, Ján Kosa via swift-users <
 swift-users@swift.org> wrote:

 Hello folks,

 I have been toying with dynamic libraries, trying to implement plugin
 functionality. I was able to get to the point where I can call simple
 function in loaded library, but I am having troubles starting more
 sophisticated communication channel.

 There are 3 projects
 - PluginConsumer is an app that loads plugin libraries
 - MyPlugin is a plugin implementation, output is dynamic library that
 PluginConsumer loads
 - PluginInterface is common interface that both MyPlugin and
 PluginConsumer use, so that they know how to communicate

 My first idea was to have PluginInterface be a simple SPM project with
 single file where the bare-bones PluginInterface class would be:


 open class PluginInterface {

 open func sayHi()

 }


 Package.swift file:


 // swift-tools-version:4.0

 import PackageDescription

 let package = Package(

 name: "PluginInterface",

 products: [ .library(name: "PluginInterface", type: .dynamic,
 targets: ["PluginInterface"]) ],

 

Re: [swift-users] Communicating with dynamically loaded swift library

[Ján Kosa via swift-users]

I tried swift package clean, but it didn't help

"Try to ensure the plugin provider module (libA) is (only) being compiled
into its standalone shared library file."
How do I go about this? It is 3rd party module, it doesn't define any
products (https://github.com/apple/swift-protobuf.git). Is there something
I can do in my Package files to make sure it is loaded dynamically?

On 6 October 2017 at 22:52, Geordie Jay  wrote:

> I think SwiftPM is (incorrectly) compiling A.XYZ into each of the modules
> that depend on it, as well as into your intended libA.so file.
>
> Try to ensure the plugin provider module (libA) is (only) being compiled
> into its standalone shared library file. Try cleaning the swiftpm build for
> one (swift package clean) and ensure the Package.swift files are correctly
> set up to output the shared library.
>
> Sorry I can’t be more specific, I’ve had these same kinds of issues before
> but I’m not 100% what they were.
>
> Geordie
>
>
> Ján Kosa via swift-users  schrieb am Fr. 6. Okt.
> 2017 um 14:41:
>
>> It worked! Took me a while to iron out details, but it is working now.
>> Huge thanks sir, I will name my firstborn after you.
>> Thanks for the @_cdecl("initializePlugin") tip as well, I didn't know
>> about it and it will be very useful.
>>
>> I am having slightly related problem now (it was there before, but I
>> ignored it for the time being), not sure if I should start a new thread?
>>
>> The PluginInterface module has one external dependency on module A,
>> PluginConsumer has the dependency on module B which has dependency on same
>> module A that the PluginInterface uses. When I load the plugin library, I
>> get bunch of errors like:
>>
>> Class A.XYZ is implemented in both libPluginInterface.dylib and
>> libMyPlugin.dylib
>>
>> I know why it is there, but I don't know how to get rid of it. I can't
>> just remove dependency from PluginConsumer and use the one from
>> PluginInterface (if that would even work?) because PluginConsumer does not
>> depend on it directly, but it is going through module B first
>>
>> Cheers,
>> Lope
>>
>> On 4 October 2017 at 22:17, Daniel Dunbar 
>> wrote:
>>
>>> The way that I have done this in the past is pass a protocol as an
>>> unsafe pointer to an exposed entry point:
>>> ```swift
>>> let entryPoint = dlsym(handle, “initializePlugin”)
>>> guard entryPoint != nil else {
>>> fatalError("missing plugin entry point: \(pluginPath)")
>>> }
>>> typealias PluginInitializationFunc = @convention(c)
>>> (UnsafeRawPointer) -> ()
>>> let f = unsafeBitCast(entryPoint, to:
>>> PluginInitializationFunc.self)
>>> f(Unmanaged.passUnretained(self).toOpaque())
>>> ```
>>>
>>> and then in the plugin convert back to the appropriate type:
>>>
>>> ```
>>> @_cdecl("initializePlugin")
>>> public func initializePlugin(_ ptr: UnsafeRawPointer) {
>>> let manager = Unmanaged.fromOpaque(ptr).
>>> takeUnretainedValue()
>>> ```
>>>
>>> HTH,
>>>  - Daniel
>>>
>>> On Oct 4, 2017, at 11:02 AM, Ján Kosa via swift-users <
>>> swift-users@swift.org> wrote:
>>>
>>> Hello folks,
>>>
>>> I have been toying with dynamic libraries, trying to implement plugin
>>> functionality. I was able to get to the point where I can call simple
>>> function in loaded library, but I am having troubles starting more
>>> sophisticated communication channel.
>>>
>>> There are 3 projects
>>> - PluginConsumer is an app that loads plugin libraries
>>> - MyPlugin is a plugin implementation, output is dynamic library that
>>> PluginConsumer loads
>>> - PluginInterface is common interface that both MyPlugin and
>>> PluginConsumer use, so that they know how to communicate
>>>
>>> My first idea was to have PluginInterface be a simple SPM project with
>>> single file where the bare-bones PluginInterface class would be:
>>>
>>>
>>> open class PluginInterface {
>>>
>>> open func sayHi()
>>>
>>> }
>>>
>>>
>>> Package.swift file:
>>>
>>>
>>> // swift-tools-version:4.0
>>>
>>> import PackageDescription
>>>
>>> let package = Package(
>>>
>>> name: "PluginInterface",
>>>
>>> products: [ .library(name: "PluginInterface", type: .dynamic,
>>> targets: ["PluginInterface"]) ],
>>>
>>> targets: [ .target(name: "PluginInterface") ]
>>>
>>> )
>>>
>>>
>>>
>>> UserPlugin is also very simple project containing only one file:
>>>
>>>
>>> public func getPlugin() -> AnyObject {
>>>
>>> return MyPlugin()
>>>
>>> }
>>>
>>>
>>> class MyPlugin: PluginInterface {
>>>
>>> override func sayHi() {
>>>
>>> print("Hi from my plugin")
>>>
>>> }
>>>
>>> }
>>>
>>> Package.swift:
>>>
>>>
>>> // swift-tools-version:4.0
>>>
>>> import PackageDescription
>>>
>>> let package = Package(
>>>
>>> name: "MyPlugin",
>>>
>>> products: [ .library(name: "MyPlugin", type: .dynamic, targets: [
>>> "MyPlugin"]) ],
>>>
>>> dependencies: [ .package(url: 

Re: [swift-users] How to check the type of a concrete class that inherits from a generic class?

[Glen Huang via swift-users]

Works like a charm, thanks.

> On 7 Oct 2017, at 2:56 PM, Slava Pestov  wrote:
> 
> You can try upcasting the value to NSObject first, and then performing a 
> conditional downcast to Controller1 and Controller2. At this point the type 
> checker will not have enough information to decide that the cast always 
> fails, and should no longer emit a warning.
> 
> Slava
> 
>> On Oct 6, 2017, at 11:55 PM, Glen Huang > > wrote:
>> 
>> Done, https://bugs.swift.org/browse/SR-6083 
>> 
>> 
>> In the mean time, is there any workaround? Or it’s not possible to check the 
>> concrete type without this issue being fixed?
>> 
>>> On 7 Oct 2017, at 2:44 PM, Slava Pestov >> > wrote:
>>> 
>>> Oh I see. I think the problem is that with Objective-C generics, you can 
>>> always cast from Foo to Foo, because the type parameters do not 
>>> really exist. Swift’s type checking logic for casts assumes Swift generic 
>>> semantics, where in general Foo and Foo are unrelated types.
>>> 
>>> Do you mind filing a bug?
>>> 
>>> Slava
>>> 
 On Oct 6, 2017, at 11:40 PM, Glen Huang > wrote:
 
 NSFetchedResultsController is the class from Core Data: 
 
 https://developer.apple.com/documentation/coredata/nsfetchedresultscontroller
  
 
 
> On 7 Oct 2017, at 2:38 PM, Slava Pestov  > wrote:
> 
> Can you post a self-contained example, including the declaration of 
> NSFetchedResultsController?
> 
> Slava
> 
>> On Oct 6, 2017, at 11:28 PM, Glen Huang via swift-users 
>> > wrote:
>> 
>> Hi,
>> 
>> I defined some concrete classes inheriting from a generic class like 
>> this:
>> 
>> class Controller1: NSFetchedResultsController {}
>> class Controller2: NSFetchedResultsController {}
>> 
>> And I assign them a shared delegate, and in the delegate method:
>> 
>> func controllerWillChangeContent(_ controller: 
>> NSFetchedResultsController)
>> 
>> I want to test the concrete type of controller, doing things differently 
>> for Controller1 and Controller2.
>> 
>> But doing the following gives me a warning: Cast from 
>> 'NSFetchedResultsController' to unrelated type 
>> 'Controller1’ always fails
>> 
>> switch controller {
>> case is Controller1:
>> // ...
>> default:
>> break
>> }
>> 
>> I wonder what’s the correct way to check the concrete type?
>> 
>> Regards,
>> Glen
>> ___
>> 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] How to check the type of a concrete class that inherits from a generic class?

[Slava Pestov via swift-users]

You can try upcasting the value to NSObject first, and then performing a 
conditional downcast to Controller1 and Controller2. At this point the type 
checker will not have enough information to decide that the cast always fails, 
and should no longer emit a warning.

Slava

> On Oct 6, 2017, at 11:55 PM, Glen Huang  wrote:
> 
> Done, https://bugs.swift.org/browse/SR-6083 
> 
> 
> In the mean time, is there any workaround? Or it’s not possible to check the 
> concrete type without this issue being fixed?
> 
>> On 7 Oct 2017, at 2:44 PM, Slava Pestov > > wrote:
>> 
>> Oh I see. I think the problem is that with Objective-C generics, you can 
>> always cast from Foo to Foo, because the type parameters do not really 
>> exist. Swift’s type checking logic for casts assumes Swift generic 
>> semantics, where in general Foo and Foo are unrelated types.
>> 
>> Do you mind filing a bug?
>> 
>> Slava
>> 
>>> On Oct 6, 2017, at 11:40 PM, Glen Huang >> > wrote:
>>> 
>>> NSFetchedResultsController is the class from Core Data: 
>>> 
>>> https://developer.apple.com/documentation/coredata/nsfetchedresultscontroller
>>>  
>>> 
>>> 
 On 7 Oct 2017, at 2:38 PM, Slava Pestov  wrote:
 
 Can you post a self-contained example, including the declaration of 
 NSFetchedResultsController?
 
 Slava
 
> On Oct 6, 2017, at 11:28 PM, Glen Huang via swift-users 
>  wrote:
> 
> Hi,
> 
> I defined some concrete classes inheriting from a generic class like this:
> 
> class Controller1: NSFetchedResultsController {}
> class Controller2: NSFetchedResultsController {}
> 
> And I assign them a shared delegate, and in the delegate method:
> 
> func controllerWillChangeContent(_ controller: 
> NSFetchedResultsController)
> 
> I want to test the concrete type of controller, doing things differently 
> for Controller1 and Controller2.
> 
> But doing the following gives me a warning: Cast from 
> 'NSFetchedResultsController' to unrelated type 
> 'Controller1’ always fails
> 
> switch controller {
> case is Controller1:
> // ...
> default:
> break
> }
> 
> I wonder what’s the correct way to check the concrete type?
> 
> Regards,
> Glen
> ___
> 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] How to check the type of a concrete class that inherits from a generic class?

[Glen Huang via swift-users]

Done, https://bugs.swift.org/browse/SR-6083 


In the mean time, is there any workaround? Or it’s not possible to check the 
concrete type without this issue being fixed?

> On 7 Oct 2017, at 2:44 PM, Slava Pestov  wrote:
> 
> Oh I see. I think the problem is that with Objective-C generics, you can 
> always cast from Foo to Foo, because the type parameters do not really 
> exist. Swift’s type checking logic for casts assumes Swift generic semantics, 
> where in general Foo and Foo are unrelated types.
> 
> Do you mind filing a bug?
> 
> Slava
> 
>> On Oct 6, 2017, at 11:40 PM, Glen Huang  wrote:
>> 
>> NSFetchedResultsController is the class from Core Data: 
>> 
>> https://developer.apple.com/documentation/coredata/nsfetchedresultscontroller
>> 
>>> On 7 Oct 2017, at 2:38 PM, Slava Pestov  wrote:
>>> 
>>> Can you post a self-contained example, including the declaration of 
>>> NSFetchedResultsController?
>>> 
>>> Slava
>>> 
 On Oct 6, 2017, at 11:28 PM, Glen Huang via swift-users 
  wrote:
 
 Hi,
 
 I defined some concrete classes inheriting from a generic class like this:
 
 class Controller1: NSFetchedResultsController {}
 class Controller2: NSFetchedResultsController {}
 
 And I assign them a shared delegate, and in the delegate method:
 
 func controllerWillChangeContent(_ controller: 
 NSFetchedResultsController)
 
 I want to test the concrete type of controller, doing things differently 
 for Controller1 and Controller2.
 
 But doing the following gives me a warning: Cast from 
 'NSFetchedResultsController' to unrelated type 
 'Controller1’ always fails
 
 switch controller {
 case is Controller1:
 // ...
 default:
 break
 }
 
 I wonder what’s the correct way to check the concrete type?
 
 Regards,
 Glen
 ___
 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] How to check the type of a concrete class that inherits from a generic class?

[Slava Pestov via swift-users]

Oh I see. I think the problem is that with Objective-C generics, you can always 
cast from Foo to Foo, because the type parameters do not really exist. 
Swift’s type checking logic for casts assumes Swift generic semantics, where in 
general Foo and Foo are unrelated types.

Do you mind filing a bug?

Slava

> On Oct 6, 2017, at 11:40 PM, Glen Huang  wrote:
> 
> NSFetchedResultsController is the class from Core Data: 
> 
> https://developer.apple.com/documentation/coredata/nsfetchedresultscontroller
> 
>> On 7 Oct 2017, at 2:38 PM, Slava Pestov  wrote:
>> 
>> Can you post a self-contained example, including the declaration of 
>> NSFetchedResultsController?
>> 
>> Slava
>> 
>>> On Oct 6, 2017, at 11:28 PM, Glen Huang via swift-users 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> I defined some concrete classes inheriting from a generic class like this:
>>> 
>>> class Controller1: NSFetchedResultsController {}
>>> class Controller2: NSFetchedResultsController {}
>>> 
>>> And I assign them a shared delegate, and in the delegate method:
>>> 
>>> func controllerWillChangeContent(_ controller: 
>>> NSFetchedResultsController)
>>> 
>>> I want to test the concrete type of controller, doing things differently 
>>> for Controller1 and Controller2.
>>> 
>>> But doing the following gives me a warning: Cast from 
>>> 'NSFetchedResultsController' to unrelated type 
>>> 'Controller1’ always fails
>>> 
>>> switch controller {
>>> case is Controller1:
>>>  // ...
>>> default:
>>>  break
>>> }
>>> 
>>> I wonder what’s the correct way to check the concrete type?
>>> 
>>> Regards,
>>> Glen
>>> ___
>>> 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] How to check the type of a concrete class that inherits from a generic class?

[Glen Huang via swift-users]

NSFetchedResultsController is the class from Core Data: 

https://developer.apple.com/documentation/coredata/nsfetchedresultscontroller

> On 7 Oct 2017, at 2:38 PM, Slava Pestov  wrote:
> 
> Can you post a self-contained example, including the declaration of 
> NSFetchedResultsController?
> 
> Slava
> 
>> On Oct 6, 2017, at 11:28 PM, Glen Huang via swift-users 
>>  wrote:
>> 
>> Hi,
>> 
>> I defined some concrete classes inheriting from a generic class like this:
>> 
>> class Controller1: NSFetchedResultsController {}
>> class Controller2: NSFetchedResultsController {}
>> 
>> And I assign them a shared delegate, and in the delegate method:
>> 
>> func controllerWillChangeContent(_ controller: 
>> NSFetchedResultsController)
>> 
>> I want to test the concrete type of controller, doing things differently for 
>> Controller1 and Controller2.
>> 
>> But doing the following gives me a warning: Cast from 
>> 'NSFetchedResultsController' to unrelated type 
>> 'Controller1’ always fails
>> 
>> switch controller {
>> case is Controller1:
>>   // ...
>> default:
>>   break
>> }
>> 
>> I wonder what’s the correct way to check the concrete type?
>> 
>> Regards,
>> Glen
>> ___
>> 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] How to check the type of a concrete class that inherits from a generic class?

[Slava Pestov via swift-users]

Can you post a self-contained example, including the declaration of 
NSFetchedResultsController?

Slava

> On Oct 6, 2017, at 11:28 PM, Glen Huang via swift-users 
>  wrote:
> 
> Hi,
> 
> I defined some concrete classes inheriting from a generic class like this:
> 
> class Controller1: NSFetchedResultsController {}
> class Controller2: NSFetchedResultsController {}
> 
> And I assign them a shared delegate, and in the delegate method:
> 
> func controllerWillChangeContent(_ controller: 
> NSFetchedResultsController)
> 
> I want to test the concrete type of controller, doing things differently for 
> Controller1 and Controller2.
> 
> But doing the following gives me a warning: Cast from 
> 'NSFetchedResultsController' to unrelated type 
> 'Controller1’ always fails
> 
> switch controller {
> case is Controller1:
>// ...
> default:
>break
> }
> 
> I wonder what’s the correct way to check the concrete type?
> 
> Regards,
> Glen
> ___
> 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] How to check the type of a concrete class that inherits from a generic class?

[Glen Huang via swift-users]

Hi,

I defined some concrete classes inheriting from a generic class like this:

class Controller1: NSFetchedResultsController {}
class Controller2: NSFetchedResultsController {}

And I assign them a shared delegate, and in the delegate method:

func controllerWillChangeContent(_ controller: 
NSFetchedResultsController)

I want to test the concrete type of controller, doing things differently for 
Controller1 and Controller2.

But doing the following gives me a warning: Cast from 
'NSFetchedResultsController' to unrelated type 
'Controller1’ always fails

switch controller {
case is Controller1:
// ...
default:
break
}

I wonder what’s the correct way to check the concrete type?

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