Re: [swift-users] Extracting arbitrary types (e.g. UInt16) out of Data

[Philippe Hausler via swift-users]

> On Jun 26, 2017, at 1:47 PM, Roderick Mann <rm...@latencyzero.com> wrote:
> 
>> 
>> On Jun 26, 2017, at 10:20 , Charles Srstka <cocoa...@charlessoft.com 
>> <mailto:cocoa...@charlessoft.com>> wrote:
>> 
>> Rats, I was hoping that one of the reasons about being so explicit what 
>> we’re going to access and where with bindMemory() and friends would be to 
>> take care of these sorts of issues.
>> 
>> In that case, the simplest way to do it is probably just this:
>> 
>> let crc = (UInt16(myData[myData.endIndex]) << 8) | 
>> UInt16(myData[myData.endIndex - 1])
> 
> By the way, self.endIndex == self.count, so shouldn't these both have an 
> additional 1 subtracted?
> 
> That's what I'm seeing, and what the docs show. What's the point of endIndex? 
> Completeness?

If the data was sliced.

e.g.

let d = Data(bytes: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
let slice = d[2..<4]

slice.endIndex != slice.count

> 
>> 
>> (or the reverse, depending on the endianness of the source data)
>> 
>> Charles
>> 
>>> On Jun 26, 2017, at 12:05 PM, Philippe Hausler via swift-users 
>>> <swift-users@swift.org> wrote:
>>> 
>>> Data.copyBytes will do that under the hood
>>> 
>>> var crc: UInt16 = 0
>>> let amountCopied = withUnsafeMutablePointer(to: ) { data.copyBytes(to: 
>>> UnsafeMutableBufferPointer(start: $0, count: 1)) }
>>> if amountCopied == MemoryLayout.size {
>>>   // we have a full crc
>>> }
>>> 
>>> That will probably do what you want; plus it will allow you to do it from a 
>>> given range of bytes.
>>> 
>>> 
>>>> On Jun 26, 2017, at 9:57 AM, Joe Groff via swift-users 
>>>> <swift-users@swift.org> wrote:
>>>> 
>>>> 
>>>>> On Jun 26, 2017, at 1:55 AM, Daniel Vollmer via swift-users 
>>>>> <swift-users@swift.org> wrote:
>>>>> 
>>>>> Hi Rick,
>>>>> 
>>>>>> On 26. Jun 2017, at 02:37, Rick Mann via swift-users 
>>>>>> <swift-users@swift.org> wrote:
>>>>> 
>>>>> [snip]
>>>>> 
>>>>>> I'd also like to avoid unnecessary copying of the data. All of it is 
>>>>>> immutable for the purposes of this problem.
>>>>>> 
>>>>>> How can I get the UInt16 that starts at byte X in a Data? Same goes for 
>>>>>> Double or Int32 or whatever.
>>>>> 
>>>>> I’m not sure what Swift’s stance on this is, but not all platforms allow 
>>>>> misaligned memory accesses (such as your attempt to access a UInt16 that 
>>>>> lies at an odd memory address).
>>>> 
>>>> Unaligned memory accesses are not currently allowed by the language 
>>>> semantics, regardless of the underlying ISA. You should use memcpy if you 
>>>> need to load potentially-unaligned values out of raw memory.
>>>> 
>>>> -Joe
>>>> ___
>>>> swift-users mailing list
>>>> swift-users@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-users
>>> 
>> 
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com <mailto:rm...@latencyzero.com>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Extracting arbitrary types (e.g. UInt16) out of Data

[Philippe Hausler via swift-users]

> On Jun 26, 2017, at 10:20 AM, Charles Srstka <cocoa...@charlessoft.com> wrote:
> 
> Rats, I was hoping that one of the reasons about being so explicit what we’re 
> going to access and where with bindMemory() and friends would be to take care 
> of these sorts of issues.
> 
> In that case, the simplest way to do it is probably just this:
> 
> let crc = (UInt16(myData[myData.endIndex]) << 8) | 
> UInt16(myData[myData.endIndex - 1])

Yea that should work; and should be really fast as well. My example was just 
funneling it to memcpy and give you are guard where the bytes were not fully 
initialized.

> 
> (or the reverse, depending on the endianness of the source data)
> 
> Charles
> 
>> On Jun 26, 2017, at 12:05 PM, Philippe Hausler via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>> Data.copyBytes will do that under the hood
>> 
>> var crc: UInt16 = 0
>> let amountCopied = withUnsafeMutablePointer(to: ) { data.copyBytes(to: 
>> UnsafeMutableBufferPointer(start: $0, count: 1)) }
>> if amountCopied == MemoryLayout.size {
>>// we have a full crc
>> }
>> 
>> That will probably do what you want; plus it will allow you to do it from a 
>> given range of bytes.
>> 
>> 
>>> On Jun 26, 2017, at 9:57 AM, Joe Groff via swift-users 
>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>> 
>>> 
>>>> On Jun 26, 2017, at 1:55 AM, Daniel Vollmer via swift-users 
>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>> 
>>>> Hi Rick,
>>>> 
>>>>> On 26. Jun 2017, at 02:37, Rick Mann via swift-users 
>>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>> 
>>>> [snip]
>>>> 
>>>>> I'd also like to avoid unnecessary copying of the data. All of it is 
>>>>> immutable for the purposes of this problem.
>>>>> 
>>>>> How can I get the UInt16 that starts at byte X in a Data? Same goes for 
>>>>> Double or Int32 or whatever.
>>>> 
>>>> I’m not sure what Swift’s stance on this is, but not all platforms allow 
>>>> misaligned memory accesses (such as your attempt to access a UInt16 that 
>>>> lies at an odd memory address).
>>> 
>>> Unaligned memory accesses are not currently allowed by the language 
>>> semantics, regardless of the underlying ISA. You should use memcpy if you 
>>> need to load potentially-unaligned values out of raw memory.
>>> 
>>> -Joe
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org <mailto: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] Extracting arbitrary types (e.g. UInt16) out of Data

