Given the educational angle that seems to be part of the mission of Swift, I was hoping that the Raspberry Pi port would be something the Swift project would directly integrate and distribute
-david > On Jan 2, 2016, at 3:00 PM, Philippe Hausler via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > > > Responses inline: > >> On Jan 2, 2016, at 3:58 AM, Drew Crawford via swift-corelibs-dev >> <swift-corelibs-dev@swift.org> wrote: >> >> I had a question about something I saw in the docs: >> >>> A significant portion of the implementation of Foundation on Apple >>> platforms is provided by another framework called CoreFoundation (a.k.a. >>> CF). CF is written primarily in C and is very portable. Therefore we have >>> chosen to use it for the internal implementation of Swift Foundation where >>> possible. As CF is present on all platforms, we can use it to provide a >>> common implementation everywhere. >> >> (emphasis added) >> >> Is the intent of this paragraph to suggest that most PRs to >> swift-corelibs-foundation should be a C-language implementation to CF with a >> light Swift wrapper? That goes against my intuition, but it "seems to be" a >> plain reading of the paragraph. > > I think the underlying intent is that we should use the right tools for the > job; where it makes sense, even the standard library uses C++. Similarly some > of the interfaces for ICU for example make much more sense to encapsulate > with CF (and re-use some of the existing cross platform abstractions). Some > classes will be a thin veneer on top of CF, where-as others will be a > completely swift implementation. Take the two cases of NSCalendar and > NSThread. CF provides some very hard to write (and hard to get right) > implementations of calendrical math, even though I wrote a good portion of > the NSCalendar swift implementation; I am definitely glad that there was an > implementation I could fall back upon to deal with that logic. The > counterpoint of NSThread; we could have wrapped up a CFThreadRef type object > and bridged it across but It made sense to keep NSThread in the realm of > Swift not only for a potential example of dealing with posix APIs for the > community but also it just worked out more cleanly in my opinion. > > I have not crunched the numbers but I have a gut feeling that a large > majority of the pull requests have been mostly Swift implementations and only > a few of them have been thin veneers on-top-of CF and even fewer have been > changes to CF itself. > >> >> its justification about "all platforms" is also strange–I know CF "kind of" >> builds for Windows, but is anyone actually testing it there? To make sure >> we aren't breaking it? Or does "all platforms" mean something else here? > > I know there have been efforts to port swift to FreeBSD and to new > architectures like ARM-elf for things like Raspberry Pi, I would not be > surprised that there are efforts to port to Android or Windows out there. > Granted we do not have any CI provided by Apple to ensure not breaking these > efforts but I think that the community will be interested in keeping these > things running since a cross platform framework and language are really > appealing (even Apple makes a few products for Android and Windows…) > > As of current the Windows target is not held directly from the point at which > this CF was cut from; so I would probably say “trust but verify” and I would > not be surprised that there may be a few breaking points there that need to > be re-looked at for that platform. I am certain that if someone took up a new > target like Windows that would be met with great enthusiasm from all of the > swift community. I was ecstatic when I saw that there was a FreeBSD port. > > I think the one major thing to take under consideration is that alternate > platforms than Mac OS X and Ubuntu 14/15 don’t have integration into the CI > that the swift project maintains. I think however if there is strong desire > out there it would be interesting to have externally maintained build servers > provided by the community to verify these targets. I am not in charge of that > type of decision but I would definitely think that it would be an amiable > goal and I would think that it would be worthwhile to discuss further. > >> >> I feel like this paragraph is an opportunity to explain to a patch author >> how to structure their patch between use/maintenance/contributions to the CF >> layer vs the Swift layer. I feel like it could do a much better job, but I >> don't understand what the design guidance actually is, so I can't fix it. > > Things that enter into CF territory will be things that we will consider with > a very close eye on them because they will likely move up-stream into the > CoreFoundation that ships with our current platforms so that the lifecycle > completes back out to the exported version in the open-source side of it. > The Foundation part of the story is a bit more mutable since we have the > Objective-C version that will still be maintained. That being said there is a > very strong desire to keep these in parity; we may use some of the interfaces > in the swift version to try out what people think of these APIs (most of > these are marked with experimental, and if they are not we should either > correct them to be the same or mark them as such). Furthermore the swift > version will sometimes drive internal efforts to improve Foundation as a > whole not just it’s swift exposition. We have already had a few proposals > that are making their ways to the component owners and teams that will > improve the state of affairs for not just swift but objc too as externally > authored proposals. > > I agree that some of this intent should be a bit more clearly laid out; I > will discuss about this when I get back into the office Monday and see what > we can come up with to more clearly illustrate what is expected, what types > of fallout patches have, and how the process will work for each potential > layer and interaction. > > >> >> >> >> >> _______________________________________________ >> 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
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
