[swift-corelibs-dev] Defining _GNU_SOURCE for module-map-included headers
I'm trying to invoke Linux's unshare() system call from Swift, but without much success. From C, it requires _GNU_SOURCE to be #define'd before the #include . The Glibc module map does indeed include sched.h, so the lack of _GNU_SOURCE appears to be the likely culprit. What's the appropriate action to take here? Dan ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] Defining _GNU_SOURCE for module-map-included headers
+ swift-dev, Jordan
On Sun, Dec 20, 2015 at 2:21 AM, Dan Stenmark via swift-corelibs-dev
wrote:
> I'm trying to invoke Linux's unshare() system call from Swift, but without
> much success. From C, it requires _GNU_SOURCE to be #define'd before the
> #include . The Glibc module map does indeed include sched.h, so the
> lack of _GNU_SOURCE appears to be the likely culprit. What's the appropriate
> action to take here?
>
> Dan
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
--
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] NSCoding methods
> Somewhat; the mangled symbols are technically searchable by dlsym but that > seems like a hack. Perhaps one of the stdlib/compiler team might be able to > speak more on this than myself and they may have suggestions for a better > way. Foundation is at a special spot in which we can sometimes get special > runtime considerations for these types of things. It’d arguably be more of a hack to add a global manifest of classes if the dynamic linker already has one ;-) Here’s a toy implementation of swift_classFromString(): https://github.com/lhoward/SwiftRuntimeTest Disclaimer: I know very little about Swift nor its implementation beyond a bit of poking around. > For example NSUUID is defined by it’s module name Foundation.NSUUID; in that > a program could have it’s own NSUUID that is totally different (naming it the > same thing would be confusing to read and potentially viewed as bad form but > it can be done…). That would result in MyApplication.NSUUID to define the > symbolic name of the item. From the perspective of NSKeyedArchiver it will > encode things as NSUUID (without the namespace) in that in the realm of objc > there can be only one. What if you (re-)added the ability to annotate Swift classes with their Objective-C name on non-Apple platforms? I don’t know what the runtime costs of doing this are but it seems like it’s either this, or only allow non-namespaced names for Foundation objects. — Luke ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] [swift-corelibs-libdispatch] Port transform and use libbsd (#13)
First we can't use HAVE_MACH which isn't namespaces in a system header. Second we don't want to ship configure.h either anyway. Last we discussed with Daniel about that already and we'll probably end up having things based on __have_include() eventually. So for now __APPLE__ will do in headers. Everywhere else HAVE_MACH is used correctly as expected. -Pierre on his iPhone > On 19 déc. 2015, at 13:11, Chris Hanson via swift-corelibs-dev > wrote: > >> On Dec 14, 2015, at 8:12 PM, Pierre Habouzit via swift-corelibs-dev >> wrote: >> >> Technically, until someone ports libdispatch to GNU/Hurd,it’s okay to use >> #if __APPLE__ to hide anything mach related. > > I think it would be better not to conflate __APPLE__ and HAVE_MACH. > > I don't expect a libdispatch port to OSF/1 any time soon, but libdispatch is > already used in Jordan Hubbard's "NextBSD" effort, and that actually does > provide Mach APIs without being an Apple platform. > > -- Chris > > ___ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] NSCoding methods
It's not too hard to figure out (and there are a couple of other ObjC implementations) but if Apple have any specs for the archive format, I would be keen to take a look. Also regarding interoperability - perhaps it might be reasonable, for non-Foundation classes that have non-namespaced names (on non-ObjC platforms) for the caller to configure the NSKeyedArchiver with explicit class mappings? -- Luke Sent from my iPhone > On 21 Dec 2015, at 00:02, Luke Howard via swift-corelibs-dev > wrote: > > >> Somewhat; the mangled symbols are technically searchable by dlsym but that >> seems like a hack. Perhaps one of the stdlib/compiler team might be able to >> speak more on this than myself and they may have suggestions for a better >> way. Foundation is at a special spot in which we can sometimes get special >> runtime considerations for these types of things. > > It’d arguably be more of a hack to add a global manifest of classes if the > dynamic linker already has one ;-) Here’s a toy implementation of > swift_classFromString(): > > https://github.com/lhoward/SwiftRuntimeTest > > Disclaimer: I know very little about Swift nor its implementation beyond a > bit of poking around. > >> For example NSUUID is defined by it’s module name Foundation.NSUUID; in that >> a program could have it’s own NSUUID that is totally different (naming it >> the same thing would be confusing to read and potentially viewed as bad form >> but it can be done…). That would result in MyApplication.NSUUID to define >> the symbolic name of the item. From the perspective of NSKeyedArchiver it >> will encode things as NSUUID (without the namespace) in that in the realm of >> objc there can be only one. > > What if you (re-)added the ability to annotate Swift classes with their > Objective-C name on non-Apple platforms? I don’t know what the runtime costs > of doing this are but it seems like it’s either this, or only allow > non-namespaced names for Foundation objects. > > — Luke > ___ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