[Philippe Hausler via swift-users]

Data.copyBytes will do that under the hood

var crc: UInt16 = 0
let amountCopied = withUnsafeMutablePointer(to: ) { data.copyBytes(to: 
UnsafeMutableBufferPointer(start: $0, count: 1)) }
if amountCopied == MemoryLayout.size {
// we have a full crc
}

That will probably do what you want; plus it will allow you to do it from a 
given range of bytes.


> On Jun 26, 2017, at 9:57 AM, Joe Groff via swift-users 
>  wrote:
> 
> 
>> On Jun 26, 2017, at 1:55 AM, Daniel Vollmer via swift-users 
>>  wrote:
>> 
>> Hi Rick,
>> 
>>> On 26. Jun 2017, at 02:37, Rick Mann via swift-users 
>>>  wrote:
>> 
>> [snip]
>> 
>>> I'd also like to avoid unnecessary copying of the data. All of it is 
>>> immutable for the purposes of this problem.
>>> 
>>> How can I get the UInt16 that starts at byte X in a Data? Same goes for 
>>> Double or Int32 or whatever.
>> 
>> I’m not sure what Swift’s stance on this is, but not all platforms allow 
>> misaligned memory accesses (such as your attempt to access a UInt16 that 
>> lies at an odd memory address).
> 
> Unaligned memory accesses are not currently allowed by the language 
> semantics, regardless of the underlying ISA. You should use memcpy if you 
> need to load potentially-unaligned values out of raw memory.
> 
> -Joe
> ___
> 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] Extracting arbitrary types (e.g. UInt16) out of Data

[Philippe Hausler via swift-users]

There are probably a number of ways that would do what you need. I would need a 
bit more context or examples of what you are doing already to comment. But if I 
had those parameters to work with I would use copyBytes into the address of the 
target you are wanting to read.

There are some cases that might be improved when we add the 
UnsafeRawBuferPointer apis to Data.

Can you share a small sample of what you have already?

> On Jun 25, 2017, at 5:37 PM, Rick Mann via swift-users 
>  wrote:
> 
> I continue to struggle with the "proper" and most efficient way to do things 
> with Data.
> 
> In this case, I have a set of bytes received over a serial port in a Data. 
> The last two bytes are a (big- or little-endian) UInt16 CRC. However, there 
> maybe an odd or even number of bytes in the Data before these last two bytes, 
> so I can't just use withUnsafePointer.
> 
> I'd also like to avoid unnecessary copying of the data. All of it is 
> immutable for the purposes of this problem.
> 
> How can I get the UInt16 that starts at byte X in a Data? Same goes for 
> Double or Int32 or whatever.
> 
> If the endianness needs to change, I can do that swapping after I've gotten 
> the typed value out.
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> 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] arc4random_uniform on Linux is missing from Foundation??

[Philippe Hausler via swift-users]

arc4random_uniform is from Darwin not Foundation - it just happens to be in a 
header we import when you import Foundation.

> On May 22, 2017, at 8:44 AM, Edward Connell via swift-users 
>  wrote:
> 
> Any ideas when Foundation on Linux will support arc4random_uniform? This is 
> kind of an important function.
> There doesn't seem to be any decent substitute without requiring the 
> installation of libbsd-dev, which turns out to be messy. Currently I am doing 
> this, but glibc random with mod does not produce good quality numbers, due to 
> modulo bias.
> 
> Has anyone come up with a better solution to get a true uniform distribution 
> that isn't super messy?
>  
> import Foundation
> 
> #if os(Linux)
>   import Glibc
> #endif
> 
> 
> public func random_uniform(range: Int) -> Int {
>   guard range > 0 else { return 0 }
>   #if os(Linux)
> return Int(random()) % range
>   #else
> return Int(arc4random_uniform(UInt32(range)))
>   #endif
> }
> 
> 
> 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] Help! Slicing an array is very expensive

[Philippe Hausler via swift-users]

I wonder if Data might be a better tool for the job here since it is it’s own 
slice type and would avoid copying large amounts of data into temporary buffers.

> On May 8, 2017, at 16:47, Rick Mann via swift-users  
> wrote:
> 
> I have this C library that interacts with some hardware over the network that 
> produces a ton of data. It tells me up front the maximum size the data might 
> be so I can allocate a buffer for it, then does a bunch of network requests 
> downloading that data into the buffer, then tells me when it's done and what 
> the final, smaller size is.
> 
> Thanks to previous discussions on the list, I settled on using a [UInt8] as 
> the buffer, because it let me avoid various .withUnsafePointer{} calls (I 
> need the unsafe buffer pointer to live outside the scope of the closures). 
> Unfortunately, When I go to shrink the buffer to its final size with:
> 
>self.dataBuffer = Array(self.dataBuffer![0 ..< finalBufferSize])
> 
> This ends up taking over 2 minutes to complete (on an iPad Pro). 
> finalBufferSize is very large, 240 MB, but I think it's doing a very naive 
> copy.
> 
> I've since worked around this problem, but is there any way to improve on 
> this?
> 
> Thanks,
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> 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] Slicing a [UInt8] into a Data without copying?

