Re: [swift-corelibs-dev] NSDate, NSDateFormatter
Tony, all: I've opened https://bugs.swift.org/browse/SR-208 against the .dateFormat property of NSDateFormatter. It appears that it is not functioning as expected. This was against the latest main branch of the repositories and compiled on my Ubuntu14.04 system. swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c) Target: x86_64-unknown-linux-gnu Joe On Fri, Dec 11, 2015 at 12:56 PM, Tony Parker wrote: > Hi Joe, > > Sure, bug reports are appreciated. > > If you have the ability to check out the whole stack and try ToT, that > would be great too. We are moving extremely rapidly right now on > implementing missing pieces of Foundation. > > - Tony > > On Dec 11, 2015, at 10:53 AM, Joseph Bell wrote: > > Thanks Tony, with LD_LIBRARY_PATH set to include usr/lib/swift/linux I can > get the REPL to reproduce what I see with the compiler, and that's a blank > line printed out: > > ➜ dates > > LD_LIBRARY_PATH=/opt/apple/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/linux:$LD_LIBRARY_PATH > swift printdate.swift > > ➜ dates > > Which leads me to the obvious question, either I've forgotten how to use > NSDateFormatter, or the implementation in the December 1 drop is silently > not supporting setting the dateFormat property, which appears to be the > case, as setting dateStyle and timeStyle do appear to work. > > import Foundation > > let dateFormatter = NSDateFormatter() > dateFormatter.dateFormat = "dd-MM-" > var dateStr = dateFormatter.stringFromDate(NSDate()) > > print(dateStr) > > dateFormatter.dateStyle = .MediumStyle > dateFormatter.timeStyle = .MediumStyle > dateStr = dateFormatter.stringFromDate(NSDate()) > print(dateStr) > > results in: > > ➜ dates > > LD_LIBRARY_PATH=/opt/apple/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04/usr/lib/swift/linux:$LD_LIBRARY_PATH > swift printdate.swift > <-- this is a blank line emitted by the first print(), which it should not > be --> > Dec 11, 2015, 6:52:33 PM > > Thanks for any insight and if I need to file a bug report I am happy to > help, > Joe > > > > > On Fri, Dec 11, 2015 at 10:59 AM, Tony Parker > wrote: > >> Hi Joe, >> >> Try this as a workaround: Set the LD_LIBRARY_PATH environment variable to >> $INSTALLED_LOCATION_OF_SWIFT/usr/lib/swift/linux >> >> This should only affect the REPL and not compiled code. >> >> I think this is supposed to be fixed in the top of tree Swift but not in >> the Dec 1 binary drop. >> >> - Tony >> >> On Dec 11, 2015, at 5:54 AM, Joseph Bell via swift-corelibs-dev < >> swift-corelibs-dev@swift.org> wrote: >> >> All, >> >> Howdy. I am using swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04 that was >> released on December 1. The following code: >> >> import Foundation >> >> let dateFormatter = NSDateFormatter() >> dateFormatter.dateFormat = "dd-MM-" >> let dateStr = dateFormatter.stringFromDate(NSDate()) >> >> print(dateStr) >> >> results in >> >> LLVM ERROR: Program used external function >> '_TFC10Foundation6NSDateCfT_S0_' which could not be resolved! >> >> when executed with the swift driver, and then when compiled with swiftc >> the print statement just gives a blank newline. >> >> I don't know if this is a known issue (I haven't found any reference on >> the status page or elsewhere indicating this was unimplemented), or I have >> an environmental problem. >> >> Thoughts? >> >> Joe >> >> ___ >> 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] Unresolved enumeration symbols
Howdy.
I'm using the basic build instructions (checking out swift, llvm, clang,
etc.) and can successfully build a packaged release with
./swift/utils/build-script --preset=buildbot_linux_1404
install_destdir=${INSTALL_DIR} i
nstallable_package=${PACKAGE}
However, the resulting build output for Foundation is missing enumeration
types, and I noticed it in particular in the NSDateFormatter class:
➜ Foundation git:(master) ✗ nm NSDateFormatter.swift.o|grep Medium
Of course this results in the symbols not being included in libFoundation.so
➜ Foundation git:(master) ✗ nm -D libFoundation.so |grep Medium
Looking at my build from source I am missing about 200K of symbols that the
SNAPSHOT build is including:
Foundation git:(master) ✗ nm -D
/opt/apple/swift-2.2-SNAPSHOT-2015-12-10-a-ubuntu14.04/usr/lib/swift/linux/libFoundation.so|grep
Medium
0034ab40 T
_TFO10Foundation20NSDateFormatterStyle11MediumStyleFMS0_S0_
003944e0 T _TFO10Foundation21NSFormattingUnitStyle6MediumFMS0_S0_
0034b330 T
_TFO10Foundation28NSDateIntervalFormatterStyle11MediumStyleFMS0_S0_
003f5820 T
_TFO10Foundation36NSPersonNameComponentsFormatterStyle6MediumFMS0_S0_
Thanks for any thoughts,
Joe
PS - I am using the master branch across all repositories.
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] Unresolved enumeration symbols
Information about the system I'm building with, will note it doesn't have
anything else "special" i.e., no 4.x kernel or non-standard libc. It is
really interesting, everything compiles okay, no errors thrown, etc. I'm
going to try a build on a 15.10 VM as well to see if I can reproduce.
uname -a
Linux darthvader 3.19.0-39-generic #44~14.04.1-Ubuntu SMP Wed Dec 2
10:00:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty
clang --version
Ubuntu clang version 3.6.0-2ubuntu1~trusty1 (tags/RELEASE_360/final) (based
on LLVM 3.6.0)
Target: x86_64-pc-linux-gnu
Thread model: posix
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 21
model : 1
model name : AMD FX(tm)-8120 Eight-Core Processor
stepping: 2
microcode : 0x6000626
cpu MHz : 1400.000
cache size : 2048 KB
physical id : 0
siblings: 8
core id : 0
cpu cores : 4
apicid : 16
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse3
6 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm
constant_tsc
rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor
ssse3 cx16 sse4_
1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm
sse4a misali
gnsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext
perfctr_core per
fctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean
flushbyasid
decodeassists pausefilter pfthreshold vmmcall
bugs: fxsave_leak
bogomips: 6228.24
TLB size: 1536 4K pages
clflush size: 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb
On Sat, Dec 12, 2015 at 7:24 PM, Joe Bell wrote:
> Tony, yes, I'm building on an Ubuntu 14.04 system. I can provide any
> uname or kernel information if you need.
>
> Joe
>
> On Dec 12, 2015, at 7:17 PM, Tony Parker wrote:
>
> Hi Joe,
>
> I see you used the preset for linux, but I just wanted to double-check
> that you are indeed building on Linux.
>
> - Tony
>
> On Dec 12, 2015, at 3:48 PM, Joseph Bell via swift-corelibs-dev <
> swift-corelibs-dev@swift.org> wrote:
>
> Howdy.
>
> I'm using the basic build instructions (checking out swift, llvm, clang,
> etc.) and can successfully build a packaged release with
>
> ./swift/utils/build-script --preset=buildbot_linux_1404
> install_destdir=${INSTALL_DIR} i
> nstallable_package=${PACKAGE}
>
> However, the resulting build output for Foundation is missing enumeration
> types, and I noticed it in particular in the NSDateFormatter class:
>
> ➜ Foundation git:(master) ✗ nm NSDateFormatter.swift.o|grep Medium
>
>
> Of course this results in the symbols not being included in
> libFoundation.so
> ➜ Foundation git:(master) ✗ nm -D libFoundation.so |grep Medium
>
> Looking at my build from source I am missing about 200K of symbols that
> the SNAPSHOT build is including:
>
> Foundation git:(master) ✗ nm -D
> /opt/apple/swift-2.2-SNAPSHOT-2015-12-10-a-ubuntu14.04/usr/lib/swift/linux/libFoundation.so|grep
> Medium
> 0034ab40 T
> _TFO10Foundation20NSDateFormatterStyle11MediumStyleFMS0_S0_
> 003944e0 T _TFO10Foundation21NSFormattingUnitStyle6MediumFMS0_S0_
> 0034b330 T
> _TFO10Foundation28NSDateIntervalFormatterStyle11MediumStyleFMS0_S0_
> 003f5820 T
> _TFO10Foundation36NSPersonNameComponentsFormatterStyle6MediumFMS0_S0_
>
> Thanks for any thoughts,
> Joe
>
> PS - I am using the master branch across all repositories.
>
> ___
> 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] Unresolved enumeration symbols
Installing Ubuntu 15.10 on a VM, bringing in all of the prerequisites, I
get the same result. The build completes successfully but libFoundation.so
is not including the enumerations in NSDateFormatter.
public enum NSDateFormatterStyle : UInt {
case NoStyle
case ShortStyle
case MediumStyle
case LongStyle
case FullStyle
}
For grins, I searched through libFoundation.so with nm -D looking for
another enum, say one of the NSNumber format styles:
$ nm -D libFoundation.so |grep CurrencyStyle
$ nm -D libFoundation.so |grep PercentStyle
No dice, Chicago.
I can't say all enumerations are missing but these definitely are.
I've also posted what I use to prep and build at
https://github.com/iachievedit/package-swift; hoping there isn't an
embarrassing oversight.
Joe
On Sat, Dec 12, 2015 at 8:00 PM, Joseph Bell wrote:
> Information about the system I'm building with, will note it doesn't have
> anything else "special" i.e., no 4.x kernel or non-standard libc. It is
> really interesting, everything compiles okay, no errors thrown, etc. I'm
> going to try a build on a 15.10 VM as well to see if I can reproduce.
>
> uname -a
> Linux darthvader 3.19.0-39-generic #44~14.04.1-Ubuntu SMP Wed Dec 2
> 10:00:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 14.04.3 LTS
> Release: 14.04
> Codename: trusty
>
> clang --version
> Ubuntu clang version 3.6.0-2ubuntu1~trusty1 (tags/RELEASE_360/final)
> (based on LLVM 3.6.0)
> Target: x86_64-pc-linux-gnu
> Thread model: posix
>
> cat /proc/cpuinfo
> processor : 0
> vendor_id : AuthenticAMD
> cpu family : 21
> model : 1
> model name : AMD FX(tm)-8120 Eight-Core Processor
> stepping: 2
> microcode : 0x6000626
> cpu MHz : 1400.000
> cache size : 2048 KB
> physical id : 0
> siblings: 8
> core id : 0
> cpu cores : 4
> apicid : 16
> initial apicid : 0
> fpu : yes
> fpu_exception : yes
> cpuid level : 13
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse3
> 6 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp
> lm constant_tsc
> rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor
> ssse3 cx16 sse4_
> 1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy
> abm sse4a misali
> gnsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext
> perfctr_core per
> fctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale
> vmcb_clean flushbyasid
> decodeassists pausefilter pfthreshold vmmcall
> bugs: fxsave_leak
> bogomips: 6228.24
> TLB size: 1536 4K pages
> clflush size: 64
> cache_alignment : 64
> address sizes : 48 bits physical, 48 bits virtual
> power management: ts ttp tm 100mhzsteps hwpstate cpb
>
>
>
> On Sat, Dec 12, 2015 at 7:24 PM, Joe Bell wrote:
>
>> Tony, yes, I'm building on an Ubuntu 14.04 system. I can provide any
>> uname or kernel information if you need.
>>
>> Joe
>>
>> On Dec 12, 2015, at 7:17 PM, Tony Parker
>> wrote:
>>
>> Hi Joe,
>>
>> I see you used the preset for linux, but I just wanted to double-check
>> that you are indeed building on Linux.
>>
>> - Tony
>>
>> On Dec 12, 2015, at 3:48 PM, Joseph Bell via swift-corelibs-dev <
>> swift-corelibs-dev@swift.org> wrote:
>>
>> Howdy.
>>
>> I'm using the basic build instructions (checking out swift, llvm, clang,
>> etc.) and can successfully build a packaged release with
>>
>> ./swift/utils/build-script --preset=buildbot_linux_1404
>> install_destdir=${INSTALL_DIR} i
>> nstallable_package=${PACKAGE}
>>
>> However, the resulting build output for Foundation is missing enumeration
>> types, and I noticed it in particular in the NSDateFormatter class:
>>
>> ➜ Foundation git:(master) ✗ nm NSDateFormatter.swift.o|grep Medium
>>
>>
>> Of course this results in the symbols not being included in
>> libFoundation.so
>> ➜ Foundation git:(master) ✗ nm -D libFoundation.so |grep Medium
>>
>> Looking at my build from source I am missing about 200K of symbols that
>> the SNAPSHOT build is including:
>>
>> Foundation git:(master) ✗ nm -D
>> /opt/apple/swift-2.2-SNAPSHOT-2015-12-10-a-ubuntu14.04/usr/lib/swift/linux/libFoundation.so|grep
>> Medium
>> 0034ab40 T
>> _TFO10Foundation20NSDateFormatterStyle11MediumSt
Re: [swift-corelibs-dev] Unresolved enumeration symbols
Tony, all:
I went back to basics and used the following to build:
./swift/utils/build-script -R --xctest --foundation -t
Unfortunately I get the same result - missing symbols for enumerations in
libFoundation.so. Once again I'm building against the master branch for
all repositories.
I'm going to build the debug configuration now and see - I would be curious
to know if anyone can reproduce this, I'd be happy to write up a Dockerfile
or something to at least have someone confirm the reproducibility.
Joe
On Sat, Dec 12, 2015 at 10:27 PM, Joseph Bell wrote:
> Installing Ubuntu 15.10 on a VM, bringing in all of the prerequisites, I
> get the same result. The build completes successfully but libFoundation.so
> is not including the enumerations in NSDateFormatter.
>
> public enum NSDateFormatterStyle : UInt {
> case NoStyle
> case ShortStyle
> case MediumStyle
> case LongStyle
> case FullStyle
> }
>
> For grins, I searched through libFoundation.so with nm -D looking for
> another enum, say one of the NSNumber format styles:
>
> $ nm -D libFoundation.so |grep CurrencyStyle
> $ nm -D libFoundation.so |grep PercentStyle
>
> No dice, Chicago.
>
> I can't say all enumerations are missing but these definitely are.
>
> I've also posted what I use to prep and build at
> https://github.com/iachievedit/package-swift; hoping there isn't an
> embarrassing oversight.
>
> Joe
>
>
> On Sat, Dec 12, 2015 at 8:00 PM, Joseph Bell wrote:
>
>> Information about the system I'm building with, will note it doesn't have
>> anything else "special" i.e., no 4.x kernel or non-standard libc. It is
>> really interesting, everything compiles okay, no errors thrown, etc. I'm
>> going to try a build on a 15.10 VM as well to see if I can reproduce.
>>
>> uname -a
>> Linux darthvader 3.19.0-39-generic #44~14.04.1-Ubuntu SMP Wed Dec 2
>> 10:00:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>
>> lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description: Ubuntu 14.04.3 LTS
>> Release: 14.04
>> Codename: trusty
>>
>> clang --version
>> Ubuntu clang version 3.6.0-2ubuntu1~trusty1 (tags/RELEASE_360/final)
>> (based on LLVM 3.6.0)
>> Target: x86_64-pc-linux-gnu
>> Thread model: posix
>>
>> cat /proc/cpuinfo
>> processor : 0
>> vendor_id : AuthenticAMD
>> cpu family : 21
>> model : 1
>> model name : AMD FX(tm)-8120 Eight-Core Processor
>> stepping: 2
>> microcode : 0x6000626
>> cpu MHz : 1400.000
>> cache size : 2048 KB
>> physical id : 0
>> siblings: 8
>> core id : 0
>> cpu cores : 4
>> apicid : 16
>> initial apicid : 0
>> fpu : yes
>> fpu_exception : yes
>> cpuid level : 13
>> wp : yes
>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>> mca cmov pat pse3
>> 6 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp
>> lm constant_tsc
>> rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor
>> ssse3 cx16 sse4_
>> 1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy
>> abm sse4a misali
>> gnsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext
>> perfctr_core per
>> fctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale
>> vmcb_clean flushbyasid
>> decodeassists pausefilter pfthreshold vmmcall
>> bugs: fxsave_leak
>> bogomips: 6228.24
>> TLB size: 1536 4K pages
>> clflush size: 64
>> cache_alignment : 64
>> address sizes : 48 bits physical, 48 bits virtual
>> power management: ts ttp tm 100mhzsteps hwpstate cpb
>>
>>
>>
>> On Sat, Dec 12, 2015 at 7:24 PM, Joe Bell wrote:
>>
>>> Tony, yes, I'm building on an Ubuntu 14.04 system. I can provide any
>>> uname or kernel information if you need.
>>>
>>> Joe
>>>
>>> On Dec 12, 2015, at 7:17 PM, Tony Parker
>>> wrote:
>>>
>>> Hi Joe,
>>>
>>> I see you used the preset for linux, but I just wanted to double-check
>>> that you are indeed building on Linux.
>>>
>>> - Tony
>>>
>>> On Dec 12, 2015, at 3:48 PM, Joseph Bell via swift-corelibs-dev <
>>> swift-corelibs-dev@swift.org> wrote:
>>>
>>> Howdy.
>>>
>>> I'm using the basic build
[swift-corelibs-dev] NSThread properties
Reading the Status page I see that NSThread is "fully implemented", yet. when looking at the code and verifying by compiling, none of the properties: executing finished cancelled are implemented. Is this an oversight or was it decided to not implement these properties? Double-checking before I file an SR. Thanks, Joe ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] NSThread properties
Thanks Tony, https://bugs.swift.org/browse/SR-303 has been filed. On Thu, Dec 17, 2015 at 8:53 PM, Tony Parker wrote: > Hi Joe, > > Looks like an oversight. We should add them. > > - Tony > > On Dec 17, 2015, at 6:45 PM, Joseph Bell via swift-corelibs-dev < > swift-corelibs-dev@swift.org> wrote: > > Reading the Status page I see that NSThread is "fully implemented", yet. > when looking at the code and verifying by compiling, none of the properties: > > executing > finished > cancelled > > are implemented. > > Is this an oversight or was it decided to not implement these properties? > > Double-checking before I file an SR. > > Thanks, > Joe > > ___ > 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] Testcases for NSDateFormatter
Howdy, A few weeks ago I opened https://bugs.swift.org/browse/SR-208 as it appears setting the dateFormat property of NSDateFormatter has no effect. It's been open for a while and I thought I'd start looking at whether or not I could help, and decided to first start with getting NSDateFormatter included in TestFoundation. Before moving on further and issuing a PR, I would appreciate feedback on the approach that I'm taking here: https://github.com/iachievedit/swift-corelibs-foundation/commit/482d861127e8b78007ceaf15f6c905ac04b1e9a4 The first tests are only looking at the dateStyle property, and I've included tests for the various styles as they are rendered for the en_US locale. The intent is to add support for validating additional locales in the future. Since strptime doesn't appear to be available to the Glibc module I'm using a quick Python script included in Resources/ to take a format string and render a human-friendly date. At the moment I know there is a discrepancy between what NSDateFormatter and the python driver can emit, the python script is currently adjusting to my timezone and not using UTC, but that will be fixed before a PR is issued. I'll also add the timeStyle property and then continue to add tests. Thoughts and comments most welcome, and Happy New Year. Joe ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
[swift-corelibs-dev] Change in String.CharacterView.Index?
Howdy, I've been building the latest Swift 3.0 and noticed that between Apr 25 and today that String.CharacterView.Index.advance(by:) is no longer available. This runs with an Apr 25 build (Swift 255544591c to be exact) let string:String = "Hello, world!" print(string.startIndex) print(string.startIndex.advanced(by:1)) It fails with a build today (May 8, Swift 26fcf1ab4a): test.swift:3:14: error: value of type 'Index' (aka 'String.CharacterView.Index') has no member 'advanced' print(string.startIndex.advanced(by:1)) ~~~^~ I don't know who runs swiftdoc.org but it is handy, and shows advanced(by:) a valid method: http://swiftdoc.org/v3.0/type/String.CharacterView.Index/ Not sure what I'm missing here! Thanks, Joe -- Joseph Bell http://dev.iachieved.it/iachievedit/ @iachievedit ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
[swift-corelibs-dev] libdispatch/GCD for Swift 3.0 on Linux
Howdy all, While working to convert some NSThread code over to GCD on Linux I noticed that (to my dismay) GCD wasn't included in the Swift 3.0 preview build, nor is it apart of the buildbot for Linux. Scouring through the repository and mailing lists I can see where it is possible to build, but there are no downstream instructions on how to make a line like this: let queue = DispatchQueue(label: "com.app.queue") work with the swiftc compiler on Linux. A couple of questions: * are there any timelines that the principals of GCD with Swift 3 on Linux can share; i.e., is the plan to have it included in time for the Swift 3 GA release later this year? * are there any follow-up instructions past getting it built on how to use it (or will make install DESTDIR place it in the right spots in the Swift 3 toolchain hierarchy?) Any useful tips or pointers would be helpful! Cheers, Joe -- Joseph Bell http://dev.iachieved.it/iachievedit/ @iachievedit ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] libdispatch/GCD for Swift 3.0 on Linux
Dave, Thanks for the details, I appreciate it. I have seen the term "Swift overlay" used, particularly in the context of libdispatch. What does that mean exactly in this regard (searching for it returns tutorials on overlay UIViews which I doubt is appropriate here). I certainly hope GCD is included in Swift 3.0 on Linux too! Joe On Tue, Jun 21, 2016 at 7:59 AM, David P Grove wrote: > Hi Joe, > > TL;DR: right now the Swift 3.0 overlay for libdispatch is not available on > Linux. > > But, a variety of activities are kicking off to get it there. There > should be visible progress (and opportunities to help if you are so > inclined) over the next few weeks. > > > > > While working to convert some NSThread code over to GCD on Linux I > > noticed that (to my dismay) GCD wasn't included in the Swift 3.0 > > preview build, nor is it apart of the buildbot for Linux. Scouring > > through the repository and mailing lists I can see where it is > > possible to build, but there are no downstream instructions on how > > to make a line like this: > > > > let queue = DispatchQueue(label: "com.app.queue") > > > > work with the swiftc compiler on Linux. > > > > A couple of questions: > > > > * are there any timelines that the principals of GCD with Swift 3 on > > Linux can share; i.e., is the plan to have it included in time for > > the Swift 3 GA release later this year? > > I certainly hope so; but cannot speak for official plans. > > > * are there any follow-up instructions past getting it built on how > > to use it (or will make install DESTDIR place it in the right spots > > in the Swift 3 toolchain hierarchy?) > > > > I expect when things are done, it will be similar to how building the > current Swift-2 dispatch overlay works on Linux. To build from source you > use swift/utils/build-script with --libdispatch and it takes care of all > the details (ie, it just works...). > > --dave > > -- Joseph Bell http://dev.iachieved.it/iachievedit/ @iachievedit ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] libdispatch/GCD for Swift 3.0 on Linux
David, Chris, Thanks again for the responses regarding libdispatch (GCD) on Linux with Swift 3.0. I took a stab at building what was there and indeed, I see there are missing components to the overlay. For example, I see where Dispatch.swift contains things like "public extension DispatchGroup" but there is no actual DispatchGroup defined anywhere (just extensions to it). The same goes for DispatchSemaphore, DispatchQueue, DispatchWorkItem, etc. Unless I am offbase and that is defined (I certainly couldn't find it). At any rate, thanks again for the work you're doing bringing GCD to Linux; I'm looking forward to it. Joe On Tue, Jun 21, 2016 at 10:24 AM, David P Grove wrote: > Joseph Bell wrote on 06/21/2016 09:15:00 AM: > > > > > Thanks for the details, I appreciate it. I have seen the term > > "Swift overlay" used, particularly in the context of libdispatch. > > What does that mean exactly in this regard (searching for it returns > > tutorials on overlay UIViews which I doubt is appropriate here). > > > > Hi, > > There's a layer of Swift code that sits on top of the non-Swift > implementation of libdispatch to provide the Swift-level API for the > library. This is called the overlay. > > In Swift 2, the overlay for libdispatch was relatively thin. In Swift 3 > it became thicker and on Darwin platforms more reliant on compiler support > for importing Objective-C API declarations in a "Swifty" way. The main > work item for getting the libdispatch Swift 3 APIs on Linux is to > compensate for the lack of Objective-C by manually writing a layer (in > Swift) that sits between the basic C-level APIs libdispatch provides on > Linux and the desired user-visible Swift-3 APIs. > > --dave > -- Joseph Bell http://dev.iachieved.it/iachievedit/ @iachievedit ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
[swift-corelibs-dev] Foundation Renaming Question
Howdy. I've been building (on Linux) the latest off of master for Swift and the accompanying swift-corelibs-foundation. I can see where the great renaming is in full swing and have been updating my code accordingly. One area where I'm a bit confused is with the new API for NotificationCenter and Notification. In the past bare strings were acceptable for postNotificationName and addObserverForName. Yet now constructing a Notification and Notification.Name seem to be a bit unwieldy. Example: let ConnectedNotification= Notification(name:Notification.Name(rawValue:"ConnectedNotification")) That seems to be quite convoluted and I'm not sure why there isn't a convenience init that allows for let ConnectedNotification= Notification(name:"ConnectedNotification") Then, the APIs for post and observe seem to be mismatched: NotificationCenter.defaultCenter().postNotification(ConnectedNotification) vs. NotificationCenter.defaultCenter().addObserverForName(ConnectedNotification.name) I would think an addObserverForNotification would be more appropriate here. Finally, combining topics a bit, but they are related: let ConnectedNotification= Notification(name:Notification.Name(rawValue:"ConnectedNotification")) let DisconnectedNotification = Notification(name:Notification.Name(rawValue:"DisconnectedNotification")) These notifications are for the same API, so I'm assuming I'm "doing this wrong" and that the more Swifty way would be too put these in a struct or enum, so I'm curious as to what folks recommend. Thanks! -- Joseph Bell http://dev.iachieved.it/iachievedit/ @iachievedit ___ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
