date:20171218

Re: [swift-users] [swift-dev] Make offset index available for String

2017-12-18 Thread Cao, Jiannan via swift-users

OK, but how do you use IndexingIterator to get element and not change itself?

In C++, the iterator is more like index. because it could be used to get the 
element, and not change itself, and it can be offset back and forth not only by 
one.
*it
*(it+5)
*(it-5)
but in Swift,
you can only using next() to get the element and change the iterator to point 
to the next item:
it.next()
it.next()
it.next()
it.next()
it.next()
and you could not go to previous item.


The iterator in Swift could not be used as index.

> 在 2017年12月19日，上午3:00，Michael Ilseman  > 写道：
> 
> An index that keeps a reference to the collection is an iterator, e.g. the 
> IndexingIterator[1], which String already provides.
> 
> [1] https://developer.apple.com/documentation/swift/indexingiterator 
> 
> 
> 
>> On Dec 18, 2017, at 12:53 AM, Cao, Jiannan > > wrote:
>> 
>> Or we can copy the design of std::vector::iterator in C++.The index could 
>> keep a reference to the collection.
>> When the index being offset by + operator, it could call the owner to offset 
>> the index, since it keeps a reference to the collection owner.
>> 
>> let startIndex = s.startIndex
>> s[startIndex+1]
>> 
>> public struct MyIndex : Comparable where T.Index == MyIndex {
>> public let owner: T
>> ...
>> public static func + (lhs: MyIndex, rhs: T.IndexDistance) -> MyIndex {
>> return lhs.owner.index(lhs, offsetBy: rhs)
>> }
>> }
>> 
>>> 在 2017年12月15日，上午9:34，Michael Ilseman >> > 写道：
>>> 
>>> Yes, I was trying to highlight that they are different and should be 
>>> treated different. This was because it seemed you were conflating the two 
>>> in your argument. You claim that people expect it, and I’m pointing out 
>>> that what people actually expect (assuming they’re coming from C or 
>>> languages with a similar model) already exists as those models deal in 
>>> encoded offsets.
>>> 
>>> More important than expectations surrounding what to provide to a subscript 
>>> are expectations surrounding algorithmic complexity. This has security 
>>> implications. The expectation of subscript is that it is “constant-ish”, 
>>> for a fuzzy hand-wavy definition of “constant-ish” which includes amortized 
>>> constant or logarithmic.
>>> 
>>> Now, I agree with the overall sentiment that `index(offsetBy:)` is 
>>> unwieldy. I am interested in approaches to improve this. But, we cannot 
>>> throw linear complexity into subscript without extreme justification.
>>> 
>>> 
 On Dec 14, 2017, at 5:25 PM, Cao, Jiannan > wrote:
 
 This offset is unicode offset, is not the offset of element. 
 For example: index(startIndex, offsetBy:1) is encodedOffset 4 or 8, not 1.
 
 Offset indexable is based on the offset of count of each element/index. it 
 is the same result of s.index(s.startIndex, offsetBy:i)
 The encodedOffset is the underlaying offset of unicode string, not the 
 same concept of the offset index of collection.
 
 The offset indexable is meaning to the elements and index of collection 
 (i-th element of the collection), not related to the unicode offset (which 
 is the underlaying data offset meaning to the UTF-16 String).
 
 These two offset is totally different.
 
 Best,
 Jiannan
 
> 在 2017年12月15日，上午9:17，Michael Ilseman  > 写道：
> 
> 
> 
>> On Dec 14, 2017, at 4:49 PM, Cao, Jiannan via swift-dev 
>> > wrote:
>> 
>> People used to the offset index system instead of the String.Index. 
>> Using offset indices to name the elements, count the elements is normal 
>> and nature.
>> 
> 
> The offset system that you’re referring to is totally available in String 
> today, if you’re willing for it to be the offset into the encoding. 
> That’s the offset “people” you’re referring to are likely used to and 
> consider normal and natural. On String.Index, there is the following:
> 
> init(encodedOffset offset: Int 
> )
> 
> and 
> 
> var encodedOffset: Int 
>  { get }
> 
> 
> [1] https://developer.apple.com/documentation/swift/string.index 
> 
> 
> 
>> This offset index system has a long history and a real meaning to the 
>> collection. The subscript s[i] has a fix meaning of "getting the i-th 
>> element in this collection", which is normal and direct. Get the range 
>> with offset

Re: [swift-users] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

2017-12-18 Thread Greg Parker via swift-users

Jon is correct: JSON uses '.' as the decimal separator. 
Benoit is also correct: the bug is that JSONEncoder is incorrectly writing ',' 
as the decimal separator when the locale is set to fr_FR.

Further discussion will be on the swift-corelibs-dev list.


> On Dec 18, 2017, at 10:08 AM, Jon Shier via swift-users 
>  wrote:
> 
> I’m pretty sure JSON isn’t localized, so this isn’t a bug. Using anything but 
> a . as a decimal separator isn’t valid JSON. 
> 
> 
> Jon
> 
>> On Dec 18, 2017, at 11:51 AM, Benoit Pereira da silva via swift-users 
>> > wrote:
>> 
>> Dear all
>> 
>> I've found a serious Bug in JSONEncoder SR-6131 
>>  and would like to fix it.
>> This bug cause JSON encoding issues on Double when using a local that does 
>> not use dot as decimal separator e.g « fr_FR » (we use a coma)
>> 
>> Demonstration of the issue : 
>> 
>> import Foundation
>> 
>> // Required to call setLocale
>> import Darwin
>> 
>> // Let's set to french
>> setlocale(LC_ALL,"fr_FR")
>>  
>> struct Shot:Codable{
>> let seconds:Double
>> }
>>  
>> let shot = Shot(seconds: 1.1)
>>  
>> do{
>> let data = try JSONEncoder().encode(shot)
>> if let json =  String(data:data, encoding:.utf8){
>> // the result is : "{"seconds":1,1001}"
>> // The decimal separator should not be "," but "."
>> print(json)
>> }
>> }catch{
>> print("\(error)")
>> }
>>  
>> exit(EX_OK)
>> 
>> 
>> 
>> 
>> I would like to propose my fix, test it and, but i’m not mastering the 
>> contribution mechanism.
>> 
>> Where should i start? 
>> 
>> I ve forked 
>> https://github.com/benoit-pereira-da-silva/swift-corelibs-foundation 
>> 
>> I have a very simple Unit test that demonstrates the issue.
>> 
>> How can i test my 
>> 
>> 
>> Thanks
>> 
>> 
>> 
>> 
>> 
>> Benoit Pereira da Silva
>> Ultra Mobile Developer & Movement Activist
>> Développeur Ultra Mobile & Militant du mouvement
>> https://pereira-da-silva.com 
>> 
>> 
>> 
>> 
>> 
>> ✄ 
>> This e-mail is confidential. Distribution, copy, publication or use of this 
>> information for any purpose is prohibited without agreement of the sender.
>> Ce message est confidentiel. Toute distribution, copie, publication ou usage 
>> des informations contenues dans ce message sont interdits sans agrément 
>> préalable de l'expéditeur.
>> 
>> 
>> 
>> ___
>> 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] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

2017-12-18 Thread Jon Shier via swift-users

I’m pretty sure JSON isn’t localized, so this isn’t a bug. Using anything but a 
. as a decimal separator isn’t valid JSON. 


Jon