[Philippe Hausler via swift-users]

Not sure on exactly how you are wanting to use this but you could approach this 
like:

let bytes: [UInt8] = [ 0xC0, 0xC0, 0xA1, 0x00, 0xC0, 0xC0, 0xA1, 0x00]
let slice = bytes[0..<4]
slice.withUnsafeBytes { buffer in
let d = Data(bytesNoCopy: UnsafeMutableRawPointer(mutating: 
buffer.baseAddress!), count: buffer.count, deallocator: .none)
// whatever you do, dont let d escape
}



> On May 4, 2017, at 16:31, Rick Mann via swift-users  
> wrote:
> 
> Is it possible to make a (immutable) Data() object from a slice of a [UInt8] 
> and avoid copying the data?
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> 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] Still having trouble with C interop (passing buffers)

[Philippe Hausler via swift-users]

> On Apr 25, 2017, at 2:57 PM, Rick Mann via swift-users 
>  wrote:
> 
> I'm trying to pass a Data of allocated size to a C function for it to fill in:
> 
> 
> lib_example_call(_ params: UnsafePointer!, _ data: 
> UnsafeMutableRawPointer!)
> 
> ...
> {
>self.dataBuffer = Data(capacity: BufferSizeConstant)


If you want to create a buffer with a given count you should use Data(count: 
Int), the method you are using just reserves a given capacity. (from what I can 
tell from your code that is likely what you really want)

> 
>var params = lib_call_params_t();
>params.data_capacity = BufferSizeConstant;
> 
>self.dataBuffer?.withUnsafeMutableBytes
>{ (inBuffer) -> Void in
>lib_example_call(, inBuffer)
>}
> }
> 
> I later get called back by the library with a size value of the actual data 
> it got. self.dataBuffer is a var. I set self.dataBuffer?.count = result size, 
> which is a reasonable value.
> 
> Unfortunately, the resulting buffer is all zeros. The data generated by the 
> call is definitely not all zero, and a C example program using the same 
> library works correctly.
> 
> So, I think there's something wrong in the way I'm making the call.
> 
> Can anyone please enlighten me? Thanks!
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> ___
> 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] [swift-corelibs-dev] Building swift with xctest and foundation fails

[Philippe Hausler via swift-users]

You need to also pass --libdispatch but I am not quite sure that will fully fix 
the problem at hand.

Sent from my iPhone

