Re: [swift-corelibs-dev] Measurement Formatters & ICU
I think there is a review related to format APIs ongoing for ICU 58, but there hasn’t been much talk about the C APIs alas: https://sourceforge.net/p/icu/mailman/message/35283778/ http://bugs.icu-project.org/trac/ticket/12029 Since MeasureFormat ‘and friends’ are C++, for now, I also think the best path would be a C wrapper in CF that can pass things off to Apple’s ICU or on Linux to: http://opensource.apple.com/source/ICU/ICU-551.30/icuSources/i18n/uameasureformat.cpp http://opensource.apple.com/source/ICU/ICU-551.30/icuSources/i18n/uatimeunitformat.cpp I think the script to handle ninja on Linux also needed to be modified to build C++ successfully (I believe some private/internal includes needed to be set). Regards, Will Stanton > On Aug 22, 2016, at 1:10 PM, Tony Parker via swift-corelibs-dev > wrote: > > I would love to be able to use ICU from Swift instead of implementing > everything twice, but maybe that’s a tall order. ___ swift-corelibs-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] Measurement Formatters & ICU
I recall the time formatter being deprecated in favor of measfmt, so you might be right that uatimeunitformat isn't needed. I think some functions in uatimeunitformat.cpp made combining units easier when calling from (then NS)DateComponentsFormatter, but perhaps that can be put functionality in a (Swift-)CFDateComponentsFormatter wrapper. (Not sure if Apple will come out with its own CFDateComponentsFormatter). I think this was what I had to change to get C++ working: https://github.com/apple/swift-corelibs-foundation/blob/master/lib/phases.py The includes for CompileCxx should be more like CompileC. Regards, Will Stanton Sent from my iPhone > On Aug 22, 2016, at 15:58, Henry Betts via swift-corelibs-dev > wrote: > > Yes - I was planning on including uameasureformat.cpp for the linux build, > although I was also unsure whether the build script was setup to compile c++. > Noticed a bug in uameasureformat.cpp by the way; DURATION_DAY and > DURATION_WEEK are the wrong way around! > > I’m a bit confused by uatimeunitformat. I’m probably missing something > obvious, but what can it do that uameasureformat can’t do? ___ swift-corelibs-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] [swift-dev] Linux: Build process not finding my ICU
Hello Eric, Not sure if this will help, but perhaps you can feed something in build.py? https://github.com/apple/swift-corelibs-foundation/blob/master/build.py You seem to be working under some tight constraints! Is installing ICU in /usr/local/ not possible? Regards, Will Stanton > On Sep 13, 2016, at 6:21 PM, Eric Wing via swift-dev > wrote: > > I'm trying to build Swift 3 on a Linux system that doesn't come with a > usable libICU. > I've built ICU myself and placed it in a non-root directory (along > with a lot of other dependencies not available on my system that Swift > needs). > > I've had to reimplement my patch because it looks like a rebase was > done which broke the merge. (https://bugs.swift.org/browse/SR-1358) > > Anyway, I think I've gotten through building the swift compiler > itself, but the build process is now in swift-corelibs-foundation. The > build process fails at #include for > CoreFoundation/Locale.subproj/CFCalendar.c > > Looking at the build flags in my console, I see no -I flags to the > location of my ICU headers (or any other of my extra dependencies). > > How do I fix the build process to make sure these extra paths are searched? > > Thanks, > Eric ___ swift-corelibs-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
[swift-corelibs-dev] Mirror behavior
Hello,
I had a question about the intended behavior/functionality of mirrors in
Swift/Swift Foundation types.
In general, should a Mirror reference all variables in a type?
I’m not sure what scope mirrors should/will have, but it does seem like some of
iterating through children has been done:
http://stackoverflow.com/questions/34601802/how-can-i-check-if-a-property-has-been-set-using-swift-reflection
Should mirrors only reference public+ variables? Or private ones too? Is it
meant to be up to the author?
With respect to Foundation, I was starting to silence some warnings with ‘as
Any’ (https://bugs.swift.org/browse/SR-2737), but I noticed this code in
URLComponents.swift at
https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/URLComponents.swift#L313:
if let s = self.scheme { c.append((label: "scheme", value: s)) }
if let u = self.user { c.append((label: "user", value: u)) }
etc...
Should public properties be mirrored even if their values are nil?
c.append((label: "scheme", value: s as Any))
c.append((label: "user", value: u as Any))
etc...
What rules should there be to determine what gets mirrored?
Regards,
Will Stanton
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] [swift-dev] Mirror behavior
Hello Enrico,
Thank you for the reply!
If the goal of `Mirror` is reflection, wouldn’t the full structure of a type
need to be exposed by its `Mirror`? And even if the goal is a more limited form
of inspection, wouldn’t it still be necessary to make the default
implementation, which exposes all variables, accessible?
(Is there a way to do that – to ignore `customMirror` and get a type’s ‘full’
mirror? If not, I think the exposure of CustomReflectable outside the standard
library is a bit strange.)
Regards,
Will Stanton
> On Sep 23, 2016, at 1:54 PM, Enrico Granata wrote:
>
> There exists a default behavior, but also an override mechanism
> (CustomReflectable) in case the author of the type knows better
>
> For instance, if you have
>
> struct Point { var x: Double; var y: Double }
>
> you probably do just want to see "x" and "y" reflected - and the default will
> do just that
>
> But in more complex scenarios, e.g. Array, you probably want to see the
> logical contents of the type (the array elements), not the underlying
> implementation details
>
> I don't think metadata currently vends visibility, so it's unlikely we do
> anything to hide non-public variables in reflection.
> I think other languages take a similar stance, so maybe it's just the right
> thing to do, but I also can't recall any explicit discussion about this
>
> As for the Foundation-specific bits, I'll let somebody with more Foundation
> expertise help you out
>
>>
>> With respect to Foundation, I was starting to silence some warnings with ‘as
>> Any’ (https://bugs.swift.org/browse/SR-2737), but I noticed this code in
>> URLComponents.swift at
>> https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/URLComponents.swift#L313:
>>
>> if let s = self.scheme { c.append((label: "scheme", value: s)) }
>> if let u = self.user { c.append((label: "user", value: u)) }
>> etc...
>>
>>
>> Should public properties be mirrored even if their values are nil?
>> c.append((label: "scheme", value: s as Any))
>> c.append((label: "user", value: u as Any))
>> etc...
>>
>> What rules should there be to determine what gets mirrored?
>>
>> Regards,
>> Will Stanton
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] Implementing HTTPCookieStorage
Was wondering if there could be a common directory for Foundation-related files, such as NSUserDefaults in addition to cookie storage? So maybe for cookies: NSHomeDirectory() + "/.foundation/Cookies/shared" And settings for an app/service: NSHomeDirectory() + "/.foundation/Preferences/EXECUTABLE_NAME.plist" And I’m not familiar with how Apple Foundation/CFNetwork/nsurlsessiond handles cookies… or caches things, but I think I agree with Kenny that naming symmetry would be nice if there is a per-user cookies file. So having a /Library may be nicer, but potentially unnecessary? NSHomeDirectory() + "/.foundation/Library/Cookies/Cookies.something" Regards, Will Stanton > On Nov 7, 2016, at 5:45 PM, Tony Parker via swift-corelibs-dev > wrote: > > Hi Pushkar, > > Good question. If this were Darwin I guess I would say ~/Library/Application > Support — but I don’t know what the best practices are on other platforms. > Does anyone out there have some suggestions? ___ swift-corelibs-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] Implementing HTTPCookieStorage
Hello Tony and Philippe, I don’t think it would be odd for cookie/setting files to be in a folder named after Foundation (namely ~/.foundation): - The files are owned by Swift/Linux Foundation in the sense Foundation writes them, and Foundation is the only one that should access them directly. Foundation should enforce security. - On macOS, settings seem to be written to ~/Library/Preferences/$(BUNDLE_ID).plist, and the proposed ~/.foundation/Preferences/EXECUTABLE_NAME.plist isn’t that different. ‘.foundation’ is used in lieu of a library directory, and I feel this is acceptable so as not to clash with any user ~/Preferences or ~/Library directory. I am OK with the ‘Foundation ownership’ per above. And, executable name seems reasonable in lieu of bundle ID. I noted something like ~/.foundation/Library/Preferences/EXECUTABLE_NAME.plist may be desirable to keep symmetry/reuse more CF code, but changing Swift CF is probably necessary anyway and better (fewer search paths to loop through, possibly less I/O). Am interested in alternatives of course :-) - But having separate folders for each app seems complicated, ex. '~/.app1/Preferences’ ‘~/.app2/Preferences’ pollutes home. - I don’t really mind the name of an encapsulating folder, .foundation or otherwise. - Placing system configuration files in /etc is a norm, but I think I’d feel more comfortable with Swift app settings in /home/user (easier to keep track of, and I can delete the whole thing without consequences*). I’m also not writing any real low-level services in Swift… but others probably are… but they probably have their own code to write config data to /etc! To Philippe’s points about security+future-proofing: Perhaps the cookie file could be named per version of its format: ~/.foundation/Cookies/shared initially When we have a new format: ~/.foundation/Cookies/shared2, shared3, etc? Or even pick a new name entirely? I also think it should be up to Swift Foundation to enforce cookie security on a per-app/family basis (the latter requires changes to the package structure?). Perhaps for now, it is possible to save the hash and name of the executable storing a cookie? And Foundation can load cookie storage only if the executable name and file haven’t changed? (Is that an unnecessary pain?) Regards, Will Stanton > On Nov 14, 2016, at 12:44 PM, Tony Parker wrote: > > Isn’t it a bit odd to use ‘.foundation’ as the name of the directory, when > Foundation is just one of the libraries involved? On Darwin, the prefs are > organized by application, not by framework. ___ swift-corelibs-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] Implementing HTTPCookieStorage
Hello Tony, Thanks for the reply. About XDG_DATA_HOME, the variable is undefined on my desktop-less server, and I think many processes still have their own save locations. Still, I can believe its used in a lot of places (https://github.com/search?q=XDG_DATA_HOME&type=Code&utf8=✓) and am not opposed to it! Perhaps SEARCH/$EXECUTABLE_NAME/Preferences.plist would be good place and format for NSUserDefaults with SEARCH = getenv(XDG_DATA_HOME) then ~/.config? What about the path for cookies+caches? Regards, Will Stanton > On Nov 14, 2016, at 2:37 PM, Tony Parker via swift-corelibs-dev > wrote: > > Off-list, someone pointed me here: > > https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html > > and here: > > http://stackoverflow.com/questions/1024114/location-of-ini-config-files-in-linux-unix > > Noting that there seems to be a growing consensus for $HOME/.config. > > Is this spec beginning to be used in the real world? ___ swift-corelibs-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] Fatal error Foundation/NSCalendar.swift, Ubuntu 16.04, Swift 3.0.1
Hello Malcolm, It looks like cutting line 606 of NSCalendar.swift and pasting it over `false` on line 607 fixes the issue. 1> import Foundation 2. let fromDate = Date() 3. let toDate = Date(timeIntervalSinceNow: 20) 4. let components = Calendar.current.dateComponents([.second], from: fromDate, to: toDate) // ... [6] = 20 // ... Regards, Will Stanton > On Nov 30, 2016, at 9:22 AM, Malcolm Barclay via swift-corelibs-dev > wrote: > > Hi, > > Is this a bug in the NSCalendar.swift? On Ubuntu 16.04 with Swift 3.0.1 > installed this crashes. ___ swift-corelibs-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] [swift-users] DateFormatter crash on second usage (new instance) on Linux (swift 3.0.1)
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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] Unable to Build swift-corelibs-foundation
Hello David, Are you seeing these errors in macOS/Xcode? If so, I think `-swift-version 3` needs to be passed to the swift compiler. Submitted this PR for Mac build issues among others: https://github.com/apple/swift-corelibs-foundation/pull/988 Matt, I think you’re running into similar issues, but Ted already made a PR for builds done with build-script - I believe that’s why the Linux build works (https://github.com/apple/swift-corelibs-foundation/pull/956). Perhaps you can confirm in verbose mode `ninja -v`, in the swift-corelibs-foundation directory, that `-swift-version 3` is being passed in? Regards, Will Stanton > On May 18, 2017, at 7:07 AM, David Dunn via swift-corelibs-dev > wrote: > > I've pulled down all the latest changes from > https://github.com/apple/swift-corelibs-foundation and currently using the > latest toolchain (Swift Development Snapshot 2017-05-16). > However various errors arise when trying to build. > > I get numerous errors that are similar to this: > swift-corelibs-foundation/Foundation/Data.swift:63:41: '>>' is unavailable > '>>' was obsoleted in Swift 4 > > And this error also occurs: > swift-corelibs-foundation/Foundation/NSArray.swift:375:157: Contextual > closure type '(UnsafeMutableRawPointer, Int) -> Void' expects 2 arguments, > but 1 was used in closure body > > I was wondering if anyone knew a way around these errors? Or is there's > something I'm doing wrong. > > Thanks. ___ swift-corelibs-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