> On Dec 18, 2017, at 11:51 AM, Benoit Pereira da silva via swift-users 
>  wrote:
> 
> Dear all
> 
> I've found a serious Bug in JSONEncoder SR-6131 
>  and would like to fix it.
> This bug cause JSON encoding issues on Double when using a local that does 
> not use dot as decimal separator e.g « fr_FR » (we use a coma)
> 
> Demonstration of the issue : 
> 
> import Foundation
> 
> // Required to call setLocale
> import Darwin
> 
> // Let's set to french
> setlocale(LC_ALL,"fr_FR")
>  
> struct Shot:Codable{
> let seconds:Double
> }
>  
> let shot = Shot(seconds: 1.1)
>  
> do{
> let data = try JSONEncoder().encode(shot)
> if let json =  String(data:data, encoding:.utf8){
> // the result is : "{"seconds":1,1001}"
> // The decimal separator should not be "," but "."
> print(json)
> }
> }catch{
> print("\(error)")
> }
>  
> exit(EX_OK)
> 
> 
> 
> 
> I would like to propose my fix, test it and, but i’m not mastering the 
> contribution mechanism.
> 
> Where should i start? 
> 
> I ve forked 
> https://github.com/benoit-pereira-da-silva/swift-corelibs-foundation 
> 
> I have a very simple Unit test that demonstrates the issue.
> 
> How can i test my 
> 
> 
> Thanks
> 
> 
> 
> 
> 
> Benoit Pereira da Silva
> Ultra Mobile Developer & Movement Activist
> Développeur Ultra Mobile & Militant du mouvement
> https://pereira-da-silva.com 
> 
> 
> 
> 
> 
> ✄ 
> This e-mail is confidential. Distribution, copy, publication or use of this 
> information for any purpose is prohibited without agreement of the sender.
> Ce message est confidentiel. Toute distribution, copie, publication ou usage 
> des informations contenues dans ce message sont interdits sans agrément 
> préalable de l'expéditeur.
> 
> 
> 
> ___
> 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] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

2017-12-18 Thread Jordan Rose via swift-users

(moving to more relevant list)

> On Dec 18, 2017, at 08:51, Benoit Pereira da silva via swift-users 
>  wrote:
> 
> Dear all
> 
> I've found a serious Bug in JSONEncoder SR-6131 
>  and would like to fix it.
> This bug cause JSON encoding issues on Double when using a local that does 
> not use dot as decimal separator e.g « fr_FR » (we use a coma)
> 
> Demonstration of the issue : 
> 
> import Foundation
> 
> // Required to call setLocale
> import Darwin
> 
> // Let's set to french
> setlocale(LC_ALL,"fr_FR")
>  
> struct Shot:Codable{
> let seconds:Double
> }
>  
> let shot = Shot(seconds: 1.1)
>  
> do{
> let data = try JSONEncoder().encode(shot)
> if let json =  String(data:data, encoding:.utf8){
> // the result is : "{"seconds":1,1001}"
> // The decimal separator should not be "," but "."
> print(json)
> }
> }catch{
> print("\(error)")
> }
>  
> exit(EX_OK)
> 
> 
> 
> 
> I would like to propose my fix, test it and, but i’m not mastering the 
> contribution mechanism.
> 
> Where should i start? 
> 
> I ve forked 
> https://github.com/benoit-pereira-da-silva/swift-corelibs-foundation 
> 
> I have a very simple Unit test that demonstrates the issue.
> 
> How can i test my 
> 
> 
> Thanks
> 
> 
> 
> 
> 
> Benoit Pereira da Silva
> Ultra Mobile Developer & Movement Activist
> Développeur Ultra Mobile & Militant du mouvement
> https://pereira-da-silva.com 
> 
> 
> 
> 
> 
> ✄ 
> This e-mail is confidential. Distribution, copy, publication or use of this 
> information for any purpose is prohibited without agreement of the sender.
> Ce message est confidentiel. Toute distribution, copie, publication ou usage 
> des informations contenues dans ce message sont interdits sans agrément 
> préalable de l'expéditeur.
> 
> 
> 
> ___
> 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] Incorrect Fisher-Yates shuffle in example code

2017-12-18 Thread Ankit Aggarwal via swift-users

Thank you for working on this!

On Sun, Dec 17, 2017 at 11:07 PM, Saagar Jha via swift-users <
swift-users@swift.org> wrote:

>
> Saagar Jha
>
> On Dec 17, 2017, at 22:24, Nevin Brackett-Rozinsky via swift-users <
> swift-users@swift.org> wrote:
>
> …well that was more complicated than I anticipated.
>
> The “random” function was (Int) -> Int, so when I removed the
> “IndexDistance == Int” constraint on “shuffle” I either had to add several
> “numericCast” calls or make “random” generic.
>
> So I made “random” generic. And also fixed the modulo bias issue in the
> Glibc version that Saagar mentioned. Or at least I hope I did. I haven’t
> tested that part (nor any of the non-Swift-4 / non-macOS parts). Also, I am
> not sure why “random” had been a closure value stored in a “let” constant,
> but I changed it to a function.
>
>
> Great! I'll close my pull request, then.
>
>
> While I was at it, I removed the random-access constraint I had placed on
> “shuffle”. It will now shuffle any MutableCollection, with complexity O(n)
> for a RandomAccessCollection and O(n²) otherwise. (The constraint was
> different in different Swift versions, so the entire extension had to be
> duplicated. Without the constraint the implementation is much sleeker.)
>
> Nevin
>
>
> On Sun, Dec 17, 2017 at 9:26 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
>> On Sun, Dec 17, 2017 at 7:37 PM, Dave Abrahams 
>> wrote:
>>
>>>
>>> On Dec 16, 2017, at 4:34 PM, Nevin Brackett-Rozinsky via swift-users <
>>> swift-users@swift.org> wrote:
>>>
>>> public extension MutableCollection where Self: RandomAccessCollection,
>>> IndexDistance == Int {
>>>
>>>
>>> IndexDistance == Int is an over-constraint, FWIW.  Adding it is
>>> generally a mistake.  Not a serious one, but it does limit utility somewhat.
>>>
>>> HTH,
>>> Dave
>>>
>>
>> You are correct, however there is an accepted-and-implemented proposal (
>> SE–0191
>> )
>> to eliminate IndexDistance and replace it with Int, so the constraint will
>> always be satisfied starting in Swift 4.1.
>>
>> I wrote a version of shuffle() without that constraint, but it is less
>> elegant: the line “for n in 0 ..< count - 1” no longer compiles, and
>> writing “0 as IndexDistance” doesn’t fix it because the resulting Range is
>> not a Sequence, since IndexDistance.Stride does not conform to
>> SignedInteger (at least in Swift 4.0 according to Xcode 9.2).
>>
>> A while loop works of course, though a direct conversion requires writing
>> “var n = 0 as IndexDistance” before the loop. Luckily, with a bit of
>> cleverness we can eliminate all mention of IndexDistance, and this time we
>> really and truly don’t need the “guard !isEmpty” line:
>>
>> extension MutableCollection where Self: RandomAccessCollection {
>> mutating func shuffle() {
>> var n = count
>> while n > 1 {
>> let i = index(startIndex, offsetBy: count - n)
>> let j = index(i, offsetBy: random(n))
>> n -= 1
>> swapAt(i, j)
>> }
>> }
>> }
>>
>> Essentially, the constraint is there to make the code nicer on pre-4.1
>> versions of Swift, though I’m happy to remove it if you think that’s
>> better. If nothing else, removing the constraint means people reading the
>> example code in the future won’t be misled into thinking they need to use
>> it themselves, so perhaps it should go just on that account.
>>
>> Okay, you’ve convinced me, I’ll update the PR. :-)
>>
>> Nevin
>>
>
> ___
> 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] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

2017-12-18 Thread Benoit Pereira da silva via swift-users

Dear all

I've found a serious Bug in JSONEncoder SR-6131 
 and would like to fix it.
This bug cause JSON encoding issues on Double when using a local that does not 
use dot as decimal separator e.g « fr_FR » (we use a coma)

Demonstration of the issue : 

import Foundation

// Required to call setLocale
import Darwin

// Let's set to french
setlocale(LC_ALL,"fr_FR")
 
struct Shot:Codable{
let seconds:Double
}
 
let shot = Shot(seconds: 1.1)
 
do{
let data = try JSONEncoder().encode(shot)
if let json =  String(data:data, encoding:.utf8){
// the result is : "{"seconds":1,1001}"
// The decimal separator should not be "," but "."
print(json)
}
}catch{
print("\(error)")
}
 
exit(EX_OK)




I would like to propose my fix, test it and, but i’m not mastering the 
contribution mechanism.

Where should i start? 

I ve forked 
https://github.com/benoit-pereira-da-silva/swift-corelibs-foundation 

I have a very simple Unit test that demonstrates the issue.

How can i test my 


Thanks





Benoit Pereira da Silva
Ultra Mobile Developer & Movement Activist
Développeur Ultra Mobile & Militant du mouvement
https://pereira-da-silva.com 





✄ 
This e-mail is confidential. Distribution, copy, publication or use of this 
information for any purpose is prohibited without agreement of the sender.
Ce message est confidentiel. Toute distribution, copie, publication ou usage 
des informations contenues dans ce message sont interdits sans agrément 
préalable de l'expéditeur.



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

Re: [swift-users] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

2017-12-18 Thread David Hart via swift-users

Hello!

Thanks for noticing a bug and taking the time to fix it :) Here are the steps 
for contributing:

Fork the project (you’ve already done that).
Clone the fork to your computer.
Branch off master and name the branch after the fix (I like to name them with 
the sr number).
Write the fix and the test that validates it (i 
f
 you’re looking for help here, you can read this documentation from the 
corelibs foundation repo: 
https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/GettingStarted.md)
Push your branch to the remote.
On GitHub, open a Pull Request and wait for somebody to look into it.

If anybody notices that I’ve forgotten a step, please let me know. Meanwhile, 
if you need any help Benoit, I’m available to chat (in French or English) on 
the SwiftPM Slack at https://swift-package-manager.herokuapp.com 

Regards,
David Hart.

> On 18 Dec 2017, at 11:34, Benoit Pereira da silva via swift-users 
>  wrote:
> 
> Dear all
> 
> I've found a serious Bug in JSONEncoder SR-6131 
>  and would like to fix it.
> This bug cause JSON encoding issues on Double when using a local that does 
> not use dot as decimal separator e.g « fr_FR » (we use a coma)
> 
> Demonstration of the issue : 
> 
> import Foundation
> 
> // Required to call setLocale
> import Darwin
> 
> // Let's set to french
> setlocale(LC_ALL,"fr_FR")
>  
> struct Shot:Codable{
> let seconds:Double
> }
>  
> let shot = Shot(seconds: 1.1)
>  
> do{
> let data = try JSONEncoder().encode(shot)
> if let json =  String(data:data, encoding:.utf8){
> // the result is : "{"seconds":1,1001} »
>   // should be : "{"seconds":1.1001} »
> // The decimal separator should not be "," but "."
> print(json)
> }
> }catch{
> print("\(error)")
> }
>  
> exit(EX_OK)
> 
> 
> 
> 
> I would like to propose my fix, test it and, but i’m not mastering the 
> contribution mechanism.
> 
> Where should i start? 
> 
> I ve forked 
> https://github.com/benoit-pereira-da-silva/swift-corelibs-foundation 
> 
> I have a very simple Unit test that demonstrates the issue.
> 
> How can i test my 
> 
> 
> Thanks
> 
> 
> 
> 
> 
> Benoit Pereira da Silva
> Ultra Mobile Developer & Movement Activist
> Développeur Ultra Mobile & Militant du mouvement
> https://pereira-da-silva.com 
> 
> 
> 
> 
> 
> ✄ 
> This e-mail is confidential. Distribution, copy, publication or use of this 
> information for any purpose is prohibited without agreement of the sender.
> Ce message est confidentiel. Toute distribution, copie, publication ou usage 
> des informations contenues dans ce message sont interdits sans agrément 
> préalable de l’expéditeur.
> 
> 
> ___
> 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] I've found a serious Bug in JSON encoding (SR-6631) and would like to fix it. [Sorry for the multiple posts]

2017-12-18 Thread Benoit Pereira da silva via swift-users

Dear all

I've found a serious Bug in the JSON encoding foundations. [ SR-6631 
 ]

This bug cause JSON encoding issues on Doubles when using a locale that does 
not use dot as decimal separator e.g « fr_FR » (we use a coma)
When using such a locale JSONEncoder & JSONSerialization encodes the Double 
value with the localized decimal separator. 

Code proof of the issue : 

import Foundation

// Required to call setLocale
import Darwin

// Let's set to french
setlocale(LC_ALL,"fr_FR")
 
struct Shot:Codable{
let seconds:Double
}
 
let shot = Shot(seconds: 1.1)
 
do{
let data = try JSONEncoder().encode(shot)
if let json =  String(data:data, encoding:.utf8){
// the result is : "{"seconds":1,1001} »
// should be : "{"seconds":1.1001} »
// The decimal separator should not be "," but "."
print(json)
}
}catch{
print("\(error)")
}
 
exit(EX_OK)


Fix Proposal : 

 in swift-corelibs-foundation 
https://github.com/benoit-pereira-da-silva/swift-corelibs-foundation/blob/7bf5fc770471bcc6f9050cbdcd49492feccda2f2/Foundation/JSONSerialization.swift#L308
 

In `JSONSerialization.swift` line 308  may be should we specify  
`kCFNumberFormatterDecimalSeparator` ? 
Adding :  CFNumberFormatterSetProperty(formatter, 
kCFNumberFormatterDecimalSeparator,CFSTR("."))

private lazy var _numberformatter: CFNumberFormatter = {
let formatter: CFNumberFormatter
formatter = CFNumberFormatterCreate(nil, CFLocaleCopyCurrent(), 
kCFNumberFormatterNoStyle)
CFNumberFormatterSetProperty(formatter, 
kCFNumberFormatterMaxFractionDigits, NSNumber(value: 15))
CFNumberFormatterSetProperty(formatter, 
kCFNumberFormatterDecimalSeparator,CFSTR("."))
CFNumberFormatterSetFormat(formatter, "0.###"._cfObject)
return formatter
}()


I would like to propose my fix, test it and, but i’m not mastering the 
contribution mechanism.

Where should i start? 

I ve forked swift-corelibs-foundation 

How can i test my fix? 




Thanks



Benoit Pereira da Silva
Ultra Mobile Developer & Movement Activist
Développeur Ultra Mobile & Militant du mouvement
https://pereira-da-silva.com 





✄ 
This e-mail is confidential. Distribution, copy, publication or use of this 
information for any purpose is prohibited without agreement of the sender.
Ce message est confidentiel. Toute distribution, copie, publication ou usage 
des informations contenues dans ce message sont interdits sans agrément 
préalable de l'expéditeur.



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

[swift-users] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

2017-12-18 Thread Benoit Pereira da silva via swift-users

Dear all

I've found a serious Bug in JSONEncoder SR-6131 
 and would like to fix it.
This bug cause JSON encoding issues on Double when using a local that does not 
use dot as decimal separator e.g « fr_FR » (we use a coma)

Demonstration of the issue : 

import Foundation

// Required to call setLocale
import Darwin

// Let's set to french
setlocale(LC_ALL,"fr_FR")
 
struct Shot:Codable{
let seconds:Double
}
 
let shot = Shot(seconds: 1.1)
 
do{
let data = try JSONEncoder().encode(shot)
if let json =  String(data:data, encoding:.utf8){
// the result is : "{"seconds":1,1001} »
// should be : "{"seconds":1.1001} »
// The decimal separator should not be "," but "."
print(json)
}
}catch{
print("\(error)")
}
 
exit(EX_OK)




I would like to propose my fix, test it and, but i’m not mastering the 
contribution mechanism.

Where should i start? 

I ve forked 
https://github.com/benoit-pereira-da-silva/swift-corelibs-foundation 

I have a very simple Unit test that demonstrates the issue.

How can i test my 


Thanks





Benoit Pereira da Silva
Ultra Mobile Developer & Movement Activist
Développeur Ultra Mobile & Militant du mouvement
https://pereira-da-silva.com 





✄ 
This e-mail is confidential. Distribution, copy, publication or use of this 
information for any purpose is prohibited without agreement of the sender.
Ce message est confidentiel. Toute distribution, copie, publication ou usage 
des informations contenues dans ce message sont interdits sans agrément 
préalable de l’expéditeur.


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

Re: [swift-users] [swift-dev] Make offset index available for String

Re: [swift-users] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

Re: [swift-users] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

Re: [swift-users] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

Re: [swift-users] Incorrect Fisher-Yates shuffle in example code

[swift-users] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

Re: [swift-users] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

[swift-users] I've found a serious Bug in JSON encoding (SR-6631) and would like to fix it. [Sorry for the multiple posts]

[swift-users] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

9 matches

Site Navigation

Mail list logo

Footer information