> On Mar 29, 2017, at 6:29 PM, Mohit Athwani via swift-corelibs-dev 
>  wrote:
> 
> I'm trying to get back to work starting from scratch on Swift Foundation on 
> my Ubuntu 16.04 LTS system.
> 
> I cloned the main swift repo and all of it's dependencies via ssh
> ./swift/utils/update-checkout --clone-with-ssh
> and after running (taken from instructions from the Foundation site):
> 
> swift/utils/build-script --xctest --foundation -t
> 
> I get the following error:
> 
> + make build-tests
> /bin/bash ../libtool  --tag=CC   --mode=link 
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>  -Wall -Wno-deprecated-declarations  -fblocks 
> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY   -g -O0 -rpath 
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>   -o dispatch_apply dispatch_apply.o libbsdtests.la ../src/libdispatch.la  
> -lbsd 
> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread 
> libtool: link: 
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/llvm-linux-x86_64/bin/clang
>  -Wall -Wno-deprecated-declarations -fblocks 
> -I/home/mohit/Documents/swift-source/swift-corelibs-libdispatch/src/BlocksRuntime
>  -isystem /usr/include/bsd -DLIBBSD_OVERLAY -g -O0 -o .libs/dispatch_apply 
> dispatch_apply.o  ./.libs/libbsdtests.a ../src/.libs/libdispatch.so -lbsd 
> -L/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
>  -lswiftCore -lswiftSwiftOnoneSupport -lpthread -Wl,-rpath 
> -Wl,//usr/lib/swift/linux -Wl,-rpath 
> -Wl,/home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64
> /home/mohit/Documents/swift-source/build/Ninja-DebugAssert/swift-linux-x86_64/lib/swift/linux/x86_64/libswiftCore.so:
>  undefined reference to `objc_release'
> clang-4.0: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> Makefile:1123: recipe for target 'dispatch_apply' failed
> make: *** [dispatch_apply] Error 1
> swift/utils/build-script: fatal error: command terminated with a non-zero 
> exit status 2, aborting
> 
> Looks like there is some undefined reference for objc_release in libswiftCore.
> 
> From the looks of the message it looks like swift was actually built but it's 
> just that test cases weren't built. On this hunch, I went into my 
> swift-corelibs-foundation folder and tried to execute:
> 
> ninja
> 
> Which tells me:
> 
> ninja: error: loading 'build.ninja': No such file or directory
> 
> Given my lack of experience here, I'm not quite sure how to go about 
> resolving these issues.
> 
> Could somebody help me out here please.
> 
> Thanks,
> 
> Mohit
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Foundation: build.ninja No such file or directory

[Philippe Hausler via swift-users]

What host os are you attempting to build on?

For linux you need to have a configured Foundation initially to run ninja. This 
means that you need to build swift with the build-script including --foundation 
and --libdispatch and --xctest

After one successful build you can run ninja in the Foundation directory to 
build it, and if you need to modify the build scripts (for example including 
additional files) you can run ./configure --reconfigure

> On Mar 28, 2017, at 12:28 PM, Mohit Athwani via swift-users 
>  wrote:
> 
> I am trying to build Foundation and is anybody else getting build.ninja: No 
> such file or directory error?
> 
> I just cloned everything from github. This did not happen with me when I 
> worked on my previous pull request.
> 
> Cheers!
> 
> 
> --
> Mohit Athwani
> http://about.me/mohitathwani
> ___
> 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] [swift-corelibs-dev] DateFormatter crash on second usage (new instance) on Linux (swift 3.0.1)

[Philippe Hausler via swift-users]

You are probably missing the package libblocksruntime-dev. That would cause 
that failure.

Sent from my iPhone

> On Jan 26, 2017, at 6:33 AM, Dennis Schafroth  wrote:
> 
> Thanks for the suggestions. 
> 
> It works with 3.0.2 but won't compile with 3.1 beta for Ubuntu 14.04. Missing 
> a Block.h which does exist in 3.0.2
> 
> :-Dennis
> 
>> On 26 Jan 2017, at 05.20, Philippe Hausler  wrote:
>> 
>> We should run those tests with ASAN, I thought I had fixed that with the 
>> Sierra merge.
>> 
>> Sent from my iPhone
>> 
>>> On Jan 25, 2017, at 6:11 PM, Will Stanton via swift-corelibs-dev 
>>>  wrote:
>>> 
>>> Based on the backtrace, I think the code is running into a memory issue 
>>> with Swift Foundation:
>>> https://bugs.swift.org/browse/SR-2485
>>> https://bugs.swift.org/browse/SR-2462
>>> 
>>> I haven’t seen this in a while - are you able to try running on Swift 3.1 
>>> or 3.0.2?
>>> Your code seems to work on the IBM Sandbox with 3.0.2 but not 3.0.1.
>>> You could also try replacing every 'let’ with ‘var’ but that might not be 
>>> the right solution :-)
>>> 
>>> Regards,
>>> Will Stanton
>>> 
 On Jan 25, 2017, at 5:04 PM, Dennis Schafroth via swift-users 
  wrote:
 
 Hi
 
 Trying to do some simple date parsing from syslog format (“Jan 25 
 20:21:22”) into Date. Seem to work once but crashes on second call
 
 
 func dateConv(_ dateString: String) -> Date? {
 let dateFormatter = DateFormatter()
 dateFormatter.dateFormat = "MMM dd HH:mm"
 dateFormatter.locale = Locale(identifier: "da_DK_POSIX")
 if let date = dateFormatter.date(from: dateString) {
  print("Real date: \(date)" )
  return date
 }
 return nil
 }
 
 var date  = dateConv("Jan 25 20:10")
 var date2 = dateConv("Jan 25 20:11”)
 
 # swift main.swift
 Real date: 2000-01-25 19:10:00 +
 0  swift0x0334ab78 
 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
 1  swift0x03349346 llvm::sys::RunSignalHandlers() + 54
 2  swift0x0334b6aa
 3  libpthread.so.0  0x7fec92166890
 4  libswiftCore.so  0x7fec8e8f0735
 5  libFoundation.so 0x7fec8c0ab6ee
 6  libFoundation.so 0x7fec8bd7a222
 7  libFoundation.so 0x7fec8bd7c623
 8  libFoundation.so 0x7fec8bf0e873 
 _TFC10Foundation6NSDateg11descriptionSS + 99
 9  libFoundation.so 0x7fec8c182829 
 _TTWV10Foundation4Dates23CustomStringConvertibleS_FS1_g11descriptionSS + 57
 10 libswiftCore.so  0x7fec8e78c745 
 _TFs15_print_unlockedu0_R_s16TextOutputStreamrFTxRq__T_ + 997
 
 using swift 3.0.1. Am I doing something wrong? I seems to work on macOS.
 
 cheers,
 :-Dennis
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-...@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] [swift-corelibs-dev] DateFormatter crash on second usage (new instance) on Linux (swift 3.0.1)

[Philippe Hausler via swift-users]

We should run those tests with ASAN, I thought I had fixed that with the Sierra 
merge.

Sent from my iPhone

> On Jan 25, 2017, at 6:11 PM, Will Stanton via swift-corelibs-dev 
>  wrote:
> 
> Based on the backtrace, I think the code is running into a memory issue with 
> Swift Foundation:
> https://bugs.swift.org/browse/SR-2485
> https://bugs.swift.org/browse/SR-2462
> 
> I haven’t seen this in a while - are you able to try running on Swift 3.1 or 
> 3.0.2?
> Your code seems to work on the IBM Sandbox with 3.0.2 but not 3.0.1.
> You could also try replacing every 'let’ with ‘var’ but that might not be the 
> right solution :-)
> 
> Regards,
> Will Stanton
> 
>> On Jan 25, 2017, at 5:04 PM, Dennis Schafroth via swift-users 
>>  wrote:
>> 
>> Hi
>> 
>> Trying to do some simple date parsing from syslog format (“Jan 25 20:21:22”) 
>> into Date. Seem to work once but crashes on second call
>> 
>> 
>> func dateConv(_ dateString: String) -> Date? {
>>  let dateFormatter = DateFormatter()
>>  dateFormatter.dateFormat = "MMM dd HH:mm"
>>  dateFormatter.locale = Locale(identifier: "da_DK_POSIX")
>>  if let date = dateFormatter.date(from: dateString) {
>>print("Real date: \(date)" )
>>return date
>>  }
>>  return nil
>> }
>> 
>> var date  = dateConv("Jan 25 20:10")
>> var date2 = dateConv("Jan 25 20:11”)
>> 
>> # swift main.swift
>> Real date: 2000-01-25 19:10:00 +
>> 0  swift0x0334ab78 
>> llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
>> 1  swift0x03349346 llvm::sys::RunSignalHandlers() + 54
>> 2  swift0x0334b6aa
>> 3  libpthread.so.0  0x7fec92166890
>> 4  libswiftCore.so  0x7fec8e8f0735
>> 5  libFoundation.so 0x7fec8c0ab6ee
>> 6  libFoundation.so 0x7fec8bd7a222
>> 7  libFoundation.so 0x7fec8bd7c623
>> 8  libFoundation.so 0x7fec8bf0e873 
>> _TFC10Foundation6NSDateg11descriptionSS + 99
>> 9  libFoundation.so 0x7fec8c182829 
>> _TTWV10Foundation4Dates23CustomStringConvertibleS_FS1_g11descriptionSS + 57
>> 10 libswiftCore.so  0x7fec8e78c745 
>> _TFs15_print_unlockedu0_R_s16TextOutputStreamrFTxRq__T_ + 997
>> 
>> using swift 3.0.1. Am I doing something wrong? I seems to work on macOS.
>> 
>> cheers,
>> :-Dennis
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Decimal to Double?

[Philippe Hausler via swift-users]

This might be a bit nicer since that is relying on NSNumber bridges. You can 
bridge to NSDecimalNumber directly like this: 

(Decimal(1.0) as NSDecimalNumber).doubleValue

(but perhaps we should consider adding initializers that follow the same 
pattern as Double that don’t have to bridge to solve the problem)

> On Nov 28, 2016, at 2:40 AM, Alex Blewitt via swift-users 
>  wrote:
> 
> You can wrap it with an NSDecimalNumber, and then cast it to a Double from 
> there:
> 
> Double(NSDecimalNumber(decimal:Decimal(1.0)))
> 
> Alex
> 
>> On 28 Nov 2016, at 10:13, Rick Mann via swift-users > > wrote:
>> 
>> How do I get a Double from a Decimal?
>> 
>> TIA,
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com 
>> 
>> 
>> ___
>> 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] why NSTask is Process on Apple platforms but it's Task on Linux?

[Philippe Hausler via swift-users]

Looks like that renaming didn’t get updated correctly on 
swift-corelibs-foundation. I filed - https://bugs.swift.org/browse/SR-3279

> On Nov 26, 2016, at 9:42 PM, Mr Bee via swift-users  
> wrote:
> 
> Hi all,
> 
> It took me a few hours to find out why Process is unknown on Linux while it's 
> available on macOS/iOS. Turned out, it's still called Task. Why is that? Is 
> there anything like this on Swift Standard Library and Foundation for Linux?
> 
> Thank you.
> 
> Regards, 
> 
> –Mr Bee
> 
> ___
> 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] Decimal imported as NSDecimal not NSDecimalNumber in Swift 3 to Objective C

[Philippe Hausler via swift-users]

NSDecimal is not toll free bridged, but it does have a bridge to 
NSDecimalNumber.

So take this for example:

@objc class Exam: NSObject {
var grade: Double = 90.0
}

It would be reasonable to expect that is exposed in objc as:

@interface Exam : NSObject
@property double grade;
@end

and not:

@interface Exam : NSObject
@property NSNumber *grade;
@end

As it stands this is exposing as the structural type since that structural type 
comes from objective-c. Unlike String or Dictionary that have direct 
counterparts - NSDecimal and NSDecimalNumber both are sourced from the 
objective-c headers. That being said an API exposed in objc as returning a 
NSDecimalNumber should be exposed into swift as returning a Decimal (the struct 
NSDecimal). So if Exam was implemented in objc as such:

@interface Exam : NSObject
@property NSDecimalNumber *grade;
@end

that should be imported into swift as:

class Exam : NSObject {
var grade : Decimal
}

> On Nov 11, 2016, at 2:58 PM, Adam C. Lickel via swift-users 
>  wrote:
> 
> NSDecimal has toll-free bridging with NSDecimalNumber so you can still do as 
> casting when talking to an Objective-C API.
> 
>> On Nov 11, 2016, at 2:56 PM, Chris Anderson via swift-users 
>> > wrote:
>> 
>> Sure thing. Yeah, ideally the bridging would be fixed, but at the least, 
>> correcting the documentation will be a good start. Will file, thanks.
>> 
>> Best,
>> Chris Anderson
>> 
>>> On Nov 11, 2016, at 5:55 PM, Tony Parker >> > wrote:
>>> 
>>> Hi Chris,
>>> 
>>> Can you file a radar or JIRA for us on this? It looks like something should 
>>> be fixed in the documentation at least, or perhaps in the bridging.
>>> 
>>> - Tony
>>> 
 On Nov 11, 2016, at 1:46 PM, Chris Anderson via swift-users 
 > wrote:
 
 I'm having problems with the type conversion between a Swift `Decimal` and 
 an Objective C `NSDecimalNumber`.
 
 If I have the Swift class:
 
 @objc class Exam: NSObject {
 var grade: Decimal = 90.0
 }
 
 And try to use that Swift class in Objective C, 
 
 Exam *exam = [[Exam alloc] init];
 NSDecimalNumber *result = [[NSDecimalNumber zero] 
 decimalNumberByAdding:grade.value];
 
 I get the error:
 
 Sending 'NSDecimal' to parameter of incompatible type 'NSDecimalNumber * 
 _Nonnull'
 
 as it seems like `grade` is being treated as an `NSDecimal` not an 
 `NSDecimalNumber`. This seems incorrect as per 
 https://developer.apple.com/reference/foundation/nsdecimalnumber 
  it says 
 
 "The Swift overlay to the Foundation framework provides the Decimal 
 structure, which bridges to the NSDecimalNumber class. The Decimal value 
 type offers the same functionality as the NSDecimalNumber reference type, 
 and the two can be used interchangeably in Swift code that interacts with 
 Objective-C APIs. This behavior is similar to how Swift bridges standard 
 string, numeric, and collection types to their corresponding Foundation 
 classes."
 
 So I'm not sure if 1) I'm doing something wrong. 2) there's an error in 
 the documentation or 3) this is a Swift bug. Number 1 on that list is 
 definitely the most likely, but I wanted to see what I’m missing here.
 
 I don't want to explicitly make the values in my Swift class 
 `NSDecimalNumber` because then I cannot do simple arithmetic operations 
 such as `+` without doing the whole ugly `decimalNumberByAdding` dance.
 
 Thanks for the help!
 
 Best,
 Chris Anderson
 ___
 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

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

Re: [swift-users] Autoreleasepool for Ubuntu

[Philippe Hausler via swift-users]

See:

https://github.com/apple/swift-corelibs-foundation/blob/d015466450b2675037c6f1ace8e17e73050ccfb9/Foundation/NSURL.swift#L561
 


This is far and few between of cases that it would be useful but there are a 
few APIs that we have not been able to express without being able to 
autorelease items. Most of which we have either forbidden in Linux or 
redesigned because they were sub-par swift experiences. However it seems 
reasonable to have a minimal shim to provide cross platform code compatibility 
even if it does next to nothing. That way trivial code as the original issue 
showed can easily be directly compiled on either platform without littering 
gnarly #ifdefs about.

> On Nov 2, 2016, at 12:55 PM, Jordan Rose  wrote:
> 
> I’m confused about this. Shouldn’t you be able to get away with using +1 
> convention everywhere? What needs to have arbitrary lifetime-extension in an 
> ARC-ified language?
> 
> Jordan
> 
>> On Nov 2, 2016, at 12:23, Philippe Hausler > > wrote:
>> 
>> So there are issues we have in swift-corelibs that suffer(leak) because we 
>> don't have ARPs on Linux. It would be super nice to have a retain until 
>> scope end concept for swift core libs where autorelease would be an accessor 
>> in unmanaged that would retain the object until the arp ends scope.
>> 
>> Sent from my iPhone
>> 
>> On Nov 2, 2016, at 10:17 AM, Jordan Rose > > wrote:
>> 
>>> 
 On Nov 2, 2016, at 09:42, Joe Groff via swift-users > wrote:
 
> 
> On Nov 1, 2016, at 6:40 PM, Bernardo Breder via swift-users 
> > wrote:
> 
> Hello,
> 
> I want to create a mini http server project and execute at Ubuntu 15. The 
> Xcode compile and access the function "autoreleasepool", but when i 
> compile the same code at Ubuntu, this function not found
> 
> For example, i can compile the code above at Xcode:
> 
> while true {
>autoreleasepool {
>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
> 1\r\n\r\na".data(using: .utf8)!
>}
> }
> 
> But when i try to compile at Ubuntu:
> 
> git@breder:~$ cat main.swift 
> import Foundation
> 
> while true {
>autoreleasepool {
>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
> 1\r\n\r\na".data(using: .utf8)!
>}
> }
> 
> git@breder:~$ swiftc main.swift 
> main.swift:4:5: error: use of unresolved identifier 'autoreleasepool'
>autoreleasepool {
>^~~
 
 Autoreleasepools are an ObjC compatibility feature. They aren't necessary 
 in standalone Swift.
>>> 
>>> But they are necessary in Swift programs on Apple platforms (that don’t use 
>>> RunLoop, anyway). Philippe, what do you think? What’s the right way to 
>>> write cross-platform code that doesn’t use RunLoop or dispatch_main for an 
>>> implicit autorelease pool?
>>> 
>>> (/me remembers +[NSAutoreleasePool drain] from the ObjC-GC days)
>>> 
>>> Jordan
> 

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

Re: [swift-users] Counting in Threads

[Philippe Hausler via swift-users]

Or allocate a pointer for it. The other alternative would be NSLock but that 
might be swatting flies with sledgehammers. We had a similar issue implementing 
NSLock in swift-corelibs-foundation where taking the address of a pthread mutex 
corrupted the structure for when another thread would attempt to grab it.

Sent from my iPhone

> On Oct 12, 2016, at 4:45 PM, Shawn Erickson <shaw...@gmail.com> wrote:
> 
> So we would have to drop down to C code, etc. to safely leverage OSAtomic?
> 
>> On Wed, Oct 12, 2016 at 8:32 AM Philippe Hausler via swift-users 
>> <swift-users@swift.org> wrote:
>> I was under the impression that taking the address was more than a single 
>> load instruction and would emit a placeholder invalid value: which would 
>> make that technically unsafe in a threaded context.
>> 
>> Sent from my iPhone
>> 
>>> On Oct 12, 2016, at 8:18 AM, Daniel Dunbar via swift-users 
>>> <swift-users@swift.org> wrote:
>>> 
>>> I suspect one of the actual compiler people might tell me I shouldn't trust 
>>> this, but in practice it works:
>>> --
>>> import Darwin.C
>>> 
>>> public class AtomicInt32 {
>>>public fileprivate (set) var value : Int32 = 0
>>> 
>>>/// Create a new atomic integer with the specified initial value.
>>>public init(_ value: Int32 = 0) {
>>>self.value = value
>>>}
>>> 
>>>/// Add one to the value.
>>>public func increment () {
>>>OSAtomicIncrement32()
>>>}
>>> }
>>> 
>>> public func +=(int: AtomicInt32, value: Int32) {
>>>OSAtomicAdd32(value, )
>>> }
>>> --
>>> 
>>> Would also love to know if compiler guarantees I *can* trust this.
>>> 
>>> Note that this has to be a class for this to be in any way safe, which 
>>> means it is also rather inefficient if the use case was having a lot of 
>>> them.
>>> 
>>> - Daniel
>>> 
>>>> On Oct 12, 2016, at 12:47 AM, Gerriet M. Denkmann via swift-users 
>>>> <swift-users@swift.org> wrote:
>>>> 
>>>> 
>>>> How to translate this to Swift:
>>>> 
>>>> __block atomic_uint_fast64_t counter = ATOMIC_VAR_INIT(0);
>>>> dispatch_apply( nbrInterations, queue, ^void(size_t idx)
>>>>{
>>>>uint64_t tCount = 0;
>>>>... do some counting ...
>>>>atomic_fetch_add_explicit( , tCount, memory_order_relaxed );
>>>>}
>>>> )
>>>> 
>>>> Currently I am using:
>>>> 
>>>> var counter: UInt64 = 0
>>>> let dsema = DispatchSemaphore(value: 1)  
>>>> DispatchQueue.concurrentPerform( iterations: nbrInterations )
>>>> { ( idx: size_t) -> Void in
>>>>
>>>>var tCount: UInt64 = 0
>>>>... do some counting ...
>>>>_ = dsema.wait(timeout: .distantFuture) 
>>>>counter += tCount;
>>>>dsema.signal()  
>>>> }
>>>> 
>>>> Is there a better way?
>>>> 
>>>> Gerriet.
>>>> 
>>>> ___
>>>> 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
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Identity based object hash?

[Philippe Hausler via swift-users]

ObjectIdentifier(self).hashValue is a decent approach; it hashes based upon the 
pointer address. That is how swift-corelibs-foundation does it for the swift 
implementation of NSObject: 
https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSObject.swift#L94

> On Oct 5, 2016, at 9:53 AM, Travis Griggs via swift-users 
>  wrote:
> 
> I have a class that I’d rather not have based off of NSObject, but I do want 
> to have identity based equality. I’ve done that as follows:
> 
> class Foobar { }
> 
> extension Foobar:Equatable { }
> 
> func == (a:Foobar, b:Foobar) -> Bool {
>   return a === b
> }
> 
> What’s less clear to me is how to go about implementing an identity based hash
> 
> extension Foobar:Hashable {
>   var hashValue:Int {
>   // what magic should happen here?
>   }
> }
> ___
> 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] Something you might be able to answer

[Philippe Hausler via swift-users]

So there are a couple of ways objects can be bridged:

1) has-a style bridges - RunLoop and CFRunLoop for example. The only 
association is where RunLoop contains a CFRunLoop and there is a method to 
fetch the CFRunLoop out of the RunLoop. Some times this relationship is not 
public.

2) is-a style bridges - NSCFString and CFString for example. These are where 
the structural size and layout of the objects are identical. So when casting 
the only change is a re-interpretation of the type and the underlying data 
structure backing the object is exactly the same.

3) toll-free bridges - NSString and CFString for example. CF can take NSStrings 
because the methods that transact upon CFStrings all check to determine if the 
object being passed is a subclass of NSString or if it is a NSCFString, in the 
NSString subclass cases it will dispatch calls out to the subclass to specific 
funnel points such that it can reasonably transact upon that object.

4) Compiler generated struct to reference bridges - NSString and String. When 
the translation occurs the compiler emits a call to a method on String to 
convert NSString to String. This is just a specialized and automatically 
generated form of style 1

The styles 1, 2 and 3 work for swift-corelibs-foundation, however 4 is disabled 
for linux even though we have both the reference types and the structural 
types. 

On Darwin CFReadStream is actually a NSCFInputStream (which is a subclass of 
NSInputStream) but currently in swift-corelibs-foundation CFReadStream is a 
NSCFType (I would consider that discrepancy an incomplete point of 
swift-corelibs-foundation) with an ivar of a CFReadStream. So what would need 
to be done is that InputStream and OutputStream would need to be made 
conditionally abstract and the ivar layout would need to exactly mimic the 
layout of the CF counterpart. Two new subclasses would need to be made to 
dispatch back into CF the functionality for streams created from CF and 
dispatching methods would need to be made. Doing this would make InputStream 
and OutputStream more like NSString (which might be a decent place to take a 
look at how it works).

Let me know if there is anything I can help clear up on more.

> On Sep 20, 2016, at 11:29 PM, Dave Abrahams  wrote:
> 
> 
> From: Bouke Haarsma via swift-users 
> Subject: How to bridge between CoreFoundation and SwiftFoundation on Linux?
> Date: September 20, 2016 at 9:38:54 PM PDT
> To: swift-users@swift.org
> Reply-To: Bouke Haarsma 
> 
> 
> Hi all,
> 
> When working with CoreFoundation objects (e.g. CFReadStream, 
> CFWriteStream) it isn't immediately obvious to me how to bridge them to 
> SwiftFoundation counterparts (InputStream / OutputStream).
> 
> The following works on OSX, but doesn't work on Linux;
> 
>let readStream: CFReadStream = ...
>readStream as InputStream
>// error: cannot convert value of type 'CFReadStream' to expected 
> argument type 'InputStream'
> 
> In some other places I need to bridge a String to a CFString, the 
> following works on OSX, but doesn't work on Linux;
> 
>let string: String = ...
>string as CFString
>// error: error: 'String' is not convertible to 'CFString'; did you 
> mean to use 'as!' to force downcast?
> 
> Thanks.
> 
> -- 
> -Bouke
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
> 
> 
> 
> 
> -- 
> -Dave

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

Re: [swift-users] How to bridge between CoreFoundation and SwiftFoundation on Linux?

[Philippe Hausler via swift-users]

I would suggest that the way to do it is to follow the NSString/NSNumber 
approach used in swift-corelibs-foundation where the structural size is 
equivalent.

the layout would roughly look like:


open class InputStream : Stream {
typealias CFType = CFReadStream
// This layout MUST be the same as CFReadStream so that they are bridgeable
private var _base = _CFInfo(typeID: CFReadStreamGetTypeID())
private var _flags: CFOptionFlags = 0
private var _error: UnsafeMutableRawPointer? = nil
private var _info: UnsafeMutableRawPointer? = nil
private var _callBacks: UnsafeMutableRawPointer? = nil
#if os(OSX) || os(iOS)
private var _lock = pthread_mutex_t()
#elseif os(Linux)
private var _lock = Int32(0)
#endif
private var _previousRunloopsAndModes: UnsafeMutableRawPointer? = nil
#if DEPLOYMENT_ENABLE_LIBDISPATCH
private var _queue: UnsafeMutableRawPointer? = nil
#endif

internal var _cfObject: CFType {
return unsafeBitCast(self, to: CFType.self)
}

...
}

This would ensure the memory size of the allocation of InputStream would be the 
same as CFReadStream. 

These two calls would then need to be un-commented in NSSwiftRuntime.swift

//_CFRuntimeBridgeTypeToClass(CFReadStreamGetTypeID(), 
unsafeBitCast(InputStream.self, UnsafeRawPointer.self))
//_CFRuntimeBridgeTypeToClass(CFWriteStreamGetTypeID(), 
unsafeBitCast(OutputStream.self, UnsafeRawPointer.self))

and __CFSwiftBridge would need entries for calling out to swift for subclassers.


> On Sep 21, 2016, at 1:03 PM, Bouke Haarsma via swift-users 
>  wrote:
> 
> The one that comes with SwiftFoundation 
> (https://github.com/apple/swift-corelibs-foundation/tree/master/CoreFoundation
>  
> ).
> 
> I think it should be a bug that CFReadStream cannot be bridged to 
> (NS)InputStream, as otherwise there’s no way to intertwine Sockets 
> (CFSockets) with SwiftFoundation. As the implementation already uses a 
> CFReadStream internally 
> (https://github.com/apple/swift-corelibs-foundation/blob/d3872cb094124d5dd189839505ae73e2fa717cfd/Foundation/NSStream.swift#L122
>  
> ),
>  it would be a matter of adding an initializer. However the value is private, 
> so adding the initializer cannot be done from an extension.
> 
> —
> Bouke
> 
>> On 21 Sep 2016, at 21:22, Jens Alfke > > wrote:
>> 
>> 
>>> On Sep 20, 2016, at 9:38 PM, Bouke Haarsma via swift-users 
>>> > wrote:
>>> 
>>> When working with CoreFoundation objects (e.g. CFReadStream, CFWriteStream) 
>>> it isn't immediately obvious to me how to bridge them to SwiftFoundation 
>>> counterparts (InputStream / OutputStream).
>>> 
>>> The following works on OSX, but doesn't work on Linux;
>> 
>> What implementation of CF are you using on Linux? OpenStep?
>> 
>> The bridging between Swift and Obj-C Foundation classes is only implemented 
>> on Apple platforms. It’s not part of the open source release. The plan is to 
>> implement classes like InputStream in native Swift as part of the standard 
>> library; that work is in progress.
>> 
>> —Jens
> 
> ___
> 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