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

2017-12-19 Thread Lily Vulcano via swift-corelibs-dev 


> On Dec 19, 2017, at 10:27 AM, Jon Shier via swift-corelibs-dev 
>  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. 

JSONEncoder seems to be producing that content, so this does look like a Swift 
library issue.

Benoit: if you have a patch that fixes the issue, feel free to submit it as a 
GitHub pull request (*) against master and we’ll discuss it (and kick off 
testing) from there. I also opened  so 
that it isn’t forgotten. ✾

(*) https://help.github.com/articles/creating-a-pull-request/

> 
> 
> Jon
> 
>> On Dec 18, 2017, at 1:04 PM, Jordan Rose via swift-users 
>> mailto:[email protected]>> wrote:
>> 
>> (moving to more relevant list)
>> 
>>> On Dec 18, 2017, at 08:51, Benoit Pereira da silva via swift-users 
>>> mailto:[email protected]>> 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
>>> [email protected] 
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> 
>> 
>> ___
>> swift-users mailing list
>> [email protected] 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
> ___
> swift-corelibs-dev mailing list
> [email protected] 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> 
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] [Proposal] [Foundation] Allowing for system bundles on Linux

2018-01-12 Thread Lily Vulcano via swift-corelibs-dev 
All,

I’m looking for feedback on a proposal I'm working on for Foundation on Linux. 
On Darwin OSes, we are able to provide resources from system-installed bundles 
in /System and /Library and locate them through the various bundle APIs 
(CFBundle or Foundation’s Bundle class); on Linuxes, BSDs and other Unix-y 
systems those paths do not exist and system resources are organized 
differently. We would like to start shipping resource files for Core Foundation 
for tasks such as providing localized content, but also store them in a way 
that's idiomatic when taking the system install conventions on these platforms 
into account, and also enable other frameworks to do so if they need to.

To this end, I’ve just sent out a PR for a proposal for installed bundles that 
would allow CFBundle and higher-level APIs to find code and resources installed 
in /usr/local or in the prefix of your choice (e.g. /opt/myapp/). In short:


 - Directories of the form /share/.resources are recognized as 
installed bundles.

 - Their main executable is /lib/lib.so (for frameworks), or 
/bin/ (for executable bundles). Fallbacks from/to lib32/lib64 
or sbin are also allowed, and  will be sourced from Info.plist’s 
CFBundleExecutable key if present, as usual.

 - The resources path is /share/.resources (the same as the 
bundle location).

 - Auxiliary executables and embedded frameworks are in 
/libexec/.executables.

 - Framework headers are in /include//*.h, to support #include 
 syntax.

 - The layout of these directories is the same as that of an iOS bundle for 
their respective slice of content (e.g.: 
/share/.resources/en.lproj/Localizable.strings; 
/libexec/.executables/Frameworks/MyFramework.…)


Despite being at separate paths, as required by the relevant specs, these 
disparate locations become a single logical CFBundle; you can find the correct 
path using the existing CFBundle… accessor API (or the existing Bundle 
properties). Any path that is optional in Darwin is also optional under this 
scheme.

In addition to this, we will still support a ‘freestanding’ bundle structure 
that can be used for private or embedded frameworks, where almost all files are 
grouped into one directory, and Bundle APIs will continue supporting any bundle 
structure they already do.

The full text of the proposal is here: 
, and an 
implementation will follow shortly. Let me know if you have any feedback! ✾


___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev