Re: [swift-users] Problem with Access Control and Extensions
Thank you, Adrian.
(What I meant by “debating the correctness of my code” was that I wanted to
talk about the approach and not about the content of the viewDidLoad() method.)
Cheers,
Rick Aurbach
> On Sep 20, 2017, at 3:13 PM, Adrian Zubarev <adrian.zuba...@devandartist.com>
> wrote:
>
> I don’t get your problem here. If you don’t want to debate the correctness of
> your code, why are you asking for help or even showing error messages for a
> code snippet that cannot work?
>
> 1. Drop the access modifier from the extension itself, because this is only
> for convenience, which may or may not rule over the members of the extension
> members. If you’re already explicitly setting the access modifier on the
> extension members then the convenience access modifier makes no sense.
> 2. The code cannot work, because you cannot override `viewDidLoad` on a class
> that you don’t own, on a subclass of `UISplitViewController` that would be
> possible.
>
> ```
> class MySplitViewController : UISplitViewController {}
>
> extension MySplitViewController {
> override open func viewDidLoad() {
> super.viewDidLoad()
> /* ... */
> }
> }
> ```
>
> Am 20. September 2017 um 21:41:31, Rick Aurbach via swift-users
> (swift-users@swift.org <mailto:swift-users@swift.org>) schrieb:
>
>> I am trying to write an extension to a UIKit class, but am running into a
>> can’t-win situation:
>>
>> The code I ‘want’ to write looks like:
>>
>>
>> public extension UISplitViewController {
>> override public func viewDidLoad() {
>> super.viewDidLoad()
>> if UIDevice.current.userInterfaceIdiom == .pad {
>> preferredDisplayMode = .automatic
>> } else {
>> preferredDisplayMode = .primaryOverlay
>> }
>> }
>> }
>>
>> This generates the error message
>> /Users/rlaurb/Projects/Cooks-Memory/Cooks-Memory/AppDelegate.swift:131:23:
>> Overriding instance method must be as accessible as the declaration it
>> overrides
>> /Users/rlaurb/Projects/Cooks-Memory/Cooks-Memory/AppDelegate.swift:131:23:
>> Overridden declaration is here (UIKit.UIViewController)
>>
>> But I can’t change the access control of the function to ‘open’, because I
>> get the warning that the function can’t be “more” accessible than the
>> extension.
>>
>> And I can’t change the extension’s access to ‘open’ because apparently
>> extensions can’t be open.
>>
>> Now I don’t want to get into a debate about whether this code works — it’s
>> just an experiment — but is it even possible to express this idea?? I.e., is
>> it possible to express this idea without subclassing?
>>
>> Cheers,
>>
>> Rick Aurbach
>>
>> ___
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users
>> <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 does this leak?
This is getting interesting.
I added your suggested test code (set to execute once):
class FontSelectorDialog : UITableViewController {
static let chooser : ColorChooser = ColorChooser()
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
FontSelectorDialog.chooser.textChooserType = .text
}
< . . . >
}
BY THE WAY — I didn’t think to mention this previously, but the “leaking” code
is in a framework and I put the suggested test code in the same framework.
Using Xcode 8.3:
(1) Running Simulator for iPhone 7+ (10.3), profiling the code, neither your
suggested test code NOR the original code shows a leak in the Leaks Instrument.
(2) Running on an iPad Air 2 (10.2), profiling the code, your suggested test
code does NOT show a leak, but the original code DOES. (The stack trace for the
leak point is at the bottom of this email.)
I haven’t taken the next step of attempting to build a simple example to see if
I can duplicate the problem in a simple project. I’d like to pursue this
because it is increasingly looking like a “not my” bug, and I’d like to prevent
others from spending as much time on this issue as I have already.
Cheers,
Rick Aurbach
> On Mar 28, 2017, at 4:14 AM, Alex Blewitt wrote:
>
>> On 28 Mar 2017, at 05:41, Rick Aurbach wrote:
>>
>> That wouldn’t work directly. The “leak” occurs when processing a segue
>> called in response to a user button push. (I suppose I could attempt to wire
>> up a UI Test, but would rather not go down that route.)
>>
>> What I can try is to see if I can create a simple, artificial example. If it
>> also reports a leak, then I could try looping it. I’ll look into it in the
>> morning.
>
> You could try doing something like:
>
> static let choser:ColorChoser = ColorChoser()
> choser.textChoserType = .text
>
> Run that in Xcode and see if it shows a leak.
>
> Alex
0 libsystem_malloc.dylib malloc_zone_malloc
1 libsystem_malloc.dylib malloc
2 libswiftCore.dylib swift_slowAlloc
3 libswiftCore.dylib _swift_allocObject_
4 libswiftCore.dylib _swift_allocObject_
5 RLAFontSelector specialized RLAFontSelectorDialog.prepare(for :
UIStoryboardSegue, sender : Any?) -> ()
/Users/rlaurb/Projects/RLAFontSelector/Sources/RLAFontSelectorDialog.swift:0
6 RLAFontSelector RLAFontSelectorDialog.prepare(for : UIStoryboardSegue,
sender : Any?) -> ()
/Users/rlaurb/Projects/RLAFontSelector/Sources/RLAFontSelectorDialog.swift:0
7 RLAFontSelector @objc RLAFontSelectorDialog.prepare(for :
UIStoryboardSegue, sender : Any?) -> ()
/Users/rlaurb/Projects/RLAFontSelector/Sources/RLAFontSelectorDialog.swift:0
8 UIKit -[UIStoryboardSegueTemplate
_performWithDestinationViewController:sender:]
9 UIKit -[UIStoryboardSegueTemplate _perform:]
10 UIKit -[UIStoryboardSegueTemplate perform:]
11 UIKit -[UITableView
_selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:]
12 UIKit -[UITableView _userSelectRowAtPendingSelectionIndexPath:]
13 UIKit _runAfterCACommitDeferredBlocks
14 UIKit _cleanUpAfterCAFlushAndRunDeferredBlocks
15 UIKit _afterCACommitHandler
16 CoreFoundation
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
17 CoreFoundation __CFRunLoopDoObservers
18 CoreFoundation __CFRunLoopRun
19 CoreFoundation CFRunLoopRunSpecific
20 GraphicsServices GSEventRunModal
21 UIKit -[UIApplication _run]
22 UIKit UIApplicationMain
23 PoetsCorner main
/Users/rlaurb/Projects/PoetsCorner/PoetsCorner/SettingsController.swift:13
24 libdyld.dylib start
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Why does this leak?
That wouldn’t work directly. The “leak” occurs when processing a segue called in response to a user button push. (I suppose I could attempt to wire up a UI Test, but would rather not go down that route.) What I can try is to see if I can create a simple, artificial example. If it also reports a leak, then I could try looping it. I’ll look into it in the morning. Cheers, Rick Aurbach > On Mar 27, 2017, at 6:11 PM, David Sweeris <daveswee...@mac.com> wrote: > > Could you call the supposedly leaky code a few million times and look at > memory usage to see if there's actually a leak? > > - Dave Sweeris > > On Mar 27, 2017, at 13:31, Rick Aurbach via swift-users > <swift-users@swift.org <mailto:swift-users@swift.org>> wrote: > >> Okay, I downloaded the latest Xcode from the developer site. (The download >> page said it was 8.3beta5, but the version info called it 8.3 (8E161).) >> >> So I put the use of the enum back into my code and profiled it again. >> (Please refer to my original post for the Case 1 code that I’m testing here.) >> >> According to the Leaks Instrument, there is still a leak (just one 32-byte >> block, rather than two) coming from the call to prepare. >> >> Unless I’m missing something REALLY basic here, using the enum as in my >> original post should not leak. (Right??) So either there is a compiler issue >> (still present in the compiler version of Xcode 8E161) or there is an issue >> in the Leaks Instrument (still present in the latest Xcode). >> >> This is frustrating, because I don’t want to release a product with known >> leaks, but I don’t really know at this point whether I have one or whether >> I’m just seeing an artifact. Suggestions?? >> >> Cheers, >> >> Rick Aurbach >> >>> On Mar 27, 2017, at 3:01 AM, Alex Blewitt <alb...@apple.com >>> <mailto:alb...@apple.com>> wrote: >>> >>> >>>> On 26 Mar 2017, at 18:43, Rick Aurbach via swift-users >>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote: >>>> >>>> I have a situation where I have a leak that I do not understand. I would >>>> be very grateful if someone could explain it to me and offer an idea of >>>> how I can make the pattern work without leaking: >>> >>> How are you determining that this is leaking? There was an issue in Xcode >>> where the 'leaks' detector was unable to introspect the memory layout of a >>> Swift object containing an enum stored property and incorrectly flagging >>> other such reachable objects as leaks. If that's the case, do you still see >>> the same behaviour flagged in the latest Xcode? >>> >>> Alex >>> >> >> ___ >> swift-users mailing list >> swift-users@swift.org <mailto:swift-users@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-users >> <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 does this leak?
Okay, I downloaded the latest Xcode from the developer site. (The download page said it was 8.3beta5, but the version info called it 8.3 (8E161).) So I put the use of the enum back into my code and profiled it again. (Please refer to my original post for the Case 1 code that I’m testing here.) According to the Leaks Instrument, there is still a leak (just one 32-byte block, rather than two) coming from the call to prepare. Unless I’m missing something REALLY basic here, using the enum as in my original post should not leak. (Right??) So either there is a compiler issue (still present in the compiler version of Xcode 8E161) or there is an issue in the Leaks Instrument (still present in the latest Xcode). This is frustrating, because I don’t want to release a product with known leaks, but I don’t really know at this point whether I have one or whether I’m just seeing an artifact. Suggestions?? Cheers, Rick Aurbach > On Mar 27, 2017, at 3:01 AM, Alex Blewitt <alb...@apple.com> wrote: > > >> On 26 Mar 2017, at 18:43, Rick Aurbach via swift-users >> <swift-users@swift.org> wrote: >> >> I have a situation where I have a leak that I do not understand. I would be >> very grateful if someone could explain it to me and offer an idea of how I >> can make the pattern work without leaking: > > How are you determining that this is leaking? There was an issue in Xcode > where the 'leaks' detector was unable to introspect the memory layout of a > Swift object containing an enum stored property and incorrectly flagging > other such reachable objects as leaks. If that's the case, do you still see > the same behaviour flagged in the latest Xcode? > > Alex > ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
[swift-users] Why does this leak?
I have a situation where I have a leak that I do not understand. I would be
very grateful if someone could explain it to me and offer an idea of how I can
make the pattern work without leaking:
Consider two code snippets, the first of which leaks, while the second does not.
Case 1: This example leaks 2 32-byte objects..
in FontSelectorDialog.swift:
override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
switch segue.identifier! {
< ... >
case "ChooseTextColor" :
let target = segue.destination as! ColorChooser
target.textChooserType = .text // <===
< ... >
}
case "ChooseBackgroundColor" :
let target = segue.destination as! ColorChooser
target.textChooserType = .bkgnd // <===
< ... >
}
default : break
}
in ColorChooser.swift:
internal enum ColorCat {// <===
case: .text // <===
case: .bkgnd// <===
} // <===
internal class ColorChooser : UITableViewController {
internal var textChooserType : ColorCat = .text // <===
< ... >
}
Case 2: This example does not leak...
in FontSelectorDialog.swift:
override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
switch segue.identifier! {
< ...>
case "ChooseTextColor" :
let target = segue.destination as! ColorChooser
target.textChooserType = true // <===
< ... >
}
case "ChooseBackgroundColor" :
let target = segue.destination as! ColorChooser
target.textChooserType = false // <===
< ... >
}
default : break
}
in ColorChooser.swift:
internal class ColorChooser : UITableViewController {
internal var textChooserType : Bool = true // <===
< ... >
}
Can someone explain why? And how can I implement this using an enum. I want to
use an enum here because:
(a) it is easier to read and understand and seems more “swiftly”
(b) Someday, I may want to add additional options, which would be easy with an
enum but difficult using the current (Bool) implementation.
Cheers,
Rick Aurbach
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Accessing the bundle of the call-site
Jordan,
You are oh, so right! Thank you for helping me resolve a particularly major
piece of stupidity on my part.
The following code seems (subject to testing, of course), achieve what I’m
looking for:
public extension String {
public func localized(dsoHandle : UnsafeRawPointer = #dsohandle) ->
String {
var dlInformation : dl_info = dl_info()
let _ = dladdr(dsoHandle, )
let path = String(cString: dlInformation.dli_fname)
let url = URL(fileURLWithPath: path).deletingLastPathComponent()
let bundle = Bundle(url: url)
let str = bundle?.localizedString(forKey: self, value: self,
table: nil)
return str!
}
}
Cheers,
Rick
> On Dec 2, 2016, at 5:37 PM, Jordan Rose wrote:
>
>
>> On Dec 2, 2016, at 15:36, Rick Aurbach > > wrote:
>>
>> Greg,
>>
>> This is looking quite strange, because I didn’t see anything like what I
>> expected.
>>
>> Here’s the code that I’ve been using to test #dsohandle:
>>
>> public extension String {
>>
>> public func localized(dsoHandle : UnsafeRawPointer = #dsohandle) {
>> var dlInformation : dl_info = dl_info()
>> let _ = dladdr(dsoHandle, )
>> let path = String(describing: dlInformation.dli_fname!)
>
> ^ You asked for a string describing a pointer and you got one. :-) Try
> String(cString:) instead.
>
>
>
>> let bundle = Bundle(path: path)
>> }
>> }
>>
>> which is consistent with the following excerpt from the header file:
>>
>> /*
>> * Structure filled in by dladdr().
>> */
>> public struct dl_info {
>>
>> public var dli_fname: UnsafePointer! /* Pathname of shared object
>> */
>>
>> public var dli_fbase: UnsafeMutableRawPointer! /* Base address of shared
>> object */
>>
>> public var dli_sname: UnsafePointer! /* Name of nearest symbol */
>>
>> public var dli_saddr: UnsafeMutableRawPointer! /* Address of nearest
>> symbol */
>>
>> public init()
>>
>> public init(dli_fname: UnsafePointer!, dli_fbase:
>> UnsafeMutableRawPointer!, dli_sname: UnsafePointer!, dli_saddr:
>> UnsafeMutableRawPointer!)
>> }
>> public typealias Dl_info = dl_info
>>
>> public func dladdr(_: UnsafeRawPointer!, _: UnsafeMutablePointer!)
>> -> Int32
>> /* not POSIX */
>>
>>
>> I would have expected path to look something like a URL. However, here is
>> what the debugger says (with a breakpoint on the “let bundle…” line:
>>
>>
>>
>> As you can see, dli_fname doesn’t look anything like the “pathname of the
>> shared object”. Instead it looks more like the address where it was loaded.
>> Which, unfortunately, doesn’t get me any further along.
>>
>> Thoughts?
>>
>> Has this gotten hairy (and time consuming) enough that I should handle this
>> as a Technical Incident??
>>
>> Cheers,
>>
>> Rick Aurbach
>>
>>> On Dec 2, 2016, at 3:08 PM, Greg Parker >> > wrote:
>>>
>>> On Darwin #dsohandle points to a Mach-O file header. You can pass that
>>> address to dyld but I don't see an easy way to pass it to NSBundle.
>>>
>>> This might work:
>>> 1. Pass #dsohandle to dladdr()
>>> 2. Pass the dli_fname returned by dladdr() to NSBundle(path:).
>>>
>>>
On Dec 2, 2016, at 12:50 PM, Rick Aurbach > wrote:
Jordan,
I agree — #dsohandle is, indeed, little known. In fact, I’m having a devil
of a time figuring out what it is and what I can do with it. It is clearly
an UnsafeRawPointer, but to what??
Can you offer either a reference or a few lines of code that can help me
get the information I need from it? [recall that I want the framework’s
bundle so I can find it’s localized.strings file].
Cheers,
Rick Aurbach
> On Dec 2, 2016, at 12:56 PM, Jordan Rose > wrote:
>
> On Apple platforms, we'd probably prefer you use the little-known
> #dsoHandle, a magic pointer that's unique to the current dylib. Parsing
> out a module name seems incredibly brittle; the form of #function is not
> guaranteed to be stable or useful across Swift versions.
>
> Jordan
>>
>>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Accessing the bundle of the call-site
Jordan,
I agree — #dsohandle is, indeed, little known. In fact, I’m having a devil of a
time figuring out what it is and what I can do with it. It is clearly an
UnsafeRawPointer, but to what??
Can you offer either a reference or a few lines of code that can help me get
the information I need from it? [recall that I want the framework’s bundle so I
can find it’s localized.strings file].
Cheers,
Rick Aurbach
> On Dec 2, 2016, at 12:56 PM, Jordan Rose <jordan_r...@apple.com> wrote:
>
> On Apple platforms, we'd probably prefer you use the little-known #dsoHandle,
> a magic pointer that's unique to the current dylib. Parsing out a module name
> seems incredibly brittle; the form of #function is not guaranteed to be
> stable or useful across Swift versions.
>
> Jordan
>
>
>> On Dec 2, 2016, at 10:35, Rick Aurbach via swift-users
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>
>> That’s clever! Thank you; I’d probably never have thought of that.
>>
>> Cheers,
>>
>> Rick Aurbach
>>
>>> On Dec 2, 2016, at 12:25 PM, Greg Parker <gpar...@apple.com
>>> <mailto:gpar...@apple.com>> wrote:
>>>
>>>>
>>>> On Dec 2, 2016, at 9:44 AM, Rick Aurbach via swift-users
>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>>
>>>> Does anyone know if it is possible to do the following in Swift 3.x? (I’ll
>>>> describe the issue abstractly first, then give the use-case.)
>>>>
>>>> Consider two modules: A and B. A could be either the main module of an
>>>> application or an embedded framework. B is a different embedded framework.
>>>>
>>>> Now A contains an public extension of class X which contains a function
>>>> f(). Inside B, there is a reference to X.f(). Now what I want to do in f()
>>>> is to access information (a module name or bundle name or bundle ID or
>>>> something) that allows me to construct a Bundle object referring to B,
>>>> without f() having any external knowledge of the organization of the
>>>> application.
>>>>
>>>> The use-case I’m thinking about is a localization extension of String that
>>>> works in a multi-framework application architecture without requiring the
>>>> caller to specify the name of the framework and/or module.
>>>>
>>>> I.e., I want to write
>>>>
>>>>extension String {
>>>>func locate() -> String {…}
>>>>}
>>>>
>>>> and put this extension into framework “A”. Then, from framework “B”, I
>>>> want to use this function from within a function f() and [somehow] figure
>>>> out from the runtime what the bundle of “B” is, so that I can use it’s
>>>> localized strings file.
>>>>
>>>> I understand that from within the locate() method, I can use #function and
>>>> from it, parse out the module name of “A” and then use the correspondence
>>>> between module names and framework names to figure out the bundle of “A”.
>>>> BUT what I want here is the bundle resource for “B”, not “A”.
>>>
>>> You should be able to use a trick similar to the one that assert() uses to
>>> collect file and line numbers:
>>>
>>> func locate(caller: StaticString = #function) {
>>> // `caller` is the caller's #function
>>> }
>>>
>>>
>>> --
>>> Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime
>>> Wrangler
>>
>> ___
>> 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] Accessing the bundle of the call-site
That’s clever! Thank you; I’d probably never have thought of that.
Cheers,
Rick Aurbach
> On Dec 2, 2016, at 12:25 PM, Greg Parker <gpar...@apple.com> wrote:
>
>>
>> On Dec 2, 2016, at 9:44 AM, Rick Aurbach via swift-users
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>
>> Does anyone know if it is possible to do the following in Swift 3.x? (I’ll
>> describe the issue abstractly first, then give the use-case.)
>>
>> Consider two modules: A and B. A could be either the main module of an
>> application or an embedded framework. B is a different embedded framework.
>>
>> Now A contains an public extension of class X which contains a function f().
>> Inside B, there is a reference to X.f(). Now what I want to do in f() is to
>> access information (a module name or bundle name or bundle ID or something)
>> that allows me to construct a Bundle object referring to B, without f()
>> having any external knowledge of the organization of the application.
>>
>> The use-case I’m thinking about is a localization extension of String that
>> works in a multi-framework application architecture without requiring the
>> caller to specify the name of the framework and/or module.
>>
>> I.e., I want to write
>>
>> extension String {
>> func locate() -> String {…}
>> }
>>
>> and put this extension into framework “A”. Then, from framework “B”, I want
>> to use this function from within a function f() and [somehow] figure out
>> from the runtime what the bundle of “B” is, so that I can use it’s localized
>> strings file.
>>
>> I understand that from within the locate() method, I can use #function and
>> from it, parse out the module name of “A” and then use the correspondence
>> between module names and framework names to figure out the bundle of “A”.
>> BUT what I want here is the bundle resource for “B”, not “A”.
>
> You should be able to use a trick similar to the one that assert() uses to
> collect file and line numbers:
>
> func locate(caller: StaticString = #function) {
> // `caller` is the caller's #function
> }
>
>
> --
> Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime
> Wrangler
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